Re: [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list

[Anthony Liguori <aliguori@us.ibm.com>]

Gerd Hoffmann <kraxel@redhat.com> writes:

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

I don't really have an issue with this series.  It's a reasonable
incremental step.  But I wrote an ps2 qtest recently and had some
thoughts about how we handle input and how we could do it in a better
fashion.

We don't really have the notion of an input device backend/frontend.
There's no great way for a user to see what input devices there are or
participate in which ones should have input.  QOM can fill this void.

We could make a QOM interface, InputInterface, loosely modelled
after the Linux input layer.

The interface would have methods like:

struct InputInterface {
    uint32_t (*get_capabilities)(InputInterface *iface);
    const char *(get_description)(InputInterface *iface);

    void (*begin_batch)(InputInterface *iface);
    void (*event)(InputInterface *iface, uint16_t type,
                  uint16_t code, int32_t value);
    void (*end_batch)(InputInterface *iface);
};

Then any device capable of acting as an input device would implement
this interface.  qom-list can then be used to enumerate any Input
devices.  The VNC server (or GTK UI) could also be modelled as an object
and you could select which input device received keyboard input by
hooking up the properties.

It also makes the devices easier to unit test because you can call the
interface methods directly.

An interface like this would also work for richer input mechanisms like
touchscreens.

Regards,

Anthony Liguori


>
> cheers,
>   Gerd