Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]

[Anthony Liguori <aliguori@xxxxxxxxxxxxx>]

Steven Smith wrote:
> First: I now agree with you that scancodes are a better choice than
> keysyms, and that I was wrong initially.
The problem with scancodes is that you cannot always get scancodes from 
the viewer.  You can get scancodes from SDL but you can only get keysyms 
from VNC.  We would have to map VNC keysyms (which are just Xk keysyms) 
to scancodes?
I'm a bit surprised here.  If we generate a KEY_Q event in Linux that 
may show up as a KEY_A key?  There are keysyms for all the extended keys 
I thought.
Regards,

Anthony Liguori

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

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