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:
>
>   
> > Markus Armbruster wrote:
> >     
> [...]
>   
> > > In the Xen PVFB framebuffer, we need to convert the key we read from
> > > the wire to a Linux input layer key code.  Easy enough for PC key
> > > codes, just reuse the code that does that for a real keyboard.
> > >
> > > But let's look at the bigger picture.  Extending the VNC's RFB
> > > protocol to pass some kind of key code is a good idea.  I'd consider
> > > it a protocol bug fix, in fact.  However, I'd like us to use a
> > > reasonably well-defined, reasonably universal wire key encoding.
> > >
> > > What's a key code?  It's an identification of a key on a keyboard.
> > > The are many different keyboards in use, and almost as many encodings.
> > > The ol' PC key encoding is merely the most common one.
> > >
> > > Mapping between different encodings is straightforward (if tedious),
> > > until you encounter a key that doesn't exist in the target key code.
> > > Try mapping one of those fancy workstation keyboards of old to PC key
> > > encoding.
> > >
> > > Mapping from a real keyboard's key code to Linux input layer key code
> > > should be particularly easy, as you can just steal that code from
> > > Linux[*].
> > >
> > > Therefore, my first choice would be Linux input layer key codes.  It's
> > > reasonably universal, because it supports a wide range of real
> > > keyboards, and it's reasonably well-defined.
> > >   
> > >       
> > The Linux input layer key codes are unique.  That is, KEY_A should
> > alway represent an 'a' key press regardless of the keyboard.  Since
> > VNC's key codes are also unique you should be able to create a static
> > 1-1 mapping between them and it should Just Work.
> >
> > On the other hand, PC key codes are not unique.  Some keyboards will
> > generate a 65 for the 'a' key while others will generate a 65 for the
> > k' key (not really, but bear with me).  The only way to translate from
> > VNC key codes (which are unique) to PC key codes (which aren't) is to
> > use a mapping based on what the actual keyboard is.
> >
> > The whole point of this patch is to pass PC key codes directly through
> > such that the above mapping isn't needed.  Unless I'm not
> > understanding what you're suggesting, I'm not sure that I see how it
> > would be helpful.
> >
> > Regards,
> >
> > Anthony Liguori
> >     
>
> Excuse me if I talk utter nonsense (got a nasty headache, can't think
> straight).
>
> If I understand you correctly, we both want an encoding for *physical*
> keys.  These get transferred through RFB to the remote peer, which
> then maps them to key events according to its own keymapping.
>
> I believe that Linux input layer key codes encode physical keys.
> Quote showkey(1):
>
>     Keycodes are numbers assigned by the kernel to each individual
>     physical key.  Every key has always only one associated keycode
>     number, whether the keyboard sends single or multiple scan codes
>     when pressing it.
>
> You can easily check that the keycodes shown by showkey are exactly
> the KEY_* codes from linux/input.h.
>
> Consider the key labelled Y on US keyboards.  That key is identified
> by input layer key code 21 (KEY_Y), no matter what keymapping or
> actual keyboard I use.  The kernel's default translation tables map it
> to y, Y, Ctrl-Y and so forth.  If I load German translation tables, it
> gets mapped to z, Z, Ctrl-Z and so forth, but the key code is still
> 21.
>
> PC key codes are an encoding for the physical keys of one particular
> kind of keyboard.
>   

Not really.  PC key codes are well defined for one type of keyboard, but 
are used by every keyboard.  I guess there's a 1-1 mapping of Linux 
keycodes to PC keycodes.  I don't believe Linux keycodes are richer than 
PC key codes though because PC key codes are what are being generated 
from the actual keyboard.  By definition, there has to be a PC key code 
for any given key while this isn't necessarily true for Linux keycodes.

So I guess it really comes down to, what benefit would we get by using 
Linux key codes?

Regards,

Anthony Liguori

> Linux input layer key codes are an encoding for the physical keys of
> any keyboard supported by Linux.
>
> It's easy to map from PC key codes to Linux input layer key codes and
> back.  The map doesn't depend on what keymap the user configured,
> because both encodings identify physical keys.  But Linux input layer
> key codes are a richer encoding.  What's the PC key code for
> KEY_POWER?
>
> Again, please excuse me if I talk nonsense, and try to use simple,
> short sentences in your reply %-}
>