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

["Daniel P. Berrange" <berrange redhat com>]

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.

> 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.
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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|