Steven Smith wrote:
> 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.
Good.
>>>>>> 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?
Nothing :-P
I mean the virtual server always use the same keymap...
If it was US keymap it continues with US keymap, if it was french keymap it
continues with french keymap.
It is possible to use a german keymap on a french keyboard, or belgium keymap on
a spanish keyboard, but you should be aware that the symbol on the key will not
be the symbol on the display !!!!
> 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.
--->_I think it's better to have bad mapping than missing symbols._<---
I prefer to have to press "A" to display "Q" than to not be able to use "|" or
"&" because backend is not able to translate it and transfer it to frontend (see
below).
>> 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.
Yes, I agree.
But GNOME desktop is able to use xmodmap to set the good keymap.
>>>> 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.
I know that too ;-)
>>>> 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
Right
> and get a 'q'. It'd be good if pressing 'a' led to an 'a' appearing
> on the screen.
Yes, but I think it is not possible because keyboard driver in kernel is only
able to manage scancodes (KEY_*) and not symbols (like UTF-8).
There are two problems you can't solve using symbols instead of scancode:
1- a symbols can be on two different keys when you use two different keyboards
(i.e. like AMPERSAND), so the translation from symbol to scancode is not
possible.
2- the "shift" can act differently on keyboard: for instance on US keyboard you
don't have to press shift to have "0" when you press KEY_0, on french keyboard
you must press shift to have "0" when you press KEY_0 otherwise you will have
"à". Moreover, for instance, ALTGR and "0" produce "@".
And I think french keyboard is not the worst case, think about Japanese,
Chinese, Korean, Russian, Greek keyboards (and more). It's a big deal to map all
this "exotic" (I mean non latin ;-) ) symbols to a linux KEY_* . How big will be
the translation array ???
> 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. :)
No, I'm sorry, I don't think so.
Except, perhaps, if you send UTF-8 directly from backend to frontend without
translating it. But it supposes that frontend keyboard driver is able to manage
UTF-8 instead of linux scancode. But it will work with console not with X11. I
think X11 is working with scancode too. It will be very messy...
Regards,
Laurent
--
Laurent.Vivier@xxxxxxxx
Bull, Architect of an Open World (TM)
+----- "Any sufficiently advanced technology is ----+
| indistinguishable from magic." - Arthur C. Clarke |
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
