qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>, qemu-devel@nongnu.org
Cc: Gerd Hoffmann <kraxel@redhat.com>, Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH 0/2] ui/kbd-state: QAPI'fy QKbdModifier
Date: Sat, 25 Feb 2023 12:19:37 +0900	[thread overview]
Message-ID: <e4f34f81-17db-7b17-9f0a-32b8f950099c@gmail.com> (raw)
In-Reply-To: <20230224110153.8559-1-philmd@linaro.org>

On 2023/02/24 20:01, Philippe Mathieu-Daudé wrote:
> QAPI seems designed to maintain such enums,
> so convert QKbdModifier to be QAPI generated.
> Besides, this is how QKeyCode is maintained.

I recognize QkbdModifier as more like an internal detail of displays so 
I'm not convinced it should be converted to QAPI.

The interface of QEMU's input subsystem is so simple: send key up or key 
down events for QKeyCode. The modifiers are not exceptions. However, 
some display backends (cocoa, sdl2, and vnc) are not designed this way, 
and has internal states for modifiers. For such displays, QkbdState 
maintains the states to help them convert their internal key state 
representation to key up/down events of QKeyCode.

QKbdModifier is used by displays only to query these internal states 
QkbdState holds. As such, the definition of QKbdModifier is very 
dependent of the internal working of displays. It is particularly 
designed to match the needs of vnc, and I even wonder if the modifier 
state tracking should be moved away from the common code of QkbdState to 
vnc.

Regards,
Akihiko Odaki

> 
> Philippe Mathieu-Daudé (2):
>    ui/kbd-state: Rename QKbdModifier enum definitions
>    ui/kbd-state: QAPI'fy QKbdModifier
> 
>   include/ui/kbd-state.h | 16 ----------------
>   qapi/ui.json           | 10 ++++++++++
>   ui/cocoa.m             |  2 +-
>   ui/kbd-state.c         | 14 +++++++-------
>   ui/keymaps.c           |  6 +++---
>   ui/sdl2-input.c        |  2 +-
>   ui/vnc.c               | 16 ++++++++--------
>   7 files changed, 30 insertions(+), 36 deletions(-)
> 


      parent reply	other threads:[~2023-02-25  3:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 11:01 [PATCH 0/2] ui/kbd-state: QAPI'fy QKbdModifier Philippe Mathieu-Daudé
2023-02-24 11:01 ` [PATCH 1/2] ui/kbd-state: Rename QKbdModifier enum definitions Philippe Mathieu-Daudé
2023-02-24 11:01 ` [PATCH 2/2] ui/kbd-state: QAPI'fy QKbdModifier Philippe Mathieu-Daudé
2023-02-25  3:19 ` Akihiko Odaki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4f34f81-17db-7b17-9f0a-32b8f950099c@gmail.com \
    --to=akihiko.odaki@gmail.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).