[haiku-development] Re: magic keyboard driver
- From: Michael Lüftenegger <mlueft@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 19 Aug 2010 09:03:42 +0200
Update:
1. Till yesterday in the evening I thought the input server add-on is the
device driver. I learned it better.
=> We are talking about an add-on not a driver.
2. It is possible to connect to keyboards to one computer. For example the
G11(with special keys G11 till G24) and the G15(with special keys G1 till
G6). I think it's a good idea to be able to recognize those keys as
different keys. So we sould start a "official" list of rewritten keycodes.
So different keyboard don't interfere.
2. a) We don't know hoe the USB Keyboard standard will change in future. At
the moment it's defined from 00 till 127. On our list we should reserver a
range at the bottom end for future changes of the standard. I suggest 00
till 512.
2. b) Imagine someone is doing video editing in Haiku and for this he has
connected 2 keyboards where he want to completely rewrite the second one for
the video editing software. We should reserve a range on our list for
individual rewriting. I suggest 513 till 1024.
1025 could be the first index for "official" key code rewriting.
michael
On Thu, Aug 19, 2010 at 12:39 AM, Michael Lüftenegger <mlueft@xxxxxxxxx>wrote:
> ye, i was thinking about the devices' id to identify them.
>
>
> On Thu, Aug 19, 2010 at 12:17 AM, Paul Davey <plmdvy@xxxxxxxxx> wrote:
>
>> >
>> > 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).
>>
>> for the majority of keyboards they would be USB keyboards, wont they
>> have vendor and device IDs for the USB devices that would allow this
>> to be implemented?
>>
>> >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
>> >
>> >
>>
>>
>
>
> --
> http://www.kineticarm.com
> http://www.lueftenegger.at
> http://www.flashgameblog.at
>
>
--
http://www.kineticarm.com
http://www.lueftenegger.at
http://www.flashgameblog.at
Other related posts:
