Problems with X..

[Dejan Lesjak]

On Friday 04 of March 2005 16:34, Matthias Muthmann wrote:
> On Mi, 2005-03-02 at 20:10 +0100, Dejan Lesjak wrote:
> > Just the ones that don't work (if they are consecutive in the row, only a
> > range would be fine). I'm also interested in whether without these
> > patches applied - was the row in question behaving the same as the other
> > keys (ie codes generated being off by one) or was it behaving differently
> > even then?
> >
> >
> > Dejan
>
> Ok, now I tried X without your patches. The lowest row behaves in the
> same way as with your patches:
> e.g. keycode 198 (keysym 0x0, NoSymbol)
> But the keycodes are shifted by one (Y is 191, not 190 ...)

I see, this should eliminate concern that previous patches remapped last line 
to weird codes... Digging a bit through this I hope that we're at least a bit 
closer to something. I think we could use the mapping for wsconsole for sun 
keyboards: Looking at keycodes we should get (this is a type5 keyboard, 
right?) in /usr/X11R6/lib/X11/xkb/keycodes/sun - for de layout of type5 
keyboard key Y is <AB01> so the code should be 107. Now before mapping in 
driver (for which these patches are) is converted to this code, MIN_KEYCODE 
(defined as 8 in this case) is added to scancode, so that one should be 99. 
As we already subtract 1 before addition of MIN_KEYCODE, scancode should be 
100 or 0x64, which is what we have in wsSun map in bsd_KbdMap.c.
Anyway... if my rambling above is correct, this is what you could try: of 
previous patches keep only patch-kbd_sparc_2.c (remove patch-bsd_kbd.c and 
patch-bsd_KbdMap.c) and add the patch here:
http://www.ijs.si/~lesi/xorg/patch-bsd_KbdMap.c.2
Better? Worse? Horrible?


Dejan