RFC: drop frontend support for relative pointer

RFC: drop frontend support for relative pointer

[Markus Armbruster]

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?


[*] https://bugzilla.redhat.com/show_bug.cgi?id=523914

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

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.
As a consequence removing the EV_REL bit is fine as a workaround but I
wouldn't go as far as removing the actual code that support it
(XENKBD_TYPE_MOTION).

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> 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.
> As a consequence removing the EV_REL bit is fine as a workaround but I
> wouldn't go as far as removing the actual code that support it
> (XENKBD_TYPE_MOTION).

Why keep the then dead code in the frontend?  Note I'm not suggesting to
change the protocol or the backend.

Re: RFC: drop frontend support for relative pointer

[Daniel P. Berrange]

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

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
> 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. 

I guess keeping around unused code doesn't make much sense but I was just
being cautious, given that for example XCI is currently using relative
coordinates so they are not dead just yet.

Re: RFC: drop frontend support for relative pointer

[Daniel P. Berrange]

On Thu, Oct 08, 2009 at 12:25:23PM +0100, Stefano Stabellini wrote:
> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
> > 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. 
> 
> I guess keeping around unused code doesn't make much sense but I was just
> being cautious, given that for example XCI is currently using relative
> coordinates so they are not dead just yet.

Doh, that was exactly the kind of issue I was afraid of. If there is
a current host OS that uses relative mode, then we can't get rid of it
in the frontend. So if XCI only does relative mode, that pretty much
puts a stop to Markus' plan

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

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>> 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. 
>
> I guess keeping around unused code doesn't make much sense but I was just
> being cautious, given that for example XCI is currently using relative
> coordinates so they are not dead just yet.

Just to avoid misunderstandings:

* Does XCI set feature-abs-pointer in xenstore?

* If it does, does it read request-abs-pointer from xenstore?

* Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
  under what circumstances (if any) does it send XENKBD_TYPE_POS?

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>> 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. 
>
> I guess keeping around unused code doesn't make much sense but I was just
> being cautious, given that for example XCI is currently using relative
> coordinates so they are not dead just yet.

Can I have a pointer to source, please?

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

On Fri, 9 Oct 2009, Markus Armbruster wrote:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
> 
> > On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
> >> 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. 
> >
> > I guess keeping around unused code doesn't make much sense but I was just
> > being cautious, given that for example XCI is currently using relative
> > coordinates so they are not dead just yet.
> 
> Can I have a pointer to source, please?
>

The sources are here:

http://www.xen.org/products/xci_source.html


as for the other questions, I am not that familiar with XCI code, but I
pinged some of the people that should know about this and hopefully
they'll reply soon.

Re: RFC: drop frontend support for relative pointer

[Jean Guyader]

2009/10/8 Markus Armbruster <armbru@redhat.com>:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>
>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>>> 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.
>>
>> I guess keeping around unused code doesn't make much sense but I was just
>> being cautious, given that for example XCI is currently using relative
>> coordinates so they are not dead just yet.
>
> Just to avoid misunderstandings:
>
> * Does XCI set feature-abs-pointer in xenstore?
>
> * If it does, does it read request-abs-pointer from xenstore?
>
> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
>  under what circumstances (if any) does it send XENKBD_TYPE_POS?
>

Hi,

I just checked and we have feature-abs-pointer and request-abs-pointer
set to 1 xenstore.
The function we use to inject mouse/keyboard event in the guess is
kbd_mouse_event and it works with xenkbd.

Jean

Re: RFC: drop frontend support for relative pointer

[Jean Guyader]

2009/10/12 Jean Guyader <jean.guyader@gmail.com>:
> 2009/10/8 Markus Armbruster <armbru@redhat.com>:
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>>
>>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>>>> 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.
>>>
>>> I guess keeping around unused code doesn't make much sense but I was just
>>> being cautious, given that for example XCI is currently using relative
>>> coordinates so they are not dead just yet.
>>
>> Just to avoid misunderstandings:
>>
>> * Does XCI set feature-abs-pointer in xenstore?
>>
>> * If it does, does it read request-abs-pointer from xenstore?
>>
>> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
>>  under what circumstances (if any) does it send XENKBD_TYPE_POS?
>>
>
> Hi,
>
> I just checked and we have feature-abs-pointer and request-abs-pointer
> set to 1 xenstore.
> The function we use to inject mouse/keyboard event in the guess is
> kbd_mouse_event and it works with xenkbd.
>

