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



Anthony Liguori <anthony codemonkey ws> writes:

> Daniel P. Berrange wrote:
>> On Sat, Jan 12, 2008 at 06:42:41PM -0600, Anthony Liguori wrote:
>>   
>>> I've included both the gtk-vnc patch and the QEMU patch.  I'd like
>>> to apply the gtk-vnc one before submitting the QEMU one so please
>>> review.  I'm pretty sure I've got it right.
>>>     
>>
>> It looks reasonable to me. I'm going to forward it to Markus Armbruster
>> too, to see what he thinks about it. We've wondered about similar idea
>> for the Xen Paravirt framebuffer for a while now.5D..
>>   
>
> I am thinking of making one change.  Right now, we pass X key code and
> convert to PC key codes within QEMU.  I think it would make more sense
> to do that conversion and gtk-vnc and define the protocol such that PC
> key codes were passed.  I believe that Windows provides PC key codes
> directly so this seems to make sense to me.
>
> Regards,
>
> Anthony Liguori
>
>> Dan.
>>   

In the Xen PVFB framebuffer, we need to convert the key we read from
the wire to a Linux input layer key code.  Easy enough for PC key
codes, just reuse the code that does that for a real keyboard.

But let's look at the bigger picture.  Extending the VNC's RFB
protocol to pass some kind of key code is a good idea.  I'd consider
it a protocol bug fix, in fact.  However, I'd like us to use a
reasonably well-defined, reasonably universal wire key encoding.

What's a key code?  It's an identification of a key on a keyboard.
The are many different keyboards in use, and almost as many encodings.
The ol' PC key encoding is merely the most common one.

Mapping between different encodings is straightforward (if tedious),
until you encounter a key that doesn't exist in the target key code.
Try mapping one of those fancy workstation keyboards of old to PC key
encoding.

Mapping from a real keyboard's key code to Linux input layer key code
should be particularly easy, as you can just steal that code from
Linux[*].

Therefore, my first choice would be Linux input layer key codes.  It's
reasonably universal, because it supports a wide range of real
keyboards, and it's reasonably well-defined.

But I could certainly work with PC key codes as well.

Markus


[*] If a keyboard isn't supported by Linux, it doesn't exist.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]