Hello! I'm using - Arch Linux - plasma-desktop 5.7.5 - libinput 1.5.0 - xf86-input-libinput 0.20.0 While I have "natural" scrolling disabled in systemsettings, that doesn't take effect unless and until I suspend and subsequently resume the laptop. This is reproduced on every boot, and then breaks again whenever I switch to a non-X TTY and back again. I started recording with evemu, switched to a TTY and back, and then scrolled (thus triggering the reverts-to-natural-scrolling bug) but no events were recorded: # EVEMU 1.3 # Kernel: 4.7.6-1-ARCH # DMI: dmi:bvnHP:bvrN82Ver.01.07:bd04/27/2016:svnHP:pnHPZBookStudioG3:pvr:rvnHP:rn80D4:rvrKBCVersion11.60:cvnHP:ct10:cvr: # Input device name: "AlpsPS/2 ALPS GlidePoint" # Input device ID: bus 0x11 vendor 0x02 product 0x08 version 0x700 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event type 1 (EV_KEY) # Event code 272 (BTN_LEFT) # Event code 325 (BTN_TOOL_FINGER) # Event code 328 (BTN_TOOL_QUINTTAP) # Event code 330 (BTN_TOUCH) # Event code 333 (BTN_TOOL_DOUBLETAP) # Event code 334 (BTN_TOOL_TRIPLETAP) # Event code 335 (BTN_TOOL_QUADTAP) # Event type 3 (EV_ABS) # Event code 0 (ABS_X) # Value 1129 # Min 0 # Max 4095 # Fuzz 0 # Flat 0 # Resolution 48 # Event code 1 (ABS_Y) # Value 1134 # Min 0 # Max 2047 # Fuzz 0 # Flat 0 # Resolution 37 # Event code 47 (ABS_MT_SLOT) # Value 1 # Min 0 # Max 3 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 53 (ABS_MT_POSITION_X) # Value 0 # Min 0 # Max 4095 # Fuzz 0 # Flat 0 # Resolution 48 # Event code 54 (ABS_MT_POSITION_Y) # Value 0 # Min 0 # Max 2047 # Fuzz 0 # Flat 0 # Resolution 37 # Event code 57 (ABS_MT_TRACKING_ID) # Value 0 # Min 0 # Max 65535 # Fuzz 0 # Flat 0 # Resolution 0 # Properties: # Property type 0 (INPUT_PROP_POINTER) # Property type 2 (INPUT_PROP_BUTTONPAD) N: AlpsPS/2 ALPS GlidePoint I: 0011 0002 0008 0700 P: 05 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 01 00 00 00 00 00 B: 01 20 e5 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 03 00 00 00 00 80 60 02 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 A: 00 0 4095 0 0 48 A: 01 0 2047 0 0 37 A: 2f 0 3 0 0 0 A: 35 0 4095 0 0 48 A: 36 0 2047 0 0 37 A: 39 0 65535 0 0 0 ################################ # Waiting for events # ################################ Here are the device settings (they do not change between the working and broken states): Device 'AlpsPS/2 ALPS GlidePoint': Device Enabled (138): 1 Coordinate Transformation Matrix (140): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (292): 1 libinput Tapping Enabled Default (293): 0 libinput Tapping Drag Enabled (294): 1 libinput Tapping Drag Enabled Default (295): 1 libinput Tapping Drag Lock Enabled (296): 0 libinput Tapping Drag Lock Enabled Default (297): 0 libinput Tapping Button Mapping Enabled (298): 1, 0 libinput Tapping Button Mapping Default (299): 1, 0 libinput Accel Speed (275): 0.000000 libinput Accel Speed Default (276): 0.000000 libinput Natural Scrolling Enabled (280): 0 libinput Natural Scrolling Enabled Default (281): 0 libinput Send Events Modes Available (259): 1, 1 libinput Send Events Mode Enabled (260): 0, 0 libinput Send Events Mode Enabled Default (261): 0, 0 libinput Left Handed Enabled (282): 0 libinput Left Handed Enabled Default (283): 0 libinput Scroll Methods Available (284): 1, 1, 0 libinput Scroll Method Enabled (285): 1, 0, 0 libinput Scroll Method Enabled Default (286): 1, 0, 0 libinput Click Methods Available (300): 1, 1 libinput Click Method Enabled (301): 1, 0 libinput Click Method Enabled Default (302): 1, 0 libinput Middle Emulation Enabled (289): 0 libinput Middle Emulation Enabled Default (290): 0 libinput Disable While Typing Enabled (303): 1 libinput Disable While Typing Enabled Default (304): 1 Device Node (262): "/dev/input/event5" Device Product ID (263): 2, 8 libinput Drag Lock Buttons (291): <no items> libinput Horizontal Scroll Enabled (264): 1 The laptop is an HP Zbook Studio G3 (dmi stuff included in evemu output).
(In reply to andykluger from comment #0) > Here are the device settings (they do not change between the working and > broken states): that indicates that the problem is elsewhere. does it work when you toggle the property directly with this command: xinput set-prop 'AlpsPS/2 ALPS GlidePoint' 'libinput Natural Scrolling Enabled' 1
Yes, toggling with that command (alternating the value between 1 and 0) does work reliably. So then the proper avenue to pursue here would seem to be the plasma project / systemsettings, I suppose. If that's correct, feel free to close this issue. Thank you.
I've created a bug on the KDE tracker: https://bugs.kde.org/show_bug.cgi?id=370202
yep, that'll be somewhere in the the system settings then
I just upgraded to plasma 5.8, other versions remain the same. Now those xinput toggling commands have no effect. Is the bug bounced back here?
Ah, correction: Those commands _do_ work, but only after doing the suspend-wake dance.
run a xinput watch-props on the side, then toggle the property. maybe something immediately resets the property? I can't really thing of anything else tbh
Before the suspend-wake dance, watch-props reports when natural scrolling is disabled (0) as if it works, though it doesn't. There's no report of being set back to natural. After the suspend-wake dance, it reports the same way, but this time it is in accordance with actual behavior.
I feel a bit dense right now (and jetlagged), can you please rephrase the above? so even when you run the set-prop command to change the property to 1, it doesn't actually change? and you don't get an error message? note that the property is independent of the functionality, if the property changes but the feature doesn't, then that's a bug but it may happen, so there are three things to monitor: the value you set it to, the actual value being set (watch-props shows that) and the feature enabling/disabling.
Sorry: Watch-props correctly shows the value changing in accordance with the set commands, but the feature/user-behavior does not change until a suspend-wake cycle.
I don't know where this could be broken. The natural scrolling options are straightforward and a hacked up version of the event-debug tool in libinput that allows me to change the values on demand seems to work too. Can you reproduce this in a plain X sessions without KDE running? Does it work on the tty when you run libinput-debug-events --enable-natural-scrolling?
Yes, I've reproduced the same behavior in a plain X session without Plasma running. With no X running, in a plain TTY, things got interesting: # libinput-debug-events --enable-natural-scrolling and dragging two fingers downwards shows positive vert values, at a minimum magnitude of 15, and constant magnitude unless I drag very quickly. # libinput-debug-events --disable-natural-scrolling and dragging two fingers downwards shows negative vert values, at a minimum magnitude of 15, and constant magnitude unless I drag very quickly. If I interrupt the process, suspend and wake, and try again, nothing changes. If I leave the process running, suspend and wake, and try again, the signs are reversed, and the magnitudes are smaller and highly variable. If I do the same in an X (Plasma) session, the changes from suspend-wake (reversed sign, small magnitudes, variable magnitudes) are seen even if I interrupt the process before suspending.
now I'm out of ideas. I can't reproduce this here and I can't even think what would cause this. Is this a long-standing bug or did you notice this as regression? I kinda rely on you figuring out what triggers this, because unless I can reproduce this here, I just don't know what the reason would be. sorry.
It's a new computer, and has always been this way for it. Thanks for your efforts on this. I'll just keep suspending for now.
I'm going to assume that pointer motion doesn't change? Also, does anything on the kernel side change? e.g. the events coming out of a different kernel device now or something? libinput-debug-events should tell you the event node the events come from, does that change after suspend? If so, I'll need evemu-record outputs from before/after.
> I'm going to assume that pointer motion doesn't change? Actually, it might be a bit more sluggish or less accelerating before suspension (or after TTY switching). I've also recently noticed that horizontal two-finger scrolling doesn't work at all before suspension, and that this touchpad actually has a middle click area along the bottom (physical click), which acts as a left-click area before suspension. > Also, does anything on the kernel side change? e.g. the events coming out of a different kernel device now or something? libinput-debug-events should tell you the event node the events come from, does that change after suspend? Yes, it looks like the events before suspend are from node 7, and after, node 9. > If so, I'll need evemu-record outputs from before/after. I'll get some and attach them shortly.
Actually, you're probably interested in this in particular: /dev/input/event7: ALP0011:00 044E:120C /dev/input/event9: AlpsPS/2 ALPS GlidePoint
That sounds like i2c shot itself then, event7 is the i2c node, event9 the PS/2 one. If the former stops sending events after a suspend, something isn't right in the re-initialization. So this is definitely a kernel bug bug, CC-ing benjamin. Now the second question is of course why natural scrolling doesn't work but here I'm deferring to plasma again. Both nodes will look like touchpads to libinput so it looks like you always have two touchpads connected. Plasma should enable natural scrolling on both, so it doesn't matter where the events come from. If you run the xinput command above against both devices before suspend, it should work just fine.
Please add the dmesg from the system right after the suspend/resume. Let's try to see if the i2c-hid device has trouble while resuming.
Created attachment 127701 [details] dmesg output upon resuming from suspension
Anything else I can provide at this time?
In the log, it appears that the PS/2 node is re-enumerated. This is bad given that it will then reset the touchpad and force it to switch back to PS/2. I think it's already the third device I see with this type of issue, so I'll need to work on a generic solution for that.
Just checking in case of news related to this. Still need to suspend + wake (+ unlock) after each log-in and each TTY-change, in order to get the trackpad working right. libinput 1.7.3 linux 4.11.6 xf86-input-libinput 0.25.1
After further research, it seems we are missing a specific driver for this device over i2c: https://patchwork.kernel.org/patch/9702455/ I'll ping on the patch series and see if there are some updates.
(In reply to Benjamin Tissoires from comment #24) > After further research, it seems we are missing a specific driver for this > device over i2c: https://patchwork.kernel.org/patch/9702455/ > > I'll ping on the patch series and see if there are some updates. Ooh, a promising discovery! Any tasty info since June?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/issues/4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.