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

[Anthony Liguori <anthony codemonkey ws>]

Daniel P. Berrange wrote:
> On Tue, Jan 22, 2008 at 09:08:15AM -0600, Anthony Liguori wrote:
>   
> > > 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).
> >     
>
> VNC is more complicated than SDL though. SDL only ever runs on the same
> host that the VM is running. So you can trivially configure the keyboard
> in the guest to match the keyboard in your host.  VNC client can run from
> any remote host - each remote VNC Viewer machine may have different 
> keyboard hardware. So it is impossible to configure the guest keyboard
> in such a way that its guarenteed to match the VNC client keyboard, unless
> you change it every time.
>   

When using VNC at the moment, the assumption is that the client is 
always using a US101 keyboard unless they explicitly configure the 
keyboard via the -k option.  If they don't use -k, they get gibberish.

With this extension, if -k is specified, then the keyboard is whatever 
they configure (-k basically disabled the raw keycode extension).  If 
they don't use -k, instead of assuming a US101 keyboard, the client's 
keyboard is directly attached to the guest.

I think this is a much saner default behavior.

> > 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.
> >     
>
> With PS/2 codes going over the wire we need to configure guest to match
> the client keyboard hardware. With Linux codes going over the wire, we
> have a consistent wire encoding no matter what client keyboard is in use.
>   

No, that's not true.  We still need to configure the guest for whatever 
the appropriate keyboard is.  The Linux codes are not symbolic (like the 
X keycodes are).

Regards,

Anthony Liguori

> We then just need to decide what Linux keycode -> hardware keycode map
> to apply in QEMU when pushing  the key events up from server to the
> guest.  Or in the case of PVFB, just pass the Linux keycodes straight 
> on up without translation.
>
> Dan.
>