Re: [gtk-vnc-devel] [PATCH][RFC] Support for ExtendedKeyEvent client message

[Anthony Liguori <anthony codemonkey ws>]

Markus Armbruster wrote:
> Anthony Liguori <anthony codemonkey ws> writes:
>
>   
> > If it is true, that KEY_Q does not necessarily correspond to a 'Q' key
> > press, then I fail to see how the Linux input layer codes are any more
> > well defined the PS/2 scan codes.
> >     
>
> Either you or I are mistaken about how the Linux input layer works for
> keys :)
>
> As far as I can tell, Linux keyboard drivers map real keys to a common
> encoding of keys (the input layer key codes), which they feed to the
> input layer.  *Keys*, not key sequences, not what comes out of the
> user's keymap.
>   

Okay, let's drive down on this one then.  If I type the 'Q' key on my 
physical keyboard, the question is, will an evdev device always, no 
matter what keyboard I use, give me a KEY_Q keycode?

From what you write above, it sounds like the answer is "yes".  This is 
what I initial thought, but Gerd disagreed:

> No.  The KEY_* input layer codes don't change when you change the
> keyboard mapping.  KEY_Y means "the key between T and U", which actually
> represents 'y' with an us keyboard mapping, but if I load a german one
> it is 'z'.

So I'm confused.

> For that purpose, I propose to define a virtual keyboard that has all
> the keys of all the supported keyboards.  Client maps its own
> idiosyncratic keys to that virtual keyboard.  Guest has a driver for
> that virtual keyboard, just like it has drivers for real keyboards.
>   

VNC already provides this.  VNC keycodes provide you a keyboard that has 
every possible key and those keys are always unique.  Why would you need 
a new encoding to achieve this?  The point of the encoding I'm proposing 
is when you have a guest that doesn't know about this super keyboard and 
must contend with traditional keyboards.

Regards,

Anthony Liguori

> I further propose we steal the virtual keyboard instead of defining it
> ourselves.  I don't care where we steal it.  First thing I found was
> the virtual keyboard defined by the Linux input layer, so I proposed
> that.
>
>   
> > I still think we're somehow misunderstanding each other because I
> > still don't see why Linux input layer codes are any more well defined
> > than PS/2 scan codes except there's a bunch of symbolic defines that
> > have no real meaning for the Linux input layer codes.
> >
> > Regards,
> >
> > Anthony Liguori
> >     
>
> Yes, I agree we've done a fine job talking past each other ;)
>