All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: ~rongyichang <rongyichang@git.sr.ht>
Cc: qemu-devel@nongnu.org,  ~rongyichang <rongyichang@xiaomi.com>,
	marcandre.lureau@redhat.com,  eblake@redhat.com
Subject: Re: [PATCH qemu] ui/sdl2: add grab-on-tablet option for absolute input devices
Date: Mon, 06 Jul 2026 15:12:40 +0200	[thread overview]
Message-ID: <877bn8ntx3.fsf@pond.sub.org> (raw)
In-Reply-To: <178065435170.20548.15372728064868431795-0@git.sr.ht> (rongyichang@git.sr.ht's message of "Fri, 05 Jun 2026 17:53:25 +0800")

I apologize for the lateness of my review.

~rongyichang <rongyichang@git.sr.ht> writes:

> From: rongyichang <rongyichang@xiaomi.com>
>
> When using absolute coordinate input devices (e.g. virtio-tablet-device),
> the SDL display backend implements a "soft grab" where the mouse is
> automatically grabbed when it enters the window interior and ungrabbed
> when it hits the window edge. This edge-ungrab behavior causes problems
> in embedded emulation scenarios:
>
> 1. Mouse escapes the SDL window at edges
> 2. SDL does not deliver BUTTONUP events for the escaped mouse
> 3. The guest gets stuck in a pressed/touch-down state
> 4. First click back into the window is silently dropped
>
> This issue is confirmed as a known SDL limitation (SDL issue #5301).
>
> Add a new -display sdl,grab-on-tablet=on option that makes absolute
> coordinate devices use the same grab behavior as relative (mouse)
> devices: user must click to grab, Ctrl+Alt+G to release, and no
> automatic grab on window enter or edge-based ungrab/regrab.
>
> Signed-off-by: Yichang Rong <rongyichang@xiaomi.com>
> ---
>  qapi/ui.json    |  8 +++++++-
>  qemu-options.hx |  9 +++++++--
>  ui/sdl2.c       | 16 +++++++++++++---
>  3 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/qapi/ui.json b/qapi/ui.json
> index b2c42a7f57..454d9041bf 100644
> --- a/qapi/ui.json
> +++ b/qapi/ui.json
> @@ -1477,10 +1477,16 @@
>  # @grab-mod: Modifier keys that should be pressed together with the
>  #     "G" key to release the mouse grab.
>  #
> +# @grab-on-tablet: When enabled, the mouse grab is required even for
> +#     tablet (absolute) input devices.  This is useful when the guest
> +#     OS uses a tablet device but you still want click-to-grab
> +#     semantics (e.g. NuttX touchscreen emulation).

Missing: (since 11.1)

When would you still want click-to-grab semantics?  The commit message
gives a fairly specific use case.  The doc comment gives only an
example.  Is this good enough for users?

> +#
>  # Since: 7.1
>  ##
>  { 'struct'  : 'DisplaySDL',
> -  'data'    : { '*grab-mod'   : 'HotKeyMod' } }
> +  'data'    : { '*grab-mod'   : 'HotKeyMod',
> +                '*grab-on-tablet' : 'bool' } }
>  
>  ##
>  # @DisplayType:



      parent reply	other threads:[~2026-07-06 13:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  9:53 [PATCH qemu] ui/sdl2: add grab-on-tablet option for absolute input devices ~rongyichang
2026-06-05 16:47 ` BALATON Zoltan
2026-06-06  3:01   ` 答复: [External Mail]Re: " 荣义昌 via qemu development
2026-06-18 12:56     ` BALATON Zoltan
2026-07-06 13:12 ` Markus Armbruster [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=877bn8ntx3.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rongyichang@git.sr.ht \
    --cc=rongyichang@xiaomi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.