[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]
Steven Smith wrote: >>>> For the SDL part, I'm sorry to repeat it should use scancode instead >>>> of symbol id ... >>> I think that would imply that the frontend would need to maintain its >>> own keymap, yes? What do you think should happen if the system >> Yes, frontend (domU kernel or X11) should maintain it's own keymap. >> >>> running the SDL viewer has e.g. a French keyboard but the virtual >>> machine is configured with a US keymap? Or have I misunderstood you? >> If the SDL viewer is using X11 configured with french keyboard, and the >> virtual >> machine is configured with US keyboard, the used keymap will be the US one. >> So >> when I press 'A' on my keyboard I will have 'Q'. > That kind of sucks. Not being able to produce every character sucks > more, but having to configure the keymap in every VM isn't much > better. It's even better if you consider that with VNC clients the > client keymap may change while the virtual machine is running. The keymap may not change while the virtual machine is running: "loadkeys" acts only on the current console, and for X11, "xmodmap" modifies only the current display. A desktop like GNOME can manage that too... >> In fact, with scancode the used keymap will always be the virtual machine >> one. >> >> We can compare the two solutions: >> >> 1- GDK symbol based: >> >> * keymap is keymap of the backend >> * we can't translate all symbols >> >> for instance, look at these GIF: >> >> http://riley.slc.k12.ut.us/images/program_images/Type%20Keyboard%20with%20lower%20letters.gif >> http://www.sussex.ac.uk/its/facilities/pc/keyboards/french.gif >> >> On my french keyboard I want to produce "&", so I press "&", GDK table of >> sdlfb >> translates it to nothing... (it's true for &é"{(-è_çà)=<> ). If I want to >> produce "1", I press shift + "&" and I obtain nothing too.. so all symbols >> and >> digits are missing ! >> But if you add "&" in your table, it will be good for french keyboard but bad >> for US keyboard (you will generate "7" instead of "1"...) > I can't see why just adding SDLK_AMPERSAND to the table will break US > keyboards. Surely SDL doesn't expect every application to track the > effects of the shift key? Look at the GIFs... if you think "US Keyboard", SDLK_AMPERSAND will be translated to KEY_7, if you think "French Keyboard", SDLK_AMPERSAND should be translated to KEY_1. >> And how do you manage this one: >> >> http://jcmc.indiana.edu/vol9/issue1/Japanese_Keyboard.gif > Perhaps we should be using the keysym->unicode rather than > keysym->sym? I have to admit I'm not sure exactly how the more exotic > keymaps are actually encoded in Linux, but there must be some way of > mapping them to keysyms, or such keyboards wouldn't work at all. Are you ready to manage a table of 2^16 entries ???? ;-) > Actually, it might be nice to send unicode characters over the > protocol directly, rather than Linux key codes, and then do the > translation in the front end. Perhaps... >> 2- GDK scancode based: >> >> * keymap is keymap of the frontend > And has potentially no relationship to the ``correct'' keymap, which > is the one seen by the client. > >> * frontend knows how to translate ALL scancodes to a symbols. > But it occasionally gets it wrong. Really ? In which cases ? >> This is the method generally used in emulators (I took scancode from >> basiliskII) >> basiliskII: >> http://www.cebix.net/viewcvs/cebix/BasiliskII/src/SDL/keycodes?rev=1.4 >> Aranym: >> http://www.sophics.cz/cgi-bin/viewcvs.cgi/aranym/src/input.cpp > If you're doing full emulation then the guest expects to see a real > keyboard with real scancodes, and so you don't have a great deal of > choice. Yes, but linux kernel expects a scancode too... >> But if you don't want to use scancode, you should manage all keyboard >> internally >> as in E-UAE (file e-uae-0.8.29-WIP3/src/gfx-sdl/sdlkeys.c): >> http://www.rcdrummond.net/uae/e-uae-0.8.29-WIP3/e-uae-0.8.29-WIP3.tar.bz2 > That's kind of icky as well. Needing to know the user's exact > keyboard type is really quite unpleasant. I agree. > Steven. 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |