[haiku-development] Re: magic keyboard driver

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 18 Aug 2010 22:50:43 +0200

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

Other related posts: