qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 5/5] keymap: consider modifier state when pic


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v3 5/5] keymap: consider modifier state when picking a mapping
Date: Wed, 19 Dec 2018 08:55:10 +0100
User-agent: NeoMutt/20180716

  Hi,

> After this patch the two sequences now show:
> 
>   address@hidden:vnc_key_event_map down 1, sym 0xffe1 -> keycode 0x2a [shift]
>   address@hidden:vnc_key_event_map down 1, sym 0x3c -> keycode 0x33 [comma]
>   address@hidden:vnc_key_event_map down 0, sym 0x3c -> keycode 0x33 [comma]
>   address@hidden:vnc_key_event_map down 0, sym 0xffe1 -> keycode 0x2a [shift]
> 
>   address@hidden:vnc_key_event_map down 1, sym 0xffe1 -> keycode 0x2a [shift]
>   address@hidden:vnc_key_event_map down 1, sym 0x3c -> keycode 0x33 [comma]
>   address@hidden:vnc_key_event_map down 0, sym 0xffe1 -> keycode 0x2a [shift]
>   address@hidden:vnc_key_event_map down 0, sym 0x3c -> keycode 0x56 [less]
> 
> Notice how we sent a "down(comma)" and paired it with an "up(less)". This
> causes the guest to consider the key stuck down, so next time you type
> a "<" it will get lost.

Ouch.

> This is easily reproduced with gtk-vnc and the following QEMU command
> line:
> 
>   ./x86_64-softmmu/qemu-system-x86_64 -vnc :1 -d trace:vnc* 
> 
> 
> I don't see any nice way to fix the problem without having to keep a
> memory of modifier state with every "down" event, so you can use the
> same modifier state with the later "up" event to ensure you get a
> matching key up.

Well, for key-up you can prefer keys in "down" state instead of looking
at the modifiers.

> This is quite horrible though. I'm more inclined
> to revert this patch and find another way to fix the original problem
> which won't require the UI frontends to track modifier state.

The UIs track modifier state anyway.

I fact I have some WIP patches to add a generic keyboard state tracker,
so the UIs can use common code instead of having their own state
tracking code each.  Also to make UI hotkeys configurable, consistent
across all UIs we have.  Guess I should undust them, at least the state
tracking part of it.

With that in place we can easily pass the full keyboard state to the
keymap code.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]