From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: RFC: drop frontend support for relative pointer
Date: Wed, 7 Oct 2009 21:01:24 +0100 [thread overview]
Message-ID: <20091007200124.GD2270@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0910071829490.25583@kaball-desktop>
On Wed, Oct 07, 2009 at 06:39:04PM +0100, Stefano Stabellini wrote:
> On Wed, 7 Oct 2009, Markus Armbruster wrote:
> > The protocol between PVFB frontend and backend supports relative and
> > absolute pointer.
> >
> > In theory, support for absolute pointer in the backend is optional. In
> > practice, our backend has always supported it.
> >
> > Absolute pointers provide a superior user experience, and our frontend
> > always enabled them.
> >
> > However, because the backend could theoretically not offer the absolute
> > pointer option, the frontend still supports both. This has worked fine
> > so far, but it's starting to cause trouble now.
> >
> > We support both relative and absolute pointer by setting both EV_REL and
> > EV_ABS in input device, then use whatever the backend sends us. The
> > backend either sends only relative or only absolute events.
> >
> > Nothing in the kernel suggests setting both EV_REL and EV_ABS is bad.
> > In fact, drivers/hid/hid-wacom.c and drivers/input/tablet/aiptek.c seem
> > to do the same.
> >
> > Unfortunately, X is having difficulties with it. It worked only because
> > of a bug in evdev. This bug was fixed recently, and the fix broke the
> > Xen PV pointer. Impact: pointer doesn't work at all with Fedora Rawhide
> > guests. See [*] for the gory details.
> >
> > X will eventually be fixed, but waiting for that isn't practical. We
> > need to work around the problem in xen-kbdfront, or possibly evdev.
> >
> > My preferred solution is dropping support for relative pointer in the
> > frontend, then set only EV_ABS. It's easy, safe, and sends user space
> > down well-trodden paths. Requires a backend supporting absolute
> > pointers, but as mentioned above, they all do.
> >
> > Opinions?
> >
>
> I think that it is fair to assume that the backend supports absolute
> coordinates, in fact the stubdom frontend does that already.
That's good to know - stubdom was one area I was concerned about. To the
best of my knowledge the only backend that ever sent relative mouse events
was the old PVFB we had in Fedora 6 which was the original code before
the eventual merge into official xen-devel trees. So official repos have
always defaulted to absolute mode. Hopefully no one out there has gone
and re-implemented the PVFB backend in any other fork of Xen and dropped
ABS mode or made REL the default ???
IMHO if ABS mode is able to work correctly, then there's absolutely no
benefit in having a REL mode at all, so its best deleted / removed.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2009-10-07 20:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-07 17:16 RFC: drop frontend support for relative pointer Markus Armbruster
2009-10-07 17:39 ` Stefano Stabellini
2009-10-07 18:16 ` Markus Armbruster
2009-10-07 20:01 ` Daniel P. Berrange [this message]
2009-10-08 11:25 ` Stefano Stabellini
2009-10-08 11:32 ` Daniel P. Berrange
2009-10-08 12:59 ` Markus Armbruster
2009-10-12 18:02 ` Jean Guyader
2009-10-12 18:31 ` Jean Guyader
2009-10-12 20:42 ` Markus Armbruster
2009-10-12 21:18 ` Jean Guyader
2009-10-13 16:05 ` Markus Armbruster
2009-10-13 16:21 ` Stefano Stabellini
2009-10-13 18:13 ` Markus Armbruster
2009-10-13 20:58 ` Jean Guyader
2009-10-14 11:56 ` Stefano Stabellini
2009-10-14 12:14 ` Markus Armbruster
2009-10-14 12:42 ` Stefano Stabellini
2009-10-09 17:33 ` Markus Armbruster
2009-10-12 17:27 ` Stefano Stabellini
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=20091007200124.GD2270@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.