qemu-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]