Re: [gtk-vnc-devel] [PATCH][RFC] Support for ExtendedKeyEvent client message
- From: Markus Armbruster <armbru redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: gtk-vnc-devel List <gtk-vnc-devel lists sourceforge net>
- Subject: Re: [gtk-vnc-devel] [PATCH][RFC] Support for ExtendedKeyEvent client message
- Date: Tue, 22 Jan 2008 22:30:09 +0100
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.
(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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]