FEDORA-2018-899c7219fe created by whot 2 years ago for Fedora 28

libinput 1.11 rc2, better handling of the new ALPS trackpoints

libinput 1.11 rc1, added higher trackpoint ranges, better hysteresis, better touchpad acceleration, etc.

This update has been submitted for testing by whot.

2 years ago

This update has obsoleted libinput-1.10.901-1.fc28, and has inherited its bugs and notes.

2 years ago

This update has been pushed to testing.

2 years ago

I have an external keyboard, Lenovo ThinkPad Compact USB Keyboard with TrackPoint, and with libinput-1.10.901-1.fc28, merely touching the pointer makes the cursor jump to the top left and not move. Testing now with 1.10.902-1.fc28

User Icon mattdm commented & provided feedback 2 years ago

Yeah, 1.10.902-1 has the same failure. Note that evtest seems to show completely reasonable

type 2 (EV_REL), code 1 (REL_Y), value -12
type 2 (EV_REL), code 0 (REL_X), value 1

events, even as the cursor fails to move.

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

2 years ago

Also note that the trackpoint device built into the laptop works just fine. It's only the external device that's affected.

Are you saying that you have an extra mouse and touching that one makes the cursor jump? That's very strange. Can you file a bug for this please and attach the libinput debug-events --verbose output for that sequence. I'd really like to fix that upstream before 1.11 ships.

@whot Yeah. As soon as you touch it, it jumps to the top left corner, and no manipulation of the pointer causes other movement. However, using the Logitech mouse works fine.

It's reproducable on multiple systems (by plugging in the USB keyboard). On one, I actually had three mice: there's one on the keyboard of the laptop in the docking station plus the external-keyboard mouse plus an additional Logitech mouse I plugged in to debug. Only the USB Keyboard Mouse exhibited the problem. I'll file a bug but it won't be until tomorrow evening as I have a lot of meetings during the day.

fwiw, I cannot reproduce this here with a virtual device so there's something weird about that specific device somehow. Please also attach an evemu-record of both event nodes for the USB keyboard for an interaction, just in case it decides to send absolute events or something too.

Is it possible that this update breaks global shortcuts in gnome-shell? I use a few custom key bindings like Super+X or Super+B and they have stopped working lately.

User Icon genodeftest commented & provided feedback 2 years ago

Downgrading libinput makes the global custom key bindings work again, so I think this is another regression in the 1.11 rc2 version.

Please tell me if I should open a bug report for the global keybindings issue.

genodeftest: yes please. I haven't touched the keyboard code at all so I'm a bit baffled how libinput can break it

This update has been obsoleted by libinput-1.10.902-2.fc28.

2 years ago

@whot: With libinput 1.10.902-2.fc28, global keyboard shortcuts work fine again.

Please login to add feedback.

Content Type
Test Gating
Unstable by Karma
Stable by Karma
Stable by Time
2 years ago
in testing
2 years ago

Automated Test Results