Hello, I am trying to migrate from evdev configuration which works fine recent years to libinput configuration. Functionality: When middle bottom is pressed and primary pointer is moved up/down a scroll events are sent, while if bottom is pressed shortly it acts as middle button (paste). Use cases: 1. Track point support: middle button + movement in trackpoint = scroll 2. Any mouse configuration, in this case the track point is exposed to the Linux as USB tablet mouse, however, functionality should remain. The current evdev configuration which is working fine: --- Section "InputClass" Identifier "MyMouse" MatchProduct "VirtualBox USB Tablet" MatchIsPointer "on" Option "EmulateWheel" Option "EmulateWheelButton" "2" Option "EmulateWheelInertia" "500" EndSection --- I tried the following configuration, with and without the ScrollMethod properties: --- Section "InputClass" Identifier "MyMouse" MatchProduct "VirtualBox USB Tablet" MatchIsPointer "on" Option "NaturalScrolling" "true" Option "ScrollMethod" "button" Option "ScrollButton" "2" EndSection --- However, I get no affect in xinput, nor do I see difference if I manually set "libinput Natural Scrolling Enabled" property. Refer to bug#93617 in which we previously also discussed this for evdev, please note bug#93617 comment#25 for the alternative to make absolute device scroll user friendly, per the distance of the pointer from the base point. Thanks!
Created attachment 139799 [details] udevadm-info.txt
Gentoo system dev-libs/libinput-1.10.7 x11-drivers/xf86-input-libinput-0.27.1 x11-base/xorg-server-1.19.5-r2 x11-base/xorg-x11-7.4-r3 libinput list-devices --version 1.10.7
Created attachment 139800 [details] libinput-list-devices.txt
Created attachment 139801 [details] mouse-dpi-tool.txt
Created attachment 139802 [details] libinput-measure.txt
Created attachment 139803 [details] evemu-record.txt
Created attachment 139804 [details] xinput-list-props.txt
Created attachment 139805 [details] Xorg.0.log.gz
AIUI, VirtualBox should forward the events from the host. This is how the pointer motion conversion to absolute coordinates works. It has a wheel in its evemu output so one would expect that those events are passed on too. So if you configure the trackpoint for button scrolling and scroll while the device is above the virtual box window, doesn't it come out as REL_WHEEL events? Check with evemu-record inside the VM please.
(In reply to Peter Hutterer from comment #9) > AIUI, VirtualBox should forward the events from the host. This is how the > pointer motion conversion to absolute coordinates works. It has a wheel in > its evemu output so one would expect that those events are passed on too. > > So if you configure the trackpoint for button scrolling and scroll while the > device is above the virtual box window, doesn't it come out as REL_WHEEL > events? > Check with evemu-record inside the VM please. You can see this in attachment#139803 [details], search for BTN_MIDDLE. Let's revisit the configuration... I have Lenovo Thinkpad laptop with trackpoint and 3 buttons[1]. Virtualbox is running on this Laptop. There is no wheel... nor a driver on the host to emulate a wheel. As far as I can see the guest is getting the middle button click. While the button is pressed (more than n milliseconds) and the Y is changed, the scroll should be emulated. At least same as it was in evdev which works decently. Thanks! [1] https://www.google.com/search?hl=en&tbm=isch&source=hp&biw=1600&bih=767&ei=tlQLW8zvD8zfwAKdzKrwCw&q=thinkpad+trackpoint&oq=thinkpad+trackpoint&gs_l=img.3..0l2j0i5i30k1j0i24k1l7.6617.8983.0.9077.19.10.0.0.0.0.315.976.2-3j1.4.0....0...1ac.1.64.img..15.4.973....0.Rb3vcjze0W0#imgrc=dn1utdijS9yKtM:
do you have the host set up for the wheel emulation? Or what are you running this on? Clearly not linux then, I take it?
(In reply to Peter Hutterer from comment #11) > do you have the host set up for the wheel emulation? Or what are you running > this on? Clearly not linux then, I take it? in this case the host is Windows.
Windows doesn't have on-button scrolling?
(In reply to Peter Hutterer from comment #13) > Windows doesn't have on-button scrolling? Apparently, no. All I want is to have the same service as evdev and the old mouse driver to emulate the wheel.
https://lists.freedesktop.org/archives/wayland-devel/2018-May/038302.html
I'll you to test the patch in comment 15 please, thanks
(In reply to Peter Hutterer from comment #16) > I'll you to test the patch in comment 15 please, thanks sorry for my ignorance, how can I download raw mime from the mailing list archive to apply? I tried to look at your git repo and I do not see the patch there.
(In reply to Alon Bar-Lev from comment #17) > (In reply to Peter Hutterer from comment #16) > > I'll you to test the patch in comment 15 please, thanks > > sorry for my ignorance, how can I download raw mime from the mailing list > archive to apply? > > I tried to look at your git repo and I do not see the patch there. ok done, luckily copy/paste worked. I do not see any difference, what information can I provide? I wounder how come the solution is specific to virtualbox, as I expect virtualbox to tunnel wheel if available in host mouse. I expected a patch for the x11 input driver to emulate wheel if no wheel for all cases in which there is no wheel for any device that has buttons only.
Created attachment 139867 [details] libinput-list-devices.patched.txt
sorry, should've been more precise - since the patch adds a hwdb entry you need to jump through the hoops described here: https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html#hwdb If the new LIBINPUT_MODEL_ tag doesn't show up in the udevadm info output for the device, then it won't take effect. Could be that I had a typo or something too. > I wounder how come the solution is specific to virtualbox, as I expect virtualbox to tunnel wheel if available in host mouse. You're using Windows as host and in comment 14 you say that Windows doesn't do button wheel scrolling. So VB cannot tunnel anything here because on the host nothing generates wheel events. VB merely gets the button and movement events from the trackpoint, any conversion to other events must be done in the client because we cannot really convince Windows to do the right thing here. If you'd be using Linux as host I'd tell you to enable it in the host and leave the VB machine-as is. You should find that if you use a normal mouse that has a wheel, that should be forwarded as-is to the clients in the vm (and if not, that'd be a separate bug that needs to be fixed).
Created attachment 139895 [details] libinput-list-devices.patched.txt
Created attachment 139896 [details] udevadm-info.patched.txt
Created attachment 139897 [details] libinput-debug-events.patched.txt
OK, I had to refresh hwdb, opened a gentoo bug[1] to do this automatically. The udevadm info looks good: --- E: LIBINPUT_MODEL_VIRTUALBOX_USB_TABLET=1 --- The libinput list-devices also looks good, now I have: --- Scroll methods: button --- However, I do not see scroll working, see attachment#139897 [details], looks like regular middle button up/down. Thanks! [1] https://bugs.gentoo.org/show_bug.cgi?id=657000
Created attachment 139898 [details] xinput-list-props.patched.txt
right, so the patch I sent out merely makes the button scrolling *available*, it doesn't *enable* it by default. You'll have to both enable it and select a suitable button to scroll with. For trackpoints we do this automatically (hence middle scrolling works OOTB) and on some trackballs we select a button but don't enable it by default. But this is a special case here, the virtual tablet device is a generic one that forwards whatever comes in from the host so we cannot enable the button scrolling by default without likely upsetting other setups. Try with libinput debug-events --set-scroll-method=button --set-scroll-button=BTN_MIDDLE If that works, then the libinput bits are done and you now need to figure out how to get this into the session (xorg.conf snippet or if your DE supports graphical configuration for that bit, then that)
Created attachment 139899 [details] libinput-debug-events.patched.txt libinput debug-events --set-scroll-method=button --set-scroll-button=BTN_MIDDLE
(In reply to Peter Hutterer from comment #26) > right, so the patch I sent out merely makes the button scrolling > *available*, it doesn't *enable* it by default. You'll have to both enable > it and select a suitable button to scroll with. For trackpoints we do this > automatically (hence middle scrolling works OOTB) and on some trackballs we > select a button but don't enable it by default. But this is a special case > here, the virtual tablet device is a generic one that forwards whatever > comes in from the host so we cannot enable the button scrolling by default > without likely upsetting other setups. > > Try with > libinput debug-events --set-scroll-method=button > --set-scroll-button=BTN_MIDDLE See attachment#139899 [details], seems like when I press the middle button there is no event, then I move the cursor and get standard events of movement, when I release it dispatches press/release. > If that works, then the libinput bits are done and you now need to figure > out how to get this into the session (xorg.conf snippet or if your DE > supports graphical configuration for that bit, then that) My xorg configuration is outlined at comment#0, what should I change? Also see attachment#139898 [details] as far as I see it should be fine, not sure why natural scrolling is disabled, but the button scrolling is set. --- libinput Natural Scrolling Enabled (253): 0 libinput Natural Scrolling Enabled Default (254): 0 libinput Button Scrolling Button (264): 2 libinput Button Scrolling Button Default (265): 2 ---
oh, whoops. I think the button scrolling isn't actually hooked up for that type of device. Sorry about that, this will need some more effort than just the hwdb. Apparently the tests I added only checked for the option, not whether it works...
fwiw, I had a few high-priority things come in, so this will take me a while. Feel free to get started on it though.
-- 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/libinput/libinput/issues/24.
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.