|
xen-devel
Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
* 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
|
|
|
Home