I checked into the code and we force xenkb to use relative coordinates.
We use that because in XCI the hardware mouse on the host is generally
setup to send relative coordinates, and we do a 1 to 1 map for the
mouse/keyboard
event.

Jean

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Jean Guyader <jean.guyader@gmail.com> writes:

> 2009/10/12 Jean Guyader <jean.guyader@gmail.com>:
>> 2009/10/8 Markus Armbruster <armbru@redhat.com>:
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>>>
>>>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>>>>> 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.
>>>>
>>>> I guess keeping around unused code doesn't make much sense but I was just
>>>> being cautious, given that for example XCI is currently using relative
>>>> coordinates so they are not dead just yet.
>>>
>>> Just to avoid misunderstandings:
>>>
>>> * Does XCI set feature-abs-pointer in xenstore?
>>>
>>> * If it does, does it read request-abs-pointer from xenstore?
>>>
>>> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
>>>  under what circumstances (if any) does it send XENKBD_TYPE_POS?
>>>
>>
>> Hi,
>>
>> I just checked and we have feature-abs-pointer and request-abs-pointer
>> set to 1 xenstore.
>> The function we use to inject mouse/keyboard event in the guess is
>> kbd_mouse_event and it works with xenkbd.
>>
>
> I checked into the code and we force xenkb to use relative coordinates.
> We use that because in XCI the hardware mouse on the host is generally
> setup to send relative coordinates, and we do a 1 to 1 map for the
> mouse/keyboard
> event.

Thanks for your help.  To sum up:

* The XCI backend advertizes absolute pointers (feature-abs-pointer set
  in xenstore)

* The frontend asks for it (request-abs-pointer set in xenstore)

* Regardless, the XCI backend sends only relative coordinates (event
  type XENKBD_TYPE_POS).

Correct?

If yes, then this works more by accident than by design :)

By setting feature-abs-pointer, the backend offers absolute events.
Reneging on this offer after the frontend accepted it is a bug.

What now?  Could XCI upgrade to absolute?  If not, could it at least
stop offering feature-abs-pointer?

Re: RFC: drop frontend support for relative pointer

[Jean Guyader]

2009/10/12 Markus Armbruster <armbru@redhat.com>:
> Jean Guyader <jean.guyader@gmail.com> writes:
>
>> 2009/10/12 Jean Guyader <jean.guyader@gmail.com>:
>>> 2009/10/8 Markus Armbruster <armbru@redhat.com>:
>>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>>>>
>>>>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>>>>>> 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.
>>>>>
>>>>> I guess keeping around unused code doesn't make much sense but I was just
>>>>> being cautious, given that for example XCI is currently using relative
>>>>> coordinates so they are not dead just yet.
>>>>
>>>> Just to avoid misunderstandings:
>>>>
>>>> * Does XCI set feature-abs-pointer in xenstore?
>>>>
>>>> * If it does, does it read request-abs-pointer from xenstore?
>>>>
>>>> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
>>>>  under what circumstances (if any) does it send XENKBD_TYPE_POS?
>>>>
>>>
>>> Hi,
>>>
>>> I just checked and we have feature-abs-pointer and request-abs-pointer
>>> set to 1 xenstore.
>>> The function we use to inject mouse/keyboard event in the guess is
>>> kbd_mouse_event and it works with xenkbd.
>>>
>>
>> I checked into the code and we force xenkb to use relative coordinates.
>> We use that because in XCI the hardware mouse on the host is generally
>> setup to send relative coordinates, and we do a 1 to 1 map for the
>> mouse/keyboard
>> event.
>
> Thanks for your help.  To sum up:
>

> * The XCI backend advertizes absolute pointers (feature-abs-pointer set
>  in xenstore)
>

