ruundii / bthidhub

Bluetooth HID hub
MIT License
309 stars 51 forks source link

A1314: command key #2

Closed mcmara closed 4 years ago

mcmara commented 4 years ago

Fantastic idea! Thank you for sharing this unique work. I have paired a A1314 keyboard and it works. However, the option and command keys seems swapped (option acts as command). Is it possible to correctly remap the command key?

Edit: host is macOS; tried also to report to the host using the default filter but in such case it does not seem to work?

ruundii commented 4 years ago

thank you for trying it out! Indeed, I have swapped the option(alt) and command to bring it to the Surface book layout. It is easy to change. This is the code which swaps left option(alt) and command This is where I substitute right command key for right alt This is where right option(alt) is turned into an 'application key' press If you comment out those lines, then it will be the default behavior.

You also mentioned that your host is MacOs. With the current implementation, you will miss the functionality of some of the top buttons (volume ups, player controls etc). This is because the hub presents itself as a standard keyboard, which does not have these buttons (or maybe has some of that, but I still remap those to F1-F12 keys, as this is my preference). If this is the problem, there are a couple of directions to explore. The general approach to such a problem would start with understanding a little bit about hid descriptors, e.g. by reading this and then getting to use some utilities, like hid-tools

Then, say, you want a certain key to work in a certain way in your OS. There are three possible options:

1) The current HID descriptor already declares that it can output the such key (usage). Then you just need to remap - i.e. modify the filter code to output this event.

2) The current HID descriptor does not declare that it can output this key(usage), but this usage is in the standard HID usage tables. Then you need to modify the hid descriptor and filter code.

3) The key is vendor specific and is not in the HID usage tables. If you desperate to make it work, then you need to make the hub pretend it is actual apple device. Then the OS will use vendor-specific driver to process the vendor specific key for this HID event. I haven't tried it yet, but from what I know to do this, you should set vendor/product id to be the same as apple keyboard in /etc/bluetooth/main.conf file (DeviceID property). and then you need to set the hid descriptor in sdp_record.xml to be the same as the one of apple keyboard (I actually have sdp_record_apple.xml file in the project where it is done). After this, while using default hid filter, the messages should flow as is. and then if you still want any remapping - just create your own filter.

A slightly separate case is when you, for some reason, want some keyboard keys to behave differently in different host OSes. You can address it with OS level remapping. Most likely you will be able to map to anything that has a keycode in your OS. But some function keys e.g. turn keyboard backlight on, or increase brightness, may not have keycodes and you won't be able to remap those on OS level.

Also, technically you may even modify the BT HID hub code for it to produce slightly or completely different HID reports for different hosts, but this is likely to be far from being an elegant solution.