Added several libinput config options.
In weston.ini, the new options are called tap_and_drag, tap_and_drag_lock, disable_touchpad_while_typing, middle_emulation, left_handed, rotation, accel_profile, accel_speed, scroll_method, natural_scroll, and scroll_button.
Fixes #172 (closed).
STATUS: After further testing with a USB mouse, I have confirmed that everything except for rotation is working. I don't have the hardware to test rotation.
Merge request reports
Activity
middle_emulation you can test with most touchpads. when enabled, you can middle-click with the bottom left+right area simultaneously. when disabled, the center of the touchpad's bottom line has the middle button.
rotation is only available on trackballs.
accel speed and profile apply to every mouse, you should notice the differences there.
scroll_button is for the trackpoint scrolling (press button, move trackpoint -> scroll events). Set this to the right button or something to test, it's the middle button by default. you can enable that on any mouse too.
oops, because
[libinput]
is global, this applies natural scrolling not just to touchpads but to mice too. I guess it would make sense to limitnatural_scroll
to touchpads?--- i/compositor/main.c +++ w/compositor/main.c @@ -1534,7 +1534,8 @@ configure_input_device_scroll(struct weston_config_section *s, uint32_t button; uint32_t button_default; - if (libinput_device_config_scroll_has_natural_scroll(device)) { + if (libinput_device_config_scroll_has_natural_scroll(device) + && libinput_device_has_capability(device, LIBINPUT_DEVICE_CAP_GESTURE)) { natural_default = libinput_device_config_scroll_get_default_natural_scroll_enabled(device); weston_config_section_get_bool(s, "natural_scroll",
Edited by Val Packett@whot I tried disabling
middle_emulation
on my touchpad. It only has two physical buttons. It wouldn't work, though. Middle emulation remained on. I'm pretty sure I wrote the code right, so it must be a problem with the driver for my touchpad. It's kind of a weird one. PS/2.accel_speed
had no effect on my touchpad. I have a mouse. I'll test it.I did what you are asking me to do re.
scroll_button
. It didn't do anything. I'll try it on a USB mouse or something.Looks like all evdev devices are allowed to have natural scroll:
To libinput, both mice and touchpads are just pointers. I don't think there's any way to distinguish between them other than checking gesture support.
@whot I just added some more log entries for debugging. middle_emulation and accel_profile=flat are working on the usb mouse. Neither are supported by my touchpad. Judging by my log entries, no attempt to configure these two options was made on the touchpad, so the support checking functions must have failed. So there are driver issues with the touchpad, apparently. scroll_method=button did work on the USB mouse. scroll_button was set by the code, but the USB mouse would not respond to it. No matter what number I put there, only the middle mouse button will scroll. What are the valid values of scroll_button? I can't figure it out from libinput's docs.
@myfreeweb I just tried your change and now natural_scroll has no effect on my touchpad. It appears there are touchpads without the GESTURE capability. I think we've established my touchpad is weird as hell, though, so if it works for your touchpad and most others, fine, I guess. The real solution to the weirdness of odd-ball devices is per-device configuration. That can happen in a later patch. I mean I could do it in this patch, but it can happen in a later patch.
added 1 commit
- 0bf9f4bd - libinput config: added logging, got picky about natural_scroll
Not having
GESTURE
probably means a rather old non-multi-touch touchpad.A "good" way to detect touchpads might be to wait for some events and see if they're absolute or relative, but, ugh. Deferring choices until events sounds too complex.
Does your touchpad support tap to click, tap to drag, etc? Maybe a good enough check would be
GESTURE || tap-to-click || tap-to-drag
fwiw, run
libinput list-devices
and it'll show you the options available and the defaults. if something isn/a
or only has one option, then you can't change it and won't see a difference. good to detect if it's your code or the devices themselves.@myfreeweb: all devices in libinput are evdev devices, but the backends (evdev-fallback, evdev-mt-touchpad, ...) can override the defaults. for this purpose though: all touchpads and mice have natural scroll as option.
@ewtoombs: if you don't have gestures, you may have a semi-mt touchpad? check the
libinput record
output forINPUT_PROP_SEMI_MT
.as for detecting touchpads: libinput doesnt have device types so you need to figure it out yourself. capability pointer and tap-to-click is a good choice for most situations. Gestures aren't always available though. you could also fetch the udev device and rely on
ID_INPUT_TOUCHPAD
if you trust udev more.What are the valid values of scroll_button
something like
BTN_RIGHT
, i.e. the kernel event codes.Does your touchpad support tap to click
all touchpads do support that, it's disabled on most of them by default.
Ah, I found it in
linux/input-event-codes.h
. libinput's documentation never mentioned where the button codes were coming from. I can see now that they are non-trivial. I assumed they start from 0, but they actually start from 0x110. That documentation should really be fixed. I am programming these event codes into the code now. The user is not expected to know that the mouse button codes start at 0x110.Edited by Eric ToombsThanks for the tip, @whot. scroll_button works now. Only
rotation
has not been tested.It is very good to see the libinput options added to Weston, thank you for that! I've been wishing for left-handed mouse for years. I'm also very happy to see the manuals updated. Updating the example
weston.ini
could be useful as well.When you design the
weston.ini
syntax, it is ok to have the settings global for now, but also think how it can be extended to per-device syntax: e.g. to match sets of devices by certain criteria, then apply a setting to them. Xorg has a scheme like that, for instance. You don't need to design it completely now, just think about how to allow it to be added later. Maybe it is already fine, maybe not, I haven't looked that carefully. We don't yet have many libinput options, so I think if necessary, we could still easily replace the existing syntax with something more future-proof.The
weston.ini
can be thought of as the public API of Weston towards the users, so it should be kept very stable, hence giving it a good thought is worthwhile.When you revise a MR, do not add fixup patches on top. Instead, squash your fixes to the original patches, update their commit messages, etc.
I would be happy to see this work merged when someone says they have reviewed the code and it looks good.