Re: [Xen-devel] RFC: drop frontend support for relative pointer

[Markus Armbruster <armbru@xxxxxxxxxx>]

Jean Guyader <jean.guyader@xxxxxxxxx> writes:

> 2009/10/12 Markus Armbruster <armbru@xxxxxxxxxx>:
>> Jean Guyader <jean.guyader@xxxxxxxxx> writes:
>>
>>> 2009/10/12 Jean Guyader <jean.guyader@xxxxxxxxx>:
>>>> 2009/10/8 Markus Armbruster <armbru@xxxxxxxxxx>:
>>>>> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel