Cannot output mouse keys

[neelkamal0310]

Hi, I have these two bindings in my touchcursor.conf which do not seem to work. Took the keys from here.

KEY_I=KEY_SCROLLUP KEY_K=KEY_SCROLLDOWN

with hyper being: HYPER1=KEY_SPACE

I tried testing this with xev. While other keys show their mapping when pressed, these two do not register the mapped keys.

I want to use scroll up and scroll down instead of the up and down arrow key for I and K. Tried using BTN_4 and BTN_5. They do not seem to work as well.

[Adda0]

You are right. Mouse buttons do not work at all. If I am not mistaken, that would require additional implementation of handling mouse keys – it is not just a simple bug, I believe. It would be a nice feature to add, though.

[donniebreve]

@neelkamal0310 this was an issue with some keys missing in the keys.c parsing code. KEY_SCROLLUP / KEY_SCROLLDOWN were being mapped to nothing since they were missing. After adding these keys though, they don't seem to do anything for me.

Are you able to pull down the scroll-keys branch and test?

[neelkamal0310]

It seems the keys registered by KEY_SCROLLUP and KEY_SCROLLDOWN are XF86ScrollUp and XF86ScrollDown respectively and not the button 4 and button 5 of the mouse which is used for scrolling. Other mouse buttons seem to work fine.

i tried looking for the input event codes for those buttons here but could not find them.

The input codes reported by xev in my system are 0x810 for button 4 and 0x1010 for button 5.

[Adda0]

Yeah, KEY_SCROLLUP/KEY_SCROLLDOWN do not work for me either. I get the same input codes from xev as @neelkamal0310, but these seem to not work if applied instead of the default Linux input event codes as well.

[neelkamal0310]

A quick workaround is to map XF86ScrollUp and XF86ScrollDown to a command to execute the mouse clicks with xdotool via xbindkeys or a similar key bind tool (or through the window manager bindings).

For xbindkeys this worked for me and showed expected behaviour.

"xdotool click 4"
XF86ScrollDown

"xdotool click 5"
XF86ScrollUp

[donniebreve]

I believe @neelkamal0310's overall issue is not an issue with touchcursor-linux. If that's not correct please feel free chime in.

touchcursor-linux is taking the key code it knows of as KEY_I and translating that to the key code it knows of as KEY_SCROLLUP. The key codes are defined in input-event-codes.h. This translation happens after udev gives your input keyboard a scan code to key code mapping, and before any X11 layouts or bindings (where the KEY_SCROLLUP -> XF86ScrollUp translation is happening). KEY_SCROLLUP/DOWN do nothing for me by default. Whether your X11 configuration does anything with KEY_SCROLLUP is up to you. Because of this, I am a little confused where we're talking about the input codes reported by xev. In the KEY_I=KEY_SCROLLUP case, xev should report KEY_SCROLLUP(0xb1, 177) as they key code. Is that not the case?

Regarding BTN_4 and BTN_5, those also do nothing for me by default. Originally I thought you were referring to the side buttons on the mouse (for example, the thumb buttons on a Logitech MX Master), but those buttons are typically interpreted as backward/forward in applications. I've confirmed that with the key code mapping fix in scroll-keys the application can output mouse buttons (verified by using KEY_Y=BTN_SIDE, KEY_N=BTN_EXTRA and viewing the backward/forward behavior in VSCodium). Could you please provide more clarification on BTN_4 and BTN_5?

Something that might help @neelkamal0310 is for touchcursor-linux to support configuring key codes not defined in input-event-codes.h. That's something I would consider looking at. (maybe NUMBER=KEY_...)

[neelkamal0310]

@donniebreve Yes, it doesn't seem to be a problem with touchcursor-linux.

In the KEY_I=KEY_SCROLLUP case, xev should report KEY_SCROLLUP(0xb1, 177) as they key code. Is that not the case?

With KEY_I=KEY_SCROLLUP, this is what xev reports for me:

state 0x10, keycode 185 (keysym 0x1008ff78, XF86ScrollUp), same_screen YES,

Similarly when KEY_I=KEY_VOLUMEUP (keycode 115), xev reports

state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,

That's because keycodes in X11 are 8 larger than the ones defined in the header file. Source. When tested in a console they register their expected keycode i.e. 115 for KEY_VOLUMEUP or 177 for KEY_SCROLLUP and so on.

Could you please provide more clarification on BTN_4 and BTN_5?

BTN_0 to BTN_9 seem to do nothing for me as well. They are not even reported by xev but are detected in a console(tty) with showkey --keycodes. So I believe those buttons are entirely skipped by Xorg. I originally thought that they referred to the mouse buttons but it doesn't seem to be the case.

And yes, mouse buttons (left, middle, right and side) do work as usual when set BTN_LEFT, BTN_SIDE, BTN_EXTRA, and so on.

[donniebreve]

Thanks for your input @neelkamal0310, @Adda0, lots of good information here.

That's because keycodes in X11 are 8 larger than the ones defined in the header file. Source.

This is especially good to know. I haven't run X11 in years.

I'm going to close this issue, but please feel free to open another if you run into something else.