Yes.

> * The frontend asks for it (request-abs-pointer set in xenstore)
>
> * Regardless, the XCI backend sends only relative coordinates (event
>  type XENKBD_TYPE_POS).
>
> Correct?
>
> If yes, then this works more by accident than by design :)
>

Yep it does work, that is wrong in our code.
I didn't know about this xenstore protocol when I hacked it up.

Here is the nasty patch:
http://git/git/xenclient/ioemu-pq.git/tree/master/fix-imobile-mouse

> By setting feature-abs-pointer, the backend offers absolute events.
> Reneging on this offer after the frontend accepted it is a bug.
>

Yep, I belive there is a bug somewhere.

> What now?  Could XCI upgrade to absolute?  If not, could it at least
> stop offering feature-abs-pointer?
>
I'll fix that inside our code.

I don't really thing we could use absolute because we do graphic
device pass through with PV guest and the resolution we have on the
screen is completely decouple with the fb resolution.

Jean

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Jean Guyader <jean.guyader@gmail.com> writes:

> 2009/10/12 Markus Armbruster <armbru@redhat.com>:
>> Jean Guyader <jean.guyader@gmail.com> writes:
>>
>>> 2009/10/12 Jean Guyader <jean.guyader@gmail.com>:
>>>> 2009/10/8 Markus Armbruster <armbru@redhat.com>:
>>>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>>>>>
>>>>>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote:
>>>>>>> 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.
>>>>>>
>>>>>> I guess keeping around unused code doesn't make much sense but I was just
>>>>>> being cautious, given that for example XCI is currently using relative
>>>>>> coordinates so they are not dead just yet.
>>>>>
>>>>> Just to avoid misunderstandings:
>>>>>
>>>>> * Does XCI set feature-abs-pointer in xenstore?
>>>>>
>>>>> * If it does, does it read request-abs-pointer from xenstore?
>>>>>
>>>>> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, and
>>>>>  under what circumstances (if any) does it send XENKBD_TYPE_POS?
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I just checked and we have feature-abs-pointer and request-abs-pointer
>>>> set to 1 xenstore.
>>>> The function we use to inject mouse/keyboard event in the guess is
>>>> kbd_mouse_event and it works with xenkbd.
>>>>
>>>
>>> I checked into the code and we force xenkb to use relative coordinates.
>>> We use that because in XCI the hardware mouse on the host is generally
>>> setup to send relative coordinates, and we do a 1 to 1 map for the
>>> mouse/keyboard

What if the physical pointer device uses absolute events?  Do you pass
those on 1:1, too?

>> Thanks for your help.  To sum up:
>>
>
>> * The XCI backend advertizes absolute pointers (feature-abs-pointer set
>>  in xenstore)
>>
>
> Yes.
>
>> * The frontend asks for it (request-abs-pointer set in xenstore)
>>
>> * Regardless, the XCI backend sends only relative coordinates (event
>>  type XENKBD_TYPE_POS).
>>
>> Correct?
>>
>> If yes, then this works more by accident than by design :)
>>
>
> Yep it does work, that is wrong in our code.
> I didn't know about this xenstore protocol when I hacked it up.
>
> Here is the nasty patch:
> http://git/git/xenclient/ioemu-pq.git/tree/master/fix-imobile-mouse

Broken link, please check.

>> By setting feature-abs-pointer, the backend offers absolute events.
>> Reneging on this offer after the frontend accepted it is a bug.
>>
>
> Yep, I belive there is a bug somewhere.
>
>> What now?  Could XCI upgrade to absolute?  If not, could it at least
>> stop offering feature-abs-pointer?
>>
> I'll fix that inside our code.

If you want to pass on absolute events received from your physical
pointer device, then things become a bit more complicated.  You need to
offer feature-abs-pointer, obviously.  But if the frontend declines
(request-abs-pointer off), you can't pass on absolute events, you must
convert to relative.

> I don't really thing we could use absolute because we do graphic
> device pass through with PV guest and the resolution we have on the
> screen is completely decouple with the fb resolution.

