All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.