[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list |
Date: |
Mon, 11 Mar 2013 15:51:24 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 |
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
Re: [Qemu-devel] [PATCH v2 0/2] input: add keyboard handler list, Markus Armbruster, 2013/03/11