Re: [PATCH] Update virtio input device specification

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> The downside is that this is hard to specify formally, the same way we
> do other devices. Say we do that and point to a fixed version of the
> relevant Linux headers and the headers evolve and add or change
> something. Then we would either go change the spec to be in sync with
> the headers or build a compatibility layer in the implementation.

Highly unlikely that the structs and ioctls in linux header change.
It's userspace <=> kernel abi.  And even if they change some days it
would have to happen in a backward compatible way.  So I think
documenting the ioctl structs we have today is reasonable.  If new
ioctls for new device types show up we probably need a virtio feature
flag anyway to properly support them.

Events (new key codes for example) are added now and then.  So for them
we might continue referencing the include file with the codes instead of
copying them into the spec.

> because evdev
> needs to maintain some reasonable backwards compatibility by itself so
> it's very unlikely that things would break.

Yep.  Unknown events can simply be ignored.  And you can query the
device to figure which events (aka keys / axis / ...) are supported
(ioctl in evdev, config space in virtio).  So that level of
compatibility is already taken care of, in both evdev and virtio.

> > Let's assume linux gains ability to generate new events on top of old
> > ones.
> > Do you want to send both in all cases?
> > If you only send multitouch how do you handle old guests?
> > If you send both how does new guest know it should
> > ignore old  events?
> 
> I think that these are valid concerns but they need to be addressed at
> the evdev layer, not in virtio.

Indeed.  And I think multitouch is addressed by simply sending both.
Apps without multitouch support simply ignore the multitouch events.
Apps with multitouch support can figure this is a multitouch-capable
device and ignore the old events on those.

cheers,
  Gerd