Button 4 and 5 emulation these silly, button-less clickpads?

Peter Hutterer peter.hutterer at who-t.net
Sat May 24 01:53:03 PDT 2014

On 24/05/2014 06:06 , Carl Worth wrote:
> Thanks to everyone who has helped to get button emulation working nicely
> on the recent line of Lenovo laptops that have no hardware buttons on
> the clickpads. This has made my machine so much easier to use.
> I've recently started using an external Lenovo keyboard that has a
> trackpoint and three hardware buttons. I've discovered that this
> keyboard has a convenient feature where clicking-and-holding the middle
> button while simultaneously pushing the trackpoint up or down causes
> events to be emitted for buttons 4 and 5. This is  convenient for
> scrolling, of course.
> I'm not sure if the previous Lenovo laptops with the hardware buttons
> had the same feature.
> But now I find myself wishing I could do the same scrolling with my
> button-less clickpad together with the trackpoint.
> For those of you with more knowledge of the code, would it be crazy to
> provide software support for this feature? I can imagine it might get a
> bit tricky with the two different input devices that are involved.
> I'd be quite pleased to see something like this developed.


short answer: more effort than expected and probably more than it's 
worth. you can enable it on devices with hardware buttons because the 
evdev driver supports it (look for wheel emulation in the man page0 - in 
the case of those particular clickpads the middle button is generated by 
the synaptics driver but the trackpoint is handled by the evdev driver. 
The two drivers don't talk to each other and making them do that would 
mean another ABI that we have to worry about - not something I'd be 
happy maintaining.

only sensible solution would be to move this into the driver and have 
the events convert there. that's easier and would then work for any driver.

we're currently working on libinput which can do things like that 
because it manages all devices and can thus do what you want it to do 
(once we implement it). right now, I defer to libinput, because for 
every hack we put into the existing drivers we lose weeks of being able 
to fix this properly.


More information about the xorg-devel mailing list