From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Vivier Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5] Date: Wed, 06 Sep 2006 13:41:18 +0200 Message-ID: <44FEB3DE.5070502@bull.net> References: <20060904090150.GC4812@cam.ac.uk> <44FC224D.3090300@bull.net> <20060906091505.GD3257@cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1704166080==" Return-path: In-Reply-To: <20060906091505.GD3257@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) --===============1704166080== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7D7F5C4D01870391770B7E1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7D7F5C4D01870391770B7E1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Steven Smith wrote: >> Steven Smith wrote: >> [...] >>>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>>> +++ b/tools/xenfb/keymapping.c Sat Sep 02 15:19:25 2006 -0400 >>>> @@ -0,0 +1,141 @@ >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +uint32_t gdk_linux_mapping[0x10000] =3D { >>>> + [GDK_a] =3D KEY_A, >>> This is kind of ugly. Is there any chance it could be autogenerated?= >>> Also, where did 0x10000 come from? >>> >>> Also, depending on GTK just for the keymap table is a real pain. Or >>> is it already required for libvncserver? >>> >> For the VNC part, as it depends on libvncserver, it should use >> /usr/include/rfb/keysym.h: >> >> +uint32_t gdk_linux_mapping[0x10000] =3D { >> + [XK_a] =3D KEY_A, > Yes, you're right. The dependency on GTK is unimportant, but > libvncserver thinks it's generating X keysyms rather than GDK keys, so > XK_* is the correct thing to use, I think. Thanks >> 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 v= irtual machine is configured with US keyboard, the used keymap will be the US on= e. So when I press 'A' on my keyboard I will have 'Q'. 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%2= 0lower%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<> ). I= f I want to produce "1", I press shift + "&" and I obtain nothing too.. so all symbol= s 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"...) And how do you manage this one: http://jcmc.indiana.edu/vol9/issue1/Japanese_Keyboard.gif 2- GDK scancode based: * keymap is keymap of the frontend * frontend knows how to translate ALL scancodes to a symbols. This is the method generally used in emulators (I took scancode from basi= liskII) basiliskII: http://www.cebix.net/viewcvs/cebix/BasiliskII/src/SDL/keycodes?rev=3D1.4 Aranym: http://www.sophics.cz/cgi-bin/viewcvs.cgi/aranym/src/input.cpp But if you don't want to use scancode, you should manage all keyboard int= ernally 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= > 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 | --------------enigA7D7F5C4D01870391770B7E1 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/rPh9Kffa9pFVzwRAkSfAKCC92IeGvZz2ZJgb5B+vop18qlSowCgt1XE RUCGHouwxyWFENTyHFbDNsQ= =BlGT -----END PGP SIGNATURE----- --------------enigA7D7F5C4D01870391770B7E1-- --===============1704166080== 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 --===============1704166080==--