#Beardedspice keyboard access drivers#
#Beardedspice keyboard access driver#
#Beardedspice keyboard access code#

#Beardedspice keyboard access driver#

Then the HID driver would find these devices, call these functions, and finally publish something in userspace. The devices would have functions like read_hid_descriptor, read_hid_report, write_hid_report. In the separate driver case, USB and I2C would just provide an HID bus (in the newstyle driver system) and HID devices there.

#Beardedspice keyboard access code#

But more code could be moved to the library, which ideally should be turned into a module or perhaps even a separate driver. Yes, I did the minimal effort to move the HID parsing code to a static library instead of having it copied in all drivers. USB Device and I2C Device are 99% equal, just some lines reading from usb interrupts or i2c ones. It is a hard to parse protocol designed to have a low memory and bandwidth footprint. Using HID as wire protocol has been discussed, but for me, it is a no go. I would keep consumer events as keystrokes, not the best of designs but it works that way on… all OS? We can change that on the future.I propose to stick to USB HUT codes, we already have constants for them and are collision free. (No support for usb golf irons! What a shame!). In fact, they not even all USB Consumer usages. Linux seems to use a custom scancode map not aligned with USB.

#Beardedspice keyboard access drivers#

This class not only reduces boilerplate on current input device drivers, but also allows wmi/acpi/platform drivers to send input events (brightness, rfkill…)

A kernel side helper class, lets name it InputDevice.

Yes, this is a clone of what Linux does with evdev, but to be fair it is a simple protocol on both kernel and user space side. Events are small packets with: timestamp, event type, event value.

All input drivers use the same protocol: An ioctl query returns device name, type and all events this device is capable of.Not really offtopic but… we seem to agree that Input stack needs some changes but we don’t share an opinion on what or how. We had some discussions on gerrit but it went too much offtopic. Users may then be able to just deactivate those rules and provide their own. One idea I had for the new shortcut preferences was to have a list of “default” actions provided by the system, which would be stuff like “Mail → Open application/x-vnd.Be.URL.mailto” Or user facing “Mail Button → open new draft email” PS/2 is unlikely to get a “huge” number of new keys anyhow) But i have not fixed it since the keymap doesn’t forward this currently at all, hence the idea to increase the size of the keymap structure. (I had adjusted the PS/2 Driver to forward events for keypresses of media keys, according to what osdev wiki has, there is one button i have unbound and one error in the code. Yes there are controls that are not buttons, but that seems like a bad reason to not bind any of them to buttons, all HID and non-HID media keys I have at home are actuall buttons. This should then be “easily” bound to running applications or running specific functions in applications, for example the “play/pause music” function for a media player.Īs for binding the keys to not keystrokes, I don’t know. Ideally the new preferences would take a “Press key combo now” aproach to shortcuts so it doesn’t matter that much whether the key is known or not (I mean hey, if you connect a flfire to your computer and want to bind that, why not?) That is capabilities discovered through getsuites is inacessible now. I think redisigning it is in order, especially because a huge chunk of functionality of applications. We can hardcode a list of most used ones if we want to keep shortcut preferences as it is. I also want to emphasize that consumer usages can’t be all faked as key strokes.