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.
> >>>> 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
> >> 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?
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.
> 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.
> >> 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%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 table of
> >> sdlfb
> >> translates it to nothing... (it's true for &?"{(-?_??)=<> ). If I want to
> >> produce "1", I press shift + "&" and I obtain nothing too.. so all symbols
> >> 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"...)
> > 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.
> >> 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
and get a 'q'. It'd be good if pressing 'a' led to an 'a' appearing
on the screen.
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. :)
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
