All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ladi Prosek <lprosek@redhat.com>,
	virtio-dev@lists.oasis-open.org,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [virtio-dev] Re: [PATCH] Update virtio input device specification
Date: Tue, 28 Aug 2018 08:05:24 -0400	[thread overview]
Message-ID: <20180828080457-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180620061219-mutt-send-email-mst@kernel.org>

On Wed, Jun 20, 2018 at 06:13:35AM +0300, Michael S. Tsirkin wrote:
> On Thu, Apr 06, 2017 at 03:21:26PM +0200, Gerd Hoffmann wrote:
> >   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
> 
> 
> Gerd is there a chance you could try and address whatever
> you think needs to be addressed and repost?
> 
> Would be nice to have this in 1.1 and I think it's better
> to have an incomplete description than none.

Ping.

> 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


      reply	other threads:[~2018-08-28 12:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1490350679-19068-1-git-send-email-lprosek@redhat.com>
     [not found] ` <20170324234220-mutt-send-email-mst@kernel.org>
     [not found]   ` <CABdb736T+YRoAdze-LYYqy+gZ495CnRXvi7cqS3gffhL9OoCYw@mail.gmail.com>
     [not found]     ` <20170406011025-mutt-send-email-mst@kernel.org>
     [not found]       ` <CABdb734uWaa8CUZ-WbHJ-70MONB+WUDfPHbmGYEXXa3AjPZotg@mail.gmail.com>
     [not found]         ` <1491484886.12607.57.camel@redhat.com>
2018-06-20  3:13           ` [virtio-dev] Re: [PATCH] Update virtio input device specification Michael S. Tsirkin
2018-08-28 12:05             ` Michael S. Tsirkin [this message]

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=20180828080457-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lprosek@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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.