I figure the real solution is to decouple the PV pointer/keyboard from
the PV framebuffer, so you can configure the pointer independently, and
don't have to drag a PV framebuffer along, just to get a PV
pointer/keyboard.

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

On Tue, 13 Oct 2009, Markus Armbruster wrote:
> > I don't really thing we could use absolute because we do graphic
> > device pass through with PV guest and the resolution we have on the
> > screen is completely decouple with the fb resolution.
> 
> I figure the real solution is to decouple the PV pointer/keyboard from
> the PV framebuffer, so you can configure the pointer independently, and
> don't have to drag a PV framebuffer along, just to get a PV
> pointer/keyboard.
> 

True, but it still wouldn't solve the problem of dropping relative mouse
coordinates support from vkbd.

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> On Tue, 13 Oct 2009, Markus Armbruster wrote:
>> > I don't really thing we could use absolute because we do graphic
>> > device pass through with PV guest and the resolution we have on the
>> > screen is completely decouple with the fb resolution.
>> 
>> I figure the real solution is to decouple the PV pointer/keyboard from
>> the PV framebuffer, so you can configure the pointer independently, and
>> don't have to drag a PV framebuffer along, just to get a PV
>> pointer/keyboard.
>> 
>
> True, but it still wouldn't solve the problem of dropping relative mouse
> coordinates support from vkbd.

You can always convert between relative and absolute in the backend.
Pointer resolution need not match the graphics resolution (think tablet,
not touchscreen).

Nevertheless, it might be more convenient for this use case to keep
relative around.  Then the backend need only be able to convert from
absolute to relative (for frontends declining feature-abs-pointer), not
the other direction.  XCI is of course free to require a frontend that
doesn't decline.

If we decide to keep relative, we need to restructure pointer frontend
initialization to each axis either relative or absolute.  Unless evdev
developers find a way to continue coping with both.

Re: RFC: drop frontend support for relative pointer

[Jean Guyader]

2009/10/13 Markus Armbruster <armbru@redhat.com>:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>
>> On Tue, 13 Oct 2009, Markus Armbruster wrote:
>>> > I don't really thing we could use absolute because we do graphic
>>> > device pass through with PV guest and the resolution we have on the
>>> > screen is completely decouple with the fb resolution.
>>>
>>> I figure the real solution is to decouple the PV pointer/keyboard from
>>> the PV framebuffer, so you can configure the pointer independently, and
>>> don't have to drag a PV framebuffer along, just to get a PV
>>> pointer/keyboard.
>>>
>>
>> True, but it still wouldn't solve the problem of dropping relative mouse
>> coordinates support from vkbd.
>
> You can always convert between relative and absolute in the backend.
> Pointer resolution need not match the graphics resolution (think tablet,
> not touchscreen).

Even something a touchpad is absolute.

>
> Nevertheless, it might be more convenient for this use case to keep
> relative around.  Then the backend need only be able to convert from
> absolute to relative (for frontends declining feature-abs-pointer), not
> the other direction.  XCI is of course free to require a frontend that
> doesn't decline.
>

We already have some bit of code to do the absolute -> relative conversion.
But we try to avoid dom0 driver to use abusolute of its devices.

> If we decide to keep relative, we need to restructure pointer frontend
> initialization to each axis either relative or absolute.  Unless evdev
> developers find a way to continue coping with both.
>

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

On Tue, 13 Oct 2009, Markus Armbruster wrote:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
> 
> > On Tue, 13 Oct 2009, Markus Armbruster wrote:
> >> > I don't really thing we could use absolute because we do graphic
> >> > device pass through with PV guest and the resolution we have on the
> >> > screen is completely decouple with the fb resolution.
> >> 
> >> I figure the real solution is to decouple the PV pointer/keyboard from
> >> the PV framebuffer, so you can configure the pointer independently, and
> >> don't have to drag a PV framebuffer along, just to get a PV
> >> pointer/keyboard.
> >> 
> >
> > True, but it still wouldn't solve the problem of dropping relative mouse
> > coordinates support from vkbd.
> 
> You can always convert between relative and absolute in the backend.
> Pointer resolution need not match the graphics resolution (think tablet,
> not touchscreen).
> 
> Nevertheless, it might be more convenient for this use case to keep
> relative around.  Then the backend need only be able to convert from
> absolute to relative (for frontends declining feature-abs-pointer), not
> the other direction.  XCI is of course free to require a frontend that
> doesn't decline.
> 
> If we decide to keep relative, we need to restructure pointer frontend
> initialization to each axis either relative or absolute.  Unless evdev
> developers find a way to continue coping with both.
> 

