[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]
> >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 > from VNC. We would have to map VNC keysyms (which are just Xk keysyms) > to scancodes? Yeah. That's going to be a problem, and that's why I initially wanted to avoid this approach, but I can't see any sane way around it. The mapping table you've got there at the moment is a pretty reasonable first step, even if it is limited to a US keyboard layout. We could potentially do a bit better if we go with the pushing keymaps across xenbus thing, in that we can just send over a keymap which can generate every possible keysym using compose keys and so forth, but it'd be pretty distasteful. > 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 glad I'm not the only one who finds this confusing. :) The KEY_ constants in linux/input.h are a lot closer to scancodes than to traditional X-style keysyms. This becomes obvious once you notice that there's no KEY_COLON, and there's only one KEY_A rather than a KEY_A and a KEY_a. While there is some small amount of normalisation, so that you can mostly use the same keymaps for (say) AT and USB keyboards, input core key events are best thought of as scan codes. Calling them KEY_A etc. is more than a little bit deceptive, since they actually refer more to places on the keyboard than actual characters. The actual key mapping is implemented in drivers/char/keyboard.c (look for key_maps), and we're going to have to go through that whether we want to or not. Of course, I completely failed to understand what was going on here a couple of days ago, so there's a decent chance I've failed to understand this time as well. Steven. Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |