Scrolling vs mid-button dragging

[rainwoodman]

I know this has been around for awhile. I tried to decipher various issues around middle key and scrolling but not sure which one is still relevant. (Things seem to have changed quite a bit).

The scrolling events sent to inkscape produce choppy movements, making it hardly usable. Although several users in the issue reports suggested it is useable in a webbrowser (Chrome was mentioned) The true middle-key dragging is a lot smoother.

Is there a way to disable the keyboard's (built-in) translation from middle-key dragging to scrolling? It was mentioned in one issue that the translation is built into the hardware of the keyboard.

native-mouse-disable can disable the scroll events, but it also disables dragging -- the click itself seems to go through fine, but mouse-movements when the middle key is presses are disabled. Is this disabled by the hardware or by the driver?

[lentinj]

I know this has been around for awhile. I tried to decipher various issues around middle key and scrolling but not sure which one is still relevant. (Things seem to have changed quite a bit).

Yeah, there were several revisions of the Linux support, each with their own quirks. Linux 4.3+ should be reasonably usable though, and things haven't changed since. You shouldn't need the userland utilities here apart from for historical interest.

The scrolling events sent to inkscape produce choppy movements, making it hardly usable. Although several users in the issue reports suggested it is useable in a webbrowser (Chrome was mentioned) The true middle-key dragging is a lot smoother.

What do you mean by choppy? It's never going to be as good as a "real" trackpoint unfortunately, but it's not too dissimilar. You are restricted only horizontal or vertical movement, and the acceleration profile is rubbish. But I've found it's usable.

The not-so-fine control is going to be noticeable in Inkscape far more than Chrome, given the nature of what you're doing there.

Is there a way to disable the keyboard's (built-in) translation from middle-key dragging to scrolling? It was mentioned in one issue that the translation is built into the hardware of the keyboard.

No. This is the crux of the problem. The keyboard tries to be clever and does it's own scrollwheel-emulation, which means when the middle button is held down, you only get very low-resolution scroll events instead of raw X/Y movement. AFAIK there's no way around this beyond rewriting the keyboard's firmware.

One option you'll find somewhere in the issues here is using the right mouse button instead for scrolling. Enable "Evdev Wheel Emulation" and set "Evdev Wheel Emulation Button" to 3 (using xinput). Not sure how easy it is to "reprogram yourself" to adapt, but you could see if it works out for you.

native-mouse-disable can disable the scroll events, but it also disables dragging -- the click itself seems to go through fine, but mouse-movements when the middle key is presses are disabled. Is this disabled by the hardware or by the driver?

The hardware. native-mouse-disable isn't what you want. This option modifies what HID event is sent by the keyboard for the middle mouse button---a standard middle button event or a vendor-specific middle button event. The option turns on/off the standard middle button event, and Linux just uses the vendor-specific one. The scroll events (and no X/Y) is the same regardless.

The Kernel disables the standard event by default as vendor-specific middle-button-down event comes as the middle button is actually pressed down. The standard middle-button-down only comes after a button press without any movement. The Kernel driver then emulates Xorg's decision process as to whether the middle-button-down event was the start of a scroll or an actual middle button.

[rainwoodman]

Hi, I recently ran into a similar issue in Windows on the internal trackpoint on a T440.

This post mentioned using the Synaptics driver solves the issue:

https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Trackpoint-middle-button-dragging-still-not-working-in-Ultranav/td-p/985625

Is it possible there is a secret command string that was not ever triggered by the Lenovo driver? (Because they fail to properly set the mode even for the internal trackpoints, which worked fine on linux)

Are there any possible inspirations from the driver of the internal trackpoint?

[lentinj]

I can see why that solves it there, since for any Lenovo laptop keyboard/trackpoint I've known (the T440 included, look at the xinput output), the trackpoint uses the same PS/2 interface it's always used since the heady IBM days, and the middle-button functions are done in software. Ripping out the Lenovo driver gets rid of the various middle-button-handling routines that the driver has.

Investigating other keyboards is certainly a sensible line of thought, but my guess is that Lenovo contracted some keyboard company to make the firmware for these keyboards, and the commands more closely resemble the other bluetooth keyboards they make. But of course these won't have trackpoints, and very unlikely to have middle mouse buttons.

It's easily possible there's secret commands that the Lenovo windows driver isn't using, but then if they're secret how do you know what they are? I've and another person have tried blatting entire ranges of 3 byte commands to see what happens and neither of us made the keyboard do anything. The other option would be disassembling the firmware and poking around to find the bit of code that interprets incoming commands (at least the BT keyboard has an ARM M3 core which will be interpreting these commands). But I'm not sure if Lenovo have published firmware images.

Which keyboard are you using out of interest? Bluetooth or USB?

[amosbird]

What do you mean by choppy? It's never going to be as good as a "real" trackpoint unfortunately, but it's not too dissimilar. You are restricted only horizontal or vertical movement, and the acceleration profile is rubbish. But I've found it's usable.

Well, how can I get the "real" trackpoint like behavior?

[JayFoxRox]

Just a heads up: https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/ - this fixes it by modifying the firmware.

I originally wanted to do the same and only found that project when disassembling the ROM (which I dumped from a USB trace of the 3.30 firmware upgrader).

As part of my original effort, I did look into the USB protocol and could potentially come up with a cross-platform flasher software. However, I probably won't work on it unless someone would actually benefit from it. The only other feature that I'm personally interested in is to expose Fn as a proper button (which might already be possible somehow), to re-enable the scrolling logic while Fn is held. But that's a minor issue so I don't consider myself a stakeholder.