Given that absolute->relative conversion is not very good, I think it is
best to keep relative alive.

Re: RFC: drop frontend support for relative pointer

[Markus Armbruster]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> On Tue, 13 Oct 2009, Markus Armbruster wrote:
>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
>> 
>> > On Tue, 13 Oct 2009, Markus Armbruster wrote:
>> >> > I don't really thing we could use absolute because we do graphic
>> >> > device pass through with PV guest and the resolution we have on the
>> >> > screen is completely decouple with the fb resolution.
>> >> 
>> >> I figure the real solution is to decouple the PV pointer/keyboard from
>> >> the PV framebuffer, so you can configure the pointer independently, and
>> >> don't have to drag a PV framebuffer along, just to get a PV
>> >> pointer/keyboard.
>> >> 
>> >
>> > True, but it still wouldn't solve the problem of dropping relative mouse
>> > coordinates support from vkbd.
>> 
>> You can always convert between relative and absolute in the backend.
>> Pointer resolution need not match the graphics resolution (think tablet,
>> not touchscreen).
>> 
>> Nevertheless, it might be more convenient for this use case to keep
>> relative around.  Then the backend need only be able to convert from
>> absolute to relative (for frontends declining feature-abs-pointer), not
>> the other direction.  XCI is of course free to require a frontend that
>> doesn't decline.
>> 
>> If we decide to keep relative, we need to restructure pointer frontend
>> initialization to each axis either relative or absolute.  Unless evdev
>> developers find a way to continue coping with both.
>> 
>
> Given that absolute->relative conversion is not very good, I think it is
> best to keep relative alive.

Unless you mean relative->absolute, you're not making sense to me :)

Re: RFC: drop frontend support for relative pointer

[Stefano Stabellini]

On Wed, 14 Oct 2009, Markus Armbruster wrote:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
> 
> > On Tue, 13 Oct 2009, Markus Armbruster wrote:
> >> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
> >> 
> >> > On Tue, 13 Oct 2009, Markus Armbruster wrote:
> >> >> > I don't really thing we could use absolute because we do graphic
> >> >> > device pass through with PV guest and the resolution we have on the
> >> >> > screen is completely decouple with the fb resolution.
> >> >> 
> >> >> I figure the real solution is to decouple the PV pointer/keyboard from
> >> >> the PV framebuffer, so you can configure the pointer independently, and
> >> >> don't have to drag a PV framebuffer along, just to get a PV
> >> >> pointer/keyboard.
> >> >> 
> >> >
> >> > True, but it still wouldn't solve the problem of dropping relative mouse
> >> > coordinates support from vkbd.
> >> 
> >> You can always convert between relative and absolute in the backend.
> >> Pointer resolution need not match the graphics resolution (think tablet,
> >> not touchscreen).
> >> 
> >> Nevertheless, it might be more convenient for this use case to keep
> >> relative around.  Then the backend need only be able to convert from
> >> absolute to relative (for frontends declining feature-abs-pointer), not
> >> the other direction.  XCI is of course free to require a frontend that
> >> doesn't decline.
> >> 
> >> If we decide to keep relative, we need to restructure pointer frontend
> >> initialization to each axis either relative or absolute.  Unless evdev
> >> developers find a way to continue coping with both.
> >> 
> >
> > Given that absolute->relative conversion is not very good, I think it is
> > best to keep relative alive.
> 
> Unless you mean relative->absolute, you're not making sense to me :)
>

Yes I meant relative->absolute, sorry for the confusion.