Middle-Click Timeout, even if no scroll event was triggered

[white-gecko]

Is it possible to have the middle-click event to timeout?

I have a USB Keyboard and patched my kernel (4.2.6, debian jessie backport) with the patch proposed in #23 (https://lkml.org/lkml/2015/8/11/742). The scrolling works very good and a middle-click is only triggered when the TrackPoint was not moved (Thank you for your work so far!).
But still sometimes I press the middle button in the intention to scroll, but decide to not scroll after a while :-)

Wouldn't it be a good idea, to still let the middle-click event timeout i.e. don't send the middle-click event after releasing the middle-button after some timeout, even if the TrackPoint wasn't moved. I think this would be the same behavior as on the internal keyboard. (I think the middle-button on the internal keyboard goes to some long-click, behavior in the meantime, which doesn't seam to be possible with the external version.)

Or is it even possible to configure this behavior in the X.org config?

[lentinj]

Weird, I always thought you get a middle button press with a "normal" trackpoint if you held it down too long. You're right, after 200ms of middle-button-press no button events are sent back, even if there's no wheel events.

This isn't configurable from Xorg, as the keyboard itself does a lot of the wheel emulation work. It'd require a kernel patch to check how long the button had been down upon release, and then send if it was short enough.

[white-gecko]

I would be happy to try out the kernel patch …

[arnuschky]

I'd be quite interested in this patch as well.

[arnuschky]

Did anyone implement this yet? If not, @lentinj any pointers where I should start if I wanted to have a look myself?

[lentinj]

On button down (http://lxr.free-electrons.com/source/drivers/hid/hid-lenovo.c#L346) we need to note the time in ms that button-down happened. Then on button up (http://lxr.free-electrons.com/source/drivers/hid/hid-lenovo.c#L348) we need to only send button events if cptkbd_data->middlebutton_state == 1 and less than 200ms has passed.

It should be fairly easy to do, but I'd forgotten about it.

[arnuschky]

Thanks. On what code basis should that happen? I am a bit confused wrt to the patches in this git and whether they have been integrated into the kernel. I assume it's customary to provide patches to the latest stable release?

[lentinj]

I am a bit confused wrt to the patches in this git and whether they have been integrated into the kernel.

I add the patches to this repo as soon as they're accepted upstream, and all have gone into released kernels now. The code in this repo is mostly historical interest at this point.

I assume it's customary to provide patches to the latest stable release?

Depends on how quickly things change in that subsystem I believe. This driver isn't exactly fast-changing, so the latest stable should be fine.