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 11:31:46 +0200 Message-ID: <44FFE702.7000609@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> <44FFCAC0.6060809@bull.net> <20060907083848.GA3078@cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2106447228==" Return-path: In-Reply-To: <20060907083848.GA3078@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) --===============2106447228== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8C4335DEE76F1FD153B8036" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8C4335DEE76F1FD153B8036 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Steven Smith wrote: > First: I now agree with you that scancodes are a better choice than > keysyms, and that I was wrong initially. However, scancodes have > their own problems, and I'd like to make sure they're understood > before we go too far down this path. Good. >>>>>> For the SDL part, I'm sorry to repeat it should use scancode inste= ad >>>>>> of symbol id ... >>>>> I think that would imply that the frontend would need to maintain i= ts >>>>> 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 yo= u? >>>> 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. > What happens if you connect vncviewer from a machine with a US > keyboard, then disconnect, and then reconnect from a machine with a > French keyboard? Nothing :-P I mean the virtual server always use the same keymap... If it was US keymap it continues with US keymap, if it was french keymap = it continues with french keymap. It is possible to use a german keymap on a french keyboard, or belgium ke= ymap on a spanish keyboard, but you should be aware that the symbol on the key wi= ll not be the symbol on the display !!!! > It'd be nice if, from both machines, pressing the key labelled 'w' on > the keyboard resulted in a 'w' being sent to whatever application is > reading from the keyboard at the time. --->_I think it's better to have bad mapping than missing symbols._<--- I prefer to have to press "A" to display "Q" than to not be able to use "= |" or "&" because backend is not able to translate it and transfer it to fronte= nd (see below). >> A desktop like GNOME can manage that too... > Most Gnome apps care more about keysyms than scancodes, though, so > they'll just pick up whatever keymap is set with xmodmap. Yes, I agree. But GNOME desktop is able to use xmodmap to set the good keymap. >>>> In fact, with scancode the used keymap will always be the virtual ma= chine 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%20w= ith%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 tab= le of sdlfb >>>> translates it to nothing... (it's true for &?"{(-?_??)=3D<> ). If I= want to >>>> produce "1", I press shift + "&" and I obtain nothing too.. so all s= ymbols and >>>> digits are missing ! >>>> But if you add "&" in your table, it will be good for french keyboar= d 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. > Ack, sorry, not awake enough. I know that too ;-) >>>> 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 ? > Well, if the backend is attached to a French keyboard and the frontend > has a US keymap loaded. When the user presses 'a', scancode 16 (say) > will be sent, and the frontend will then run that through its keymap Right > and get a 'q'. It'd be good if pressing 'a' led to an 'a' appearing > on the screen. Yes, but I think it is not possible because keyboard driver in kernel is = only able to manage scancodes (KEY_*) and not symbols (like UTF-8). There are two problems you can't solve using symbols instead of scancode:= 1- a symbols can be on two different keys when you use two different keyb= oards (i.e. like AMPERSAND), so the translation from symbol to scancode is not = possible. 2- the "shift" can act differently on keyboard: for instance on US keyboa= rd you don't have to press shift to have "0" when you press KEY_0, on french key= board you must press shift to have "0" when you press KEY_0 otherwise you will = have "=E0". Moreover, for instance, ALTGR and "0" produce "@". And I think french keyboard is not the worst case, think about Japanese, Chinese, Korean, Russian, Greek keyboards (and more). It's a big deal to = map all this "exotic" (I mean non latin ;-) ) symbols to a linux KEY_* . How big = will be the translation array ??? > Given that the backend knows exactly what each scancode is supposed to > map to, we should in principle be able to avoid this sort of problem. > It's just a matter of connecting everything up correctly. :) No, I'm sorry, I don't think so. Except, perhaps, if you send UTF-8 directly from backend to frontend with= out translating it. But it supposes that frontend keyboard driver is able to = manage UTF-8 instead of linux scancode. But it will work with console not with X= 11. I think X11 is working with scancode too. It will be very messy... Regards, Laurent --=20 Laurent.Vivier@bull.net Bull, Architect of an Open World (TM) +----- "Any sufficiently advanced technology is ----+ | indistinguishable from magic." - Arthur C. Clarke | --------------enigD8C4335DEE76F1FD153B8036 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/+cF9Kffa9pFVzwRAjQ6AJ9sX1fY05i1xaD0bkBigYiGmQ30aQCgzt38 yBMbLKC+CCkjtLUdhQ4kTgs= =fYST -----END PGP SIGNATURE----- --------------enigD8C4335DEE76F1FD153B8036-- --===============2106447228== 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 --===============2106447228==--