Preliminary OLPC xkb definitions

[Bernardo Innocenti]

Sergey Udaltsov wrote:

>> Sounds like a broken keyboard or kernel map to me.  But, regardless, why
>> not make keycodes/olpc if you really need to, and have model olpc
>> include that?
> Well, I am not in favor of creating multiple keycodes unless we have
> to. First, I'd love to get to the bottom of the problem whether it is
> a bug in evdev driver or what?

Zephaniah probably knows better, but I think it's because the OLPC
keyboard sends the same scan codes for these keys.

This is the way we were fixing it.  I added the FIXME comment to
make sure we remember to find a better workaround.

How can I selectively replace them depending on the model?
I could split the standard keycodes definition in a "evdev_basic"
one with that key removed and import it both into "evdev" and
"olpc".  Or ss there a better way?


>> This should probably be symbols/olpc, but Sergey can feel free to
>> correct me on this one.
> Well, I do not mind either way, actually. I do not know whether olpc
> should be considered as a "kind of PC" or not. Never seen it.

Our rubber keyboard certainly inherits from the PC world: it
used to be an industrial PS2 keyboard before.  And I think
it's still using the PS2 protocol, but I'm not sure about it.



>>> +    key <AK01> { [ A1  ] };
>> This sounds like a really bad set of keysym names.
> Yes, keysym A1 looks rather suspicious...

It's A for "analog" key, a little like F for "function".

We could change it to AN01, AN02... Jim Gettys is also
in favor of renaming them like this.

And we currently have three groups of 7 keys on our keyboards.

For better generality, I will rework my patch to define 30 keys
from AN01 to AN30.  On the OLPC we will only map keys AN01-AN07,
AN11-AN17 and AN21-AN27.


>> The whole patchset looks pretty sketchy to me.  And I'm assuming it
>> depends on some rules changes and also keysym additions which aren't
>> published.

Yes, I've just rebased our existing changes on latest upstream
version and made few changes to integrate better.


> Yes, as I said, I am eager to see updated rules...

Keysym patch is attached, but as I said I need to rework the
AN keys to the new scheme.

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keysymdef-analog.patch
Type: text/x-patch
Size: 3906 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070611/2ddc067b/attachment.bin>