I'm not sure if this is the right place for this bug. I was pointed here by someone in #gnome-shell. My setup: Gnome 3.16 on Xorg with a Logitech Marble Mouse Trackball. The problem: The Marble Mouse has 4 buttons and a trackball, no scrollwheel. I always emulated scrolling with this xorg.conf: Section "InputClass" Identifier "Marble Mouse" MatchProduct "Logitech USB Trackball" Option "EmulateWheelButton" "8" Option "EmulateWheel" "true" Option "XAxisMapping" "6 7" Option "Emulate3Buttons" "on" Option "Emulate3Timeout" "1000" EndSection So the small left button initiates scrolling when held down or just sends a keycode when clicked. I use it for backwards navigation in the browser. When I updated Gnome to 3.16 I couldn't use the scrolling and noticed a 1 second delay between pressing a mouse button and the corresponding ButtonPress event. After some googling I found I can get the scrolling back by issuing `gsettings set org.gnome.desktop.peripherals.trackball scroll-wheel-emulation-button 8` So Gnome chooses to ignore the xorg.conf for some reason. I got the drag working properly by installing xf86-input-libinput. But then the scrolling ceases to work. So I can currently choose between drag'n'drop working as expected and scrolling working as configured. I tried creating an xorg.conf using the libinput settings (ScrollMethod and ScrollButton) which lead to X not restarting properly. TL;DR version: xorg.conf -> no scrolling, ButtonPress delayed xorg.conf + gsetting -> scrolling, ButtonPress delayed xorg.conf + gsetting + libinput for X -> no scrolling, ButtonPress instant
Note that the above xorg.conf won't work for libinput since these are evdev-specific options. You'd have to change it for different options (see man libinput(4)). But if you have the gsettings enabled anyway, that should be enough. Pls run xinput list-props <device name> after enabling the emulation and post the output here.
Couple more questions: what version of libinput/xf86-input-libinput do you have? Pls attach the output of evemu-describe here (mostly just for my device collection). What do you mean by "drag" in this context? libinput's behaviour, if the button is set, is to either let the click through if it was released within a certain timeout or to convert any device movement into scroll events while the button is down (which will eat the button event). You can't have dragging with the scroll button.
I tried writing a libinput xorg.conf, which resulted in X not starting any more. Probably made a mistake somewhere. $ xinput list-props 2 Device 'Virtual core pointer': Device Enabled (150): 1 Coordinate Transformation Matrix (152): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 By drag I actually mean any action involving a ButtonPress event. Like press and hold the primary button. I'm not trying to drag with the scroll button. I have libinput 0.13.0 and I don't currently have xf86-input-libinput installed, as I can't scroll with the button then. Of course I could still grab the scrollbar and drag it around, but that's tedious. xf86-input-libinput is current available in verison 0.8.0.
Just to clarify: without xf86-input-libinput installed I get a ButtonPress and ButtonRelease event simultaneously if I click the primary button. If I hold it it takes about 1 second for the ButtonPress event to trigger. The ButtonRelease event is then triggered as soon as I release the button. With xf86-input-libinput installed The primary button behaves correctly, but button 8 doesn't act as ScrollButton. Probably because it's simply not configured.
OK, I've toyed around a bit and noticed the xinput props I posted earlier were rather incomplete. Device ID and device name can't be used interchangeably. $ xinput --list-props Logitech\ USB\ Trackball Device 'Logitech USB Trackball': Device Enabled (150): 1 Coordinate Transformation Matrix (152): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Accel Speed (284): 0.000000 libinput Natural Scrolling Enabled (285): 0 libinput Send Events Modes Available (270): 1, 0 libinput Send Events Mode Enabled (271): 0, 0 libinput Left Handed Enabled (286): 0 libinput Scroll Methods Available (287): 0, 0, 1 libinput Scroll Method Enabled (288): 0, 0, 1 libinput Button Scrolling Button (289): 8 Device Node (272): "/dev/input/event3" Device Product ID (273): 1133, 50184 Here's the xorg.conf I currently use: Section "InputClass" Identifier "Marble Mouse" MatchProduct "Logitech USB Trackball" Driver "libinput" Option "ScrollMethod" "button" Option "ScrollButton" "8" EndSection The ScrollButton is set, but ScrollMethod seems to be ignored, which would imply it's not applicable for trackball devices. However setting it manually with `xinput --set-prop Logitech\ USB\ Trackball --type=atom ScrollMethod button` works and results in the desired behaviour. Now I get $ xinput --list-props Logitech\ USB\ Trackball Device 'Logitech USB Trackball': Device Enabled (150): 1 Coordinate Transformation Matrix (152): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Accel Speed (284): 0.000000 libinput Natural Scrolling Enabled (285): 0 libinput Send Events Modes Available (270): 1, 0 libinput Send Events Mode Enabled (271): 0, 0 libinput Left Handed Enabled (286): 0 libinput Scroll Methods Available (287): 0, 0, 1 libinput Scroll Method Enabled (288): 0, 0, 1 libinput Button Scrolling Button (289): 8 Device Node (272): "/dev/input/event3" Device Product ID (273): 1133, 50184 ScrollMethod (559): "button" (560) So it appears that ScrollMethod is applicable, but not parsed from the xorg.conf
Apparently I was too quick to judge. Now, even after a reboot, the xorg.conf works as desired without any manual intervention necessary. I probably should've read more. Sorry for bothering you.
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.