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

Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]



Anthony Liguori wrote:
> Steven Smith wrote:
>> First: I now agree with you that scancodes are a better choice than
>> keysyms, and that I was wrong initially.
> 
> The problem with scancodes is that you cannot always get scancodes from
> the viewer.  You can get scancodes from SDL but you can only get keysyms

Right.

> from VNC.  We would have to map VNC keysyms (which are just Xk keysyms)
> to scancodes?

It's what we already did: KEY_* are scancodes.
It's why it should be better to get scancodes from the viewer, not keysyms.

Currently:
we get keysyms from VNC and SDL and we translate to scancode for linux kernel.

What I propose:
we get scancode from SDL and we translate to scancode for linux kernel.
We must keep keysyms from VNC because we can't have scancode from VNC client.

> I'm a bit surprised here.  If we generate a KEY_Q event in Linux that
> may show up as a KEY_A key?  There are keysyms for all the extended keys
> I thought.

I'm sorry but I think you didn't understand the issue: we must provide scancode
to frontend keyboard driver (KEY_*), and the current issue is in translating
keysyms to scancode. Please have look at all previous e-mails...

Regards,
Laurent
-- 
                Laurent.Vivier@xxxxxxxx
         Bull, Architect of an Open World (TM)
+----- "Any sufficiently advanced technology is ----+
| indistinguishable from magic." - Arthur C. Clarke |

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.