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:
> >     
> > > Anthony Liguori <anthony codemonkey ws> writes:
> > >
> > >   
> > >       
> > > > Markus Armbruster wrote:
> > > >     
> > > >         
> > > > > Anthony Liguori <anthony codemonkey ws> writes:
> > > > >
> > > > >         
> > > > >           
> > > > > > 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.
> > > > > >             
> > > > > >             
> > > > > There has to be a PC key code for every physical key on a PC keyboard.
> > > > >
> > > > > However, not every keyboard is a PC keyboard, and some of them have
> > > > > keys that that don't exist on PC keyboards.
> > > > >         
> > > > >           
> > > > Well, I think this is our problem.  When I say, PC key code, I don't
> > > > mean the codes assigned to keys on a PC101 keycode.  I mean any
> > > > hardware keycode that is delivered through a PS/2 port.
> > > >
> > > > GDK calls this a "hardware keycode" which is perhaps a better nomenclature.
> > > >
> > > > Regards,
> > > >
> > > > Anthony Liguori
> > > >     
> > > >         
> > > Is this code at least as rich as the Linux input layer code?  If not,
> > > is it rich enough for all practical purposes?
> > >   
> > >       
> > Anything that comes in through the keyboard should be supported.
> > Linux may turn some other things into input events (perhaps some ACPI
> > events)?  It may be useful to provide some mechanism to support these
> > sort of things but I think it's outside of the scope of this
> > particular encoding.
> >
> >     
> > > Where is this code defined?
> > >   
> > >       
> > Codes aren't defined.  That's really the point.  Whatever comes in
> > from your keyboard is immediately sent to the server.  In the case of
> > QEMU, this is then immediately sent through the guest's PS/2.
> >
> > In a lot of respects, this is really PS/2 pass-through support.
> >
> > Regards,
> >
> > Anthony Liguori
> >     
>
> The question is: do we want PS/2 pass-through, or do we want a
> well-defined virtual keyboard?
>
> Consider: several people access the same guest's PVFB through VNC from
> their own computers, each with his own keyboard.
>
> Their local keyboard drivers know how to map whatever their keyboards
> send to their system's common keyboard event encoding.  In the case of
> Linux: the kernel keyboard driver maps to Linux input layer codes, and
> the X keyboard driver maps those to X events.
>   

But the Linux input codes are equally undefined.  While KEY_Q may be 
symbolic and defined to a certain value, it's all but meaningless on the 
wire.  It may correspond to any number of physical key presses.  What 
you're proposing is Linux input layer pass through.

> With your PS/2 pass-through proposal, whatever each keyboard sends
> gets passed on to the (remote) guest, without any indication of what
> kind of keyboard generated them.  PVFB has to ultimately map them to
> Linux input layer codes.  Because it has no idea what keyboard made
> these codes, it has arbitrarily assume one particular keyboard.
>   

Linux already has to make PS/2 keycodes to input events.  It should be 
the same thing.

> Some users' funny keys will just work, others won't.  And we'll have
> no sane way to fix that in PVFB.
>
> Putting something on the wire without a clear definition of its
> encoding seems very wrong to me.  Perhaps an identification of the
> keyboard could make the "whatever the keyboard sends" encoding fly.
> We'd still have to replicate local smarts on interpreting the local
> keyboard codes in the remote PVFB, but we'd have a fighting chance.
>
> For PVFB, I'd still prefer a single (near-)universal code.
>   

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.

The problem we're solving is this: if a host and guest have the same 
keyboard configured, then PS/2 pass through will Just Work.  The same 
logic applies already today with QEMU's SDL support (you don't need to 
use -k when using SDL).

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