Certain keys not being passed through about go-hidproxy HOT 7 OPEN

Hey, I tried to map all the special keys (the special key codes are defined in the Bluetooth spec, but there are a lot of kind ambiguous keys). If you run the binary with -loglevel debug, you should be able to see what codes go-hidproxy is receiving from the keyboard. The logical scan codes can be found in this document (section 10): https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf

from go-hidproxy.

Hello,

Thanks very much for the rapid and helpful response. If I may ask, how do I run the binary with log level debug? I may say that I know nothing about Linux, the instructions on the main page were clear enough to follow and that's the only reason I got it working, so I would really appreciate the options to run the binary and see the codes. I would also be grateful to know where, once the codes are known, I can map them to the USB inputs.

Thanks again,

from go-hidproxy.

You can turn on the debug log level by editing the file /etc/systemd/system/hidproxy.service and changing this line from:

ExecStart=/usr/sbin/go-hidproxy

to:

ExecStart=/usr/sbin/go-hidproxy -loglevel debug

Then run:

# systemctl daemon-reload
# systemctl restart go-hidproxy

You can follow the log files with:

# journalctl -u go-hidproxy -f

The scancodes are defined in the source code at: https://github.com/rosmo/go-hidproxy/blob/main/cmd/go-hidproxy/main.go#L38 (in the format of incoming code : outgoing code).

You should see in the logging output something like (the scancode is the important one):

Key event: scancode=X, keycode=Y, state=Z

from go-hidproxy.

Hi,

Thanks for your answer, I think you actually did map the the keys, but for some reason the program says unknown when it sees them. For example, the delete key is shown as mapped in the log...

{105 KEY_LEFT} {106 KEY_RIGHT} {107 KEY_END} {108 KEY_DOWN} {109 KEY_PAGEDOWN} {110 KEY_INSERT} {111 KEY_DELETE} {113 KEY_MIN_INTERESTING} {114 KEY_VOLUMEDOWN} {115 KEY_VOLUMEUP} {116 KEY_POWER} {117 KEY_KPEQUAL} {119 KEY_PAUSE} {121 KEY_KPCOMMA} {122 KEY_HANGUEL} {123...

It seems to see that key 111 should be delete. However, when it sees the delete key pressed by the keyboard, it says:

May 22 02:12:23 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:23+01:00" level=debug msg="Keyboard input event: type=4, code=4, value=458828"
May 22 02:12:23 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:23+01:00" level=debug msg="Keyboard input event: type=1, code=111, value=1"
May 22 02:12:23 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:23+01:00" level=debug msg="Key event: scancode=111, keycode=0, state=1"
May 22 02:12:23 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:23+01:00" level=warning msg="Unknown scancode: 111\n"
May 22 02:12:23 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:23+01:00" level=debug msg="Keyboard input event: type=0, code=0, value=0"
May 22 02:12:24 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:24+01:00" level=debug msg="Keyboard input event: type=1, code=111, value=2"
May 22 02:12:24 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:24+01:00" level=debug msg="Key event: scancode=111, keycode=0, state=2"
May 22 02:12:24 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:12:24+01:00" level=warning msg="Unknown scancode: 111\n"

Similar things happen with quite a few other keys. it shows their scancodes in the log, but says "unknown scancode", even though it does look like it knows what they are. Just for example, play/pause is mapped as key 164 but when it sees that from my K380, it says:

02:10:57 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:10:57+01:00" level=debug msg="Keyboard input event: type=1, code=164, value=0"
May 22 02:10:57 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:10:57+01:00" level=debug msg="Key event: scancode=164, keycode=0, state=0"
May 22 02:10:57 raspberrypi go-hidproxy[3515]: time="2021-05-22T02:10:57+01:00" level=warning msg="Unknown scancode: 164\n"

This only seems to happen with some keys, not with the regular keys (except delete), but with the media/browser control keys. I have uploaded a log of my starting journalctl and pressing delete a few times so that, in case I didn't paste in the right lines to confirm the issues, you can see the entire log.
delete.txt

Thanks again for putting up with my lack of knowledge on this and for your work.

from go-hidproxy.

Hi,

Sorry to respond to this again, but there are two keys which may be worth mapping for the Logitech K380. These have been tested and work here

111: 76, //delete
127: 101, // Applications

I would submit a pull request but, as I said, don't know what I'm doing in terms of coding and don't want to cause any problem with the formatting of the code. I'm not sure what that list of keys was that I saw in the log, but it doesn't seem to be a list of mapped keys.

Thanks again for your work on this.

from go-hidproxy.

The code 127 is already mapped to Right-Cmd (Right-Windows key), so that's a bit weird. I've added the delete now.

from go-hidproxy.

Hi,

I found that odd, too. When the keyboard is connected to a bluetooth device, hitting 127 does "applications" which is why I changed it. This may well be a weird thing only for the K380 and maybe other logitech keyboards. I don't have a logitech keyboard with a right windows/right CMD key, so can't test to see what key code logitech puts out for that key.

from go-hidproxy.