WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] Xen Virtual Framebuffer

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
From: Gerd Knorr <kraxel@xxxxxxx>
Date: Mon, 19 Dec 2005 11:57:41 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 19 Dec 2005 11:00:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43A2F7FB.6050507@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4394C683.1070000@xxxxxxxxxx> <43A2A2E9.1060308@xxxxxxx> <43A2F7FB.6050507@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050715)
 * why do you put the mfn and evtchn into the start page?  IMHO that
   should be handled by xenstore, like it is done for virtual network
   and disk.

xenstore is not available at start-of-day. This is why the console doesn't use it.

Yep, for the xenstore page we clearly need it (bootstrap issue), and for the console this is quite handy debug tool as well to easily get early boot messages in case the kernel crashes. I think that are enougth special cases.

I'm not tied to using the start_info_t though--just figured the same arguement could be made for the framebuffer as the console.

Not nessesarely. The kernel messages are buffered and printed as soon as the first console device is available. In case of the framebuffer console this usually happens quite late in the boot sequence, with all subsystems being initialized already. Just do a "dmesg" on a native linux machine and look where the vesafb initialization and the "Console: switching to colour frame buffer device 160x64" message is ;)

 * I would simply reuse the input event struct from
   include/linux/input.h for dom0 -> domU input event delivery
   instead of creating something new.

Is this too Linux specific though?  I could just copy the structure.

Well, yes, it is Linux specific. So other OS guests will have to adapt to that. I don't think that is a big problem though, they have to adapt to xenbus too ;)

Hmm, well, maybe, GPL and BSD don't mix without problems, so it could be a problem to simply copy the include/linux/input.h file into the FreeBSD tree for example ...

 * i18n keyboard is really tricky (that is a huge mess in vmx btw).
   I think the only sane approach is to let the guest (domU) do
   all the i18n handling and try to avoid doing any key mapping
   in the host (dom0).  If you have *two* instances (both host
   and guest) doing keyboard mapping and both not even knowing
   what the other one is doing you have absolutely no chance to
   get it right ...

How would you imagine this working? I'll be getting X11 events in dom0 so would you just pass them to domU and let it do the mapping?

I'd try to build a synthetic "struct input_event" out of whatever input
I get and pass that to the domU.

I know QEmu has to use keyboard maps depending on locality. We wouldn't push that into the domU kernel right?

Certainly not.

i18n is hard and the thing I really don't know how to do right :-) Help here is greatly appreciated.

Ok, I'll try to explain things a bit and how I think the design could look like, taking the german keyboard as example.

The "de" kbd layout for the letters a-z looks like the us layout with z and y swapped (there are more differences but thats enougth for now to explain things a bit ...).

The key code in "struct input_event" referes to the untranslated keys, i.e. KEY_Y doesn't mean "the key labeled with 'y'" but means "the key in the top row, 7th from left". That key is 'z' on a german keyboard layout.

The easiest job would have some linux-specific frontend which simply uses the dom0 framebuffer for output and reads input from /dev/input/event<x>, it could simply forward whatever input events it gets as-is ;)

X11 basically has two kinds of key ids: One are the keycodes, which reference untranslated keys too. The other ones are keysyms, which are translated. "xev" is nice to play around with that a bit, best together with some keyboard layout switcher, KDE has one for example.

Problem of the keycodes is that they are not portable. On a sparc with solaris you have other keycodes than on a PC with Linux. For the UML Framebuffer I decided to ignore this portability problem because UML is linux-on-linux only and a remote display doesn't work too. So I've build a fixed table to map the (pc-specific) X11 keycodes to linux keycodes. The uml machine comes up with a us keyboard layout, no matter what layout the host uses. Then I have to use "loadkeys <whatever>" to get the (console) keyboard layout I want, like on a real machine.

Another possible approach for X11-based frontends would be to use the keysyms and translate them backwards to get untranslated keys. Maybe this is what qemu does and what it needs the locale-specific keytables for ...

cheers,

  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel