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

[Gerd Knorr <kraxel@xxxxxxx>]

> >  * 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