Bug 98099

Summary: kernel: Disabled "natural" scrolling doesn't take effect until laptop is suspended
Product: xorg Reporter: andykluger
Component: Input/libinputAssignee: Benjamin Tissoires <benjamin.tissoires>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: andykluger, benjamin.tissoires, peter.hutterer
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output upon resuming from suspension none

Description andykluger 2016-10-05 17:11:38 UTC
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).
Comment 1 Peter Hutterer 2016-10-06 12:31:49 UTC
(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
Comment 2 andykluger 2016-10-06 16:28:06 UTC
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.
Comment 3 andykluger 2016-10-06 16:40:34 UTC
I've created a bug on the KDE tracker: https://bugs.kde.org/show_bug.cgi?id=370202
Comment 4 Peter Hutterer 2016-10-06 17:19:19 UTC
yep, that'll be somewhere in the the system settings then
Comment 5 andykluger 2016-10-06 19:11:42 UTC
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?
Comment 6 andykluger 2016-10-06 19:24:00 UTC
Ah, correction: Those commands _do_ work, but only after doing the suspend-wake dance.
Comment 7 Peter Hutterer 2016-10-08 07:01:47 UTC
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
Comment 8 andykluger 2016-10-11 16:30:03 UTC
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.
Comment 9 Peter Hutterer 2016-10-13 07:11:59 UTC
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.
Comment 10 andykluger 2016-10-13 16:24:37 UTC
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.
Comment 11 Peter Hutterer 2016-10-14 04:10:37 UTC
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?
Comment 12 andykluger 2016-10-14 20:24:24 UTC
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.
Comment 13 Peter Hutterer 2016-10-18 04:30:01 UTC
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.
Comment 14 andykluger 2016-10-20 20:25:43 UTC
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.
Comment 15 Peter Hutterer 2016-10-24 23:34:08 UTC
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.
Comment 16 andykluger 2016-10-28 17:51:17 UTC
> 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.
Comment 17 andykluger 2016-10-28 17:55:05 UTC
Actually, you're probably interested in this in particular:

/dev/input/event7:      ALP0011:00 044E:120C
/dev/input/event9:      AlpsPS/2 ALPS GlidePoint
Comment 18 Peter Hutterer 2016-10-30 22:39:30 UTC
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.
Comment 19 Benjamin Tissoires 2016-10-31 14:10:20 UTC
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.
Comment 20 andykluger 2016-11-02 17:39:15 UTC
Created attachment 127701 [details]
dmesg output upon resuming from suspension
Comment 21 andykluger 2016-11-16 18:40:37 UTC
Anything else I can provide at this time?
Comment 22 Benjamin Tissoires 2016-11-17 09:11:35 UTC
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.
Comment 23 andykluger 2017-06-22 16:48:06 UTC
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
Comment 24 Benjamin Tissoires 2017-06-23 08:13:50 UTC
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.
Comment 25 andykluger 2017-09-11 22:32:52 UTC
(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?
Comment 26 GitLab Migration User 2018-08-10 20:56:35 UTC
-- 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.