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:
>
>   
> > Daniel P. Berrange wrote:
> >     
> > > On Sat, Jan 12, 2008 at 06:42:41PM -0600, Anthony Liguori wrote:
> > >   
> > >       
> > > > I've included both the gtk-vnc patch and the QEMU patch.  I'd like
> > > > to apply the gtk-vnc one before submitting the QEMU one so please
> > > > review.  I'm pretty sure I've got it right.
> > > >     
> > > >         
> > > It looks reasonable to me. I'm going to forward it to Markus Armbruster
> > > too, to see what he thinks about it. We've wondered about similar idea
> > > for the Xen Paravirt framebuffer for a while now.5D..
> > >   
> > >       
> > I am thinking of making one change.  Right now, we pass X key code and
> > convert to PC key codes within QEMU.  I think it would make more sense
> > to do that conversion and gtk-vnc and define the protocol such that PC
> > key codes were passed.  I believe that Windows provides PC key codes
> > directly so this seems to make sense to me.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >     
> > > Dan.
> > >   
> > >       
>
> 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

> But I could certainly work with PC key codes as well.
>
> Markus
>
>
> [*] If a keyboard isn't supported by Linux, it doesn't exist.
>