From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Vivier Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5] Date: Thu, 07 Sep 2006 09:31:12 +0200 Message-ID: <44FFCAC0.6060809@bull.net> References: <20060904090150.GC4812@cam.ac.uk> <44FC224D.3090300@bull.net> <20060906091505.GD3257@cam.ac.uk> <44FEB3DE.5070502@bull.net> <20060906171006.GA5306@cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1202793313==" Return-path: In-Reply-To: <20060906171006.GA5306@cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith Cc: Jeremy Katz , aliguori , xen-devel , sos22@srcf.ucam.org, Markus Armbruster List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1202793313== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig818937AB0EE739B7D0F6C0D9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig818937AB0EE739B7D0F6C0D9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 th= e 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 cur= rent display. A desktop like GNOME can manage that too... >> In fact, with scancode the used keymap will always be the virtual mach= ine 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%20wit= h%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 &=E9"{(-=E8_=E7=E0)=3D<> )= =2E If I want to >> produce "1", I press shift + "&" and I obtain nothing too.. so all sym= bols 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, i= f 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. >=20 >> * 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 b= asiliskII) >> basiliskII: >> http://www.cebix.net/viewcvs/cebix/BasiliskII/src/SDL/keycodes?rev=3D1= =2E4 >> 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 --=20 Laurent.Vivier@bull.net Bull, Architect of an Open World (TM) +----- "Any sufficiently advanced technology is ----+ | indistinguishable from magic." - Arthur C. Clarke | --------------enig818937AB0EE739B7D0F6C0D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQFE/8rD9Kffa9pFVzwRAtACAKDAP7uNN4Ld6sDRkvAXMJqKr3sCQACgshXF 5ABZkGAknNm7UVrHdyouH38= =QLsV -----END PGP SIGNATURE----- --------------enig818937AB0EE739B7D0F6C0D9-- --===============1202793313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1202793313==--