Xen devel - Oct 2009 - RFC: drop frontend support for relative pointer

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel