Skip to content
Snippets Groups Projects

Added several libinput config options.

Merged Eric Toombs requested to merge ewtoombs/weston:libinput-configure into master

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.

Edited by Eric Toombs

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Eric Toombs changed the description

    changed the description

  • 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 limit natural_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
  • I assumed mice would get filtered by libinput_device_config_scroll_has_natural_scroll(device). Is that not happening on your end?

  • @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:

    https://gitlab.freedesktop.org/libinput/libinput/blob/3a4f7ccff9480a5a206e81200bb2a6222defa9e0/src/evdev.c#L735-738

    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.

  • @myfreeweb you're right. I just tested again with my USB mouse. Adding your change now. All other checks succeed to filter for touchpads in a sensible way.

  • @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.

  • Eric Toombs changed the description

    changed the description

  • Eric Toombs added 1 commit

    added 1 commit

    • 0bf9f4bd - libinput config: added logging, got picky about natural_scroll

    Compare with previous version

  • 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 is n/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 for INPUT_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 Toombs
  • Eric Toombs added 1 commit

    added 1 commit

    • ad419e66 - libinput config: fixed scroll_button.

    Compare with previous version

  • Thanks for the tip, @whot. scroll_button works now. Only rotation has not been tested.

  • Eric Toombs changed the description

    changed the description

  • 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.

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply
Loading