Talk:Lenovo ThinkPad X1 Carbon (Gen 5)
— I get an error when trying to do the TrackPoint Scrolling by `xinput set-prop "ImPS/2 Generic Wheel Mouse" 288 0 0` as suggested on the page:
X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 57 () Serial number of failed request: 19 Current serial number in output stream: 20
I have xorg-xinput installed. What more do I need to do?
— Try 0 0 1 instead of 0 0 0 (the page says 0 0 1):
xinput set-prop "ImPS/2 Generic Wheel Mouse" 288 0 0 1
— I tried that too, but get the same error.
— I think he refers to the libinput Scroll Methods Available property. It apparently doesn't have the same number every time. This is my working /usr/share/X11/xorg.conf.d/20-trackpad.conf
Section "InputClass" Identifier "ThinkPad TrackPoint" MatchProduct "ImPS/2 Generic Wheel Mouse" MatchDevicePath "/dev/input/event*" Option "ScrollMethod" "button" EndSection
— Oh, so obvious now that you say it. Yes, indeed it was the wrong property id. For me the command was `xinput set-prop 11 289 0 0 1`, so I assume the generic/semantic version would be:
xinput set-prop "ImPS/2 Generic Wheel Mouse" "libinput Scroll Method Enabled" 0 0 1
Fan at max speed after resume
Anyone else having this problem? There is already a thread in the forum: 
Should we update the compatibility table add a section to the page?
- Yeah, it's known. It's a kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=191181
- —This unsigned comment is by Lindhe (talk) 15:40, 12 May 2017 (UTC). Please sign your posts with ~~~~!
- The current state of the wiki page states: "There is a bug in the kernel before 4.12.4-1, causing the fans to often go on full throttle non-stop after resuming from suspend-to-ram", However this bug (and my experience) show that it may still be present on newer kernels. Should I update this section accordingly?
- Nixpulvis (talk) 18:58, 10 March 2021 (UTC)
- Of course, after updating my firmware, the problems have gone away.
- Nixpulvis (talk) 04:50, 14 March 2021 (UTC)
Hot plugging Thunderbolt dock
"The dock works nearly perfect out of the box with Kernel 4.10.13. Even hot plugging works: unplugging the dock while a display is connected just lets all the devices disappear. Replugging it later works, all the USB devices come back up automagically, thought you might need to issue a xrandr to get the display showing again (tested with Xorg based i3 setup)."
This is however not the case for me. If I unplug the dock, neither Ethernet nor USB peripherals works until I reboot the system with the dock connected. Screens still work, at least after reactivating them via xrandr.
Can someone confirm what is the case for them? Can your dock be hot plugged without issues?
I figured it out, and updated the Wiki accordingly. It was the Thunderbolt Security Level setting. Thunderbolt devices needs authorization before they can be used, apparently. Would be nice to find a way of authorizing it in the OS, since it's never a good practice to removing default security.
I don't (yet) have a TB dock to test with, but this seems to describe the solution: https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/thunderbolt.html#authorizing-devices-when-security-level-is-user-or-secure
Touchpad Tap to Click Issues
Using tap-to-click on the touchpad under GNOME (Wayland) will frequently register single finger clicks as three finger clicks causing tab / terminals to be opened or closed or text to be pasted.
--Related to https://bugs.freedesktop.org/show_bug.cgi?id=103809
Setting "Touchpad Click Method" to "Fingers" in gnome-tweak-tool seems to resolve the issue.