Closed pasdVn closed 9 years ago
This one? https://www.csl-computer.com/shop/product_info.php?products_id=9176
That --fn-lock-enable
worked with your keyboard (if that's what you're saying) is interesting, and possibly shows a shared pedigree in the bluetooth chipsets.
The HID Vendor/device ID matches a Samsung keyboard:- http://forum.xda-developers.com/showthread.php?t=2418387 http://www.a4c.com/product/samsung-galaxy-tab-10-1-bluetooth-keyboard-case-bkc-1b1-black.html
...but if it's a no-name keyboard they could have "borrowed" Samsung's vendor/device ID, instead of this actually being a Samsung keyboard. The keyboard certainly doesn't report a specific name. It doesn't seem that sensible to add it to the script as something it recognises. None of the commands I know of result in any responses from the keyboard, so one can't speculatively send commands and see what comes back.
I am using a bluetooth keyboard that is sold as "CSL - Ultra Slim Bluetooth Tastatur" in germany (probably some rebranded stuff that is merchandized under a lot of different names).
This keyboard has an Fn-key that is not working with vanilla linux. Additionally Esc an all F[0-9]+ keys are not working. I simply tried your udev script with a little modification (to grep the correct hid device by name) without investigating or sniffing before. Surprisingly it worked and I am abled to use all the keys including switching between ios, android and windows mode :-). So thank you a lot for your work!
Maybe there is a more generic way to identify which bt keyboard uses those commands?
I tried the script with the keyboard at two different machines and had a look at /sys/class/hidraw/hidraw*/device/uevent in the hope that those informations help:
Debian Wheezy, kernel 3.18.7:
Ubuntu 14.04, kernel 3.13.0