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

[Markus Armbruster <armbru@redhat.com>]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
>
> On Sat, 2006-10-07 at 18:48 +0200, Markus Armbruster wrote:
>
>> The backend gets keys in an encoding that depends on the software used
>> to access the keyboard:
>> 
>> * with SDL, struct SDL_keysym (consists of scancode, SDL keysym,
>> current modifiers and optionally Unicode translation),
>> 
>> * with LibVNCServer: rfbKeySym (which is just an X11 keysym).
>> 
>> The frontend needs to stuff Linux keycodes into the input layer.
>> 
>> Our job is to translate from frontend keysyms to Linux keycodes, and
>> the question is to find out how and where.
>
> Bear in mind that it may simply not be possible.  :-(
>
> An example is my UK keyboard connecting to a guest with a US keymap.
> For me, "#" is a key on its own (with "~" as the shift-modified key.)
> When I type "#", with no modifier pressed, there is simply no way to
> translate that to a single keycode on a US keymap and get the "#" ksym
> out --- on a US keyboard, "#" requires shift to be held down.
>
> The only way you'll get such a keypress through is by faking modifiers
> on the fly.

Arguably, `#' is not a raw key, its something bound to a key by
keymapping software.  Let me call that a mapped key, for lack of a
better word.

Options I can see:

(1) Start with the host's mapped keys.  Fake raw keys in the guest so
    that guest keymapping maps them to the mapped keys we see in the
    host.

    Nice: host key map just works across all guests.

    However, I fear this is a game we can't win: we can hardly assume
    that every keymap can produce every conceivable mapped key, no
    matter how much we fool around with modifiers.  Perhaps we could
    be good enough at the game to make things work well enough for
    most users.  I don't know.  Smells like a swamp to me.

(2) Simply use the host's raw keys.

    The guest needs to understand the host's raw keys, and map them if
    they differ from its own idea of raw keys.  At this time, the only
    idea of raw keys in town is Linux keycodes, so no mapping is
    necessary.

    Nice: simple & stupid.

    Unless I misunderstand Anthony, that's what rdesktop and qemu do.

(3) Define some abstract key encoding, map from host raw keys to that,
    then to guest raw keys.

    If we simply choose the current Linux keycodes as abstract
    encoding, we get (3) for the price of (2) now, and pay the rest
    only when Linux keycodes change incompatibly.  Which I figure is
    rather unlikely.

What do you want me to code?