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:
>
>   
> > Gerd Hoffmann wrote:
> >     
> > > Anthony Liguori wrote:
> > >   
> > >       
> > > > Gerd Hoffmann wrote:
> > > >     
> > > >         
> > > > >   Hi,
> > > > > I think they are when it comes to those fancy multimedia keyboards which
> > > > > add certain keys for "play", "pause", "next track", "volume up" and so
> > > > > on.  Linux has KEY_FOO defines for them.  For PS/2 those are not
> > > > > standardized and thus differ from vendor to vendor as far I know.  At
> > > > > least xorg comes with a bunch of different xkb keyboard definitions for
> > > > > the different keyboards ...
> > > > >       
> > > > >           
> > > > Right, but recall, we're passing this up through to the PS/2 layer so it
> > > > will just appear like the local keyboard is connected to the server.
> > > >     
> > > >         
> > > Yes for qemu-system-x86.  Not for pvfb.  Dunno how
> > > qemu-system-{sparc,ppc} are handled ...
> > >
> > >   
> > >       
> > > > One problem with passing Linux input codes is that we have no way to
> > > > make the information we get from GDK to Linux keycodes.  We're basically
> > > > passing all the information we have (the symbolic value, and what GDK
> > > > provides as the hardware keycode with some canonicalization).
> > > >     
> > > >         
> > > For the standard 105-key-kbd keys it should be easy at least on pc
> > > hardware (just a table lookup).  Just that should be good enougth for
> > > starters.
> > >
> > > The other keys probably become a bit more tricky due to non-standardized
> > > ps/2 keycodes for them.  Shouldn't be impossible though.  On the client
> > > side we probably can map those XF86XK_AudioLowerVolume (+friends)
> > > keysyms.  On the qemu side we probably have to pick one specific
> > > multimedia keyboard (with lots of different keys) and emulate that one.
> > >   
> > >       
> > Using the -k option in QEMU basically picks a particular keyboard and
> > emulates that.  If we're willing to do that, then always launching
> > qemu with -k en-us and using the existing VNC keysyms is a fine
> > solution to the problem.  This is actually exactly what the current
> > QEMU server does.  As long as you configure your guest with an en-us
> > keyboard, everything Just Works regardless of your client's keyboard
> > got most keysyms.  There aren't really keyboards you can emulate that
> > have every possible character though so you'll always have some user
> > who can't use a certain key.
> >     
>
> There are applications of the protocol that don't have to emulate a
> real keyboard, e.g. PVFB.  They can "emulate" a *virtual* keyboard
> that *does* have all the keys.  Insisting on baking a particular
> *real* keyboard into the protocol is not helpful for those
> applications.
>   

Okay.  I think I understand where you're coming from now.  What we 
really want to do is define a super keyboard that contains all of the PC 
keyboard keys along with possibly more keys.  The Linux input layer 
codes are an obvious place to start.

I'll update my patch.

Regards,

Anthony Liguori

> (1) -k works only if all your clients use the same keyboard layout, no
> matter what the client keyboard is.
>
> (2) Your proposed PS/2 pass-through works only if all your clients use
> the same keyboard, no matter what the client keyboard layout is.
>
> (3) Transmitting a suitable encoding that covers all the keys on all
> the keyboards known to man[*] just works, no matter what keyboard or
> layout the clients use.
>
> Which of the three is most useful to users?  Note that the actual
> encoding used by (3) is *irrelevant* for that question.  Forget I ever
> mentioned Linux input layer codes!
>
>   
> > Regards,
> >
> > Anthony Liguori
> >
> >     
> > > I think we should avoid wiring PS/2 limitations into the protocol, even
> > > if we don't do more than a simple PS/2 keyboard initially.
> > >
> > > cheers,
> > >   Gerd
> > >       
>
> I agree with Gerd.
>
>
> [*] Known to Linux is a useful approximation.
>