Am 18.08.2010 22:24, schrieb Michael Lüftenegger:
Hi! I am studing all the keyboard stuff with key codes and so on for some days now and I have got an idea for a keyboard driver that should be able to support nearly all kind of special keys modern keyboards offer. I have got a Logitech G11 with 18 G-Keys which are customizable under windows. I want to make them working under haiku. From key code point of view there are just values allowed from 01 to 127. Keyboard with more keys are solving this problem with a second keyboard. My G11 has 2 entries in /dev/input/keyboard/usb and the special keys are sending keycodes of the keys F1 to F12 and some others. The keyboard driver doesn't care about the hardware keyboard which is sending the code(it just sees 0x02 for F1 for example), so there is no way to catch those keys in the mapping app. This is the point where my magic driver comes in play. My driver reads a config file and allows to change the keycode depending on the hardware it is comming from. On one hand the config file defines the default keycodes and on the other hand it allows the maniplation of key codes if they are comming from a certain device. Example: My G11 keyboard represents 2 keyboards to the computer. Let's call them LG11_NORMAL which handles the normal 105 keys of the keyboard and LG11_GAME for the 18 gamer keys. The config file defines the default "keycode remapping" # default mapping for all keyboards # The first value is the value comming from the device # and the second value is the value the driver is giving to the system DEFAULT: 0x01:0x01 0x02:0x02 ... # rewriting for logitech G11 G-Keys LG11_GAME: 0x02:0x80 0x03:0x81 ... This is keycode rewriting and doesn't have to do anything with mapping of keyboard layout. Now In the mapping app the G-Keys are received as a seperate keycode and can be mapped differently than F1, F2 and so on. PROS: + With just some config writing any kind of keyboard should be supported by haiku. + Even gaming mice with all their special keys represent a keyboard to the computer and should be supported with this system. CONS: - Because of rewriting the driver is a bit slower. - The standard says key codes have to be between 01 and 127. This rewriting has to support values out of this range(>127). The system and the mapping app have to support them too. Some points I have fixed till now: 1. It's not possible to make just one config file for the driver. There should be one file for each keyboard. Otherwise the driver have to load all the configs even for devices that are not connected to the computer. 2. The mapping app (Keyboard layout mapping) needs to offer a mapping for each keyboard not just one global mapping like it is now. This way it would be possible to mapp a gaming mouse too for example. Let's say all this is OK for a moment. The second part of my plan is to write an app which allows to listen for an keystroke and bind some action to it(For example the execution of an file or the playback of an recorded macro(combination of key strokes.)) This is the functionality the G11 Software offers on windows. It even support Profiles for apps. So one key can have different functionality depending on the app which has the focus. That's my idea. I hope my english is good enough to communicate my "vision". What do you think about it? Let's discuss what's good or not and how it could be improved.
Different keymaps per hardware keyboard is an idea I have liked and advertised since a long time. My vision was to create a single preference application for "Input" devices, which would present the attached devices, and display the configuration GUI (which would be mostly the refactored code from the existing preflets) depending on which device is selected. I never got far in implementing this idea and pretty much the only change I did was to give each input_server keyboard device instance it's own copy of the keymap. The only fundamental difference I see in your proposal is that key codes can be greater than 127, but I believe they are stored in the key event BMessage as int32 ("key"), so it wouldn't be a problem. I don't envision the need for a separate driver. Rather the existing input_device add-ons should look up their settings (keymap, state of modifier keys) based on the device name exported by the driver (mechanism needs to be added, perhaps). And the preference application needs to write those separate settings files of course, or perhaps even one settings file with sections per device... a matter of taste. The second part of your plan already exists in the repository and on the image in the form of the "Shortcuts" preflet. It's just in desperate need of some love (bugfixing, polishing, big GUI cleanup).
What do you think about that? Best regards, -Stephan