From: Gerd Hoffmann <kraxel@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list
Date: Mon, 11 Mar 2013 15:51:24 +0100 [thread overview]
Message-ID: <513DEF6C.8080108@redhat.com> (raw)
In-Reply-To: <CAFEAcA-DJTVqjjXKtmZFa7o3u7Qej5NvP=eSz5EzK+5T37oUFQ@mail.gmail.com>
Hi,
> The major difference is that where this code sends key events
> to the first handler only, the Nokia patch sends events to
> all keys, because the use case it's trying to deal with is
> "some keys should go to one device and some to another"
> (for example, most keys go to a usb keyboard but F-keys
> are treated as being like some of the hardware buttons on
> the phone, and they go to a different device in the model).
> Maybe we could deal with this by having kbd_put_keycode()
> send the event to every register keyboard until one of
> them says it has handled it [ie have the put_kbd callback
> return a handled/not-handled return].
Yea, sending to all doesn't fly in general as guests
with ps/2 + usb kbd would see all keys twice then ...
Having a "handled" return code makes sense to me. IIRC glib has
something simliar (return true == handled, return false == call next
handler please).
> That would still
> leave the issue that you need to make sure that keyboard
> handlers get called in the right order (perhaps a priority
> thing on registering?)
A priority field is more robust I think.
> Anyway, no objection to this patch (and I'm certainly not
> trying to say you should fix my problems in this patch),
> I just thought I'd mention this other usecase for multiple
> keyboards while it was in my head.
Should be easy to add support for this on top of this series.
cheers,
Gerd
next prev parent reply other threads:[~2013-03-11 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 14:22 [Qemu-devel] [PATCH v2 0/2] input: add keyboard handler list Gerd Hoffmann
2013-03-08 14:22 ` [Qemu-devel] [PATCH v2 1/2] input: make QEMUPutLEDEntry + QEMUPutMouseEntry private Gerd Hoffmann
2013-03-08 14:22 ` [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list Gerd Hoffmann
2013-03-11 9:25 ` Markus Armbruster
2013-03-11 9:56 ` Gerd Hoffmann
2013-03-11 12:49 ` Anthony Liguori
2013-03-11 13:52 ` Markus Armbruster
2013-03-11 13:46 ` Peter Maydell
2013-03-11 14:51 ` Gerd Hoffmann [this message]
2013-03-11 15:28 ` Anthony Liguori
2013-03-11 9:24 ` [Qemu-devel] [PATCH v2 0/2] input: add " Markus Armbruster
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=513DEF6C.8080108@redhat.com \
--to=kraxel@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=peter.maydell@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).