pvfb: Absolute vs relative mouse tracking mystery

pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On one of my host machines, in PV guests using pvfb I get proper
absolute mouse tracking.

On another host machine, I get relative tracking in pvfb-using guests.

Both are using identical versions of Fedora 12, identical domain
configs, and toolstacks and kernels built from the same source.  The log
files of the X servers are more or less identical.

Help?  Any clues?

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Stefano Stabellini]

On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
> On one of my host machines, in PV guests using pvfb I get proper
> absolute mouse tracking.
> 
> On another host machine, I get relative tracking in pvfb-using guests.
> 
> Both are using identical versions of Fedora 12, identical domain
> configs, and toolstacks and kernels built from the same source.  The log
> files of the X servers are more or less identical.
> 
> Help?  Any clues?
> 

relative vs absolute depends on a node on xenstore called
"request-abs-pointer" that defaults to 0 and has to be written by the
guest.

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
>   
>> On one of my host machines, in PV guests using pvfb I get proper
>> absolute mouse tracking.
>>
>> On another host machine, I get relative tracking in pvfb-using guests.
>>
>> Both are using identical versions of Fedora 12, identical domain
>> configs, and toolstacks and kernels built from the same source.  The log
>> files of the X servers are more or less identical.
>>
>> Help?  Any clues?
>>
>>     
> relative vs absolute depends on a node on xenstore called
> "request-abs-pointer" that defaults to 0 and has to be written by the
> guest.

Thanks, that gives me something to start with.

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
>   
>> On one of my host machines, in PV guests using pvfb I get proper
>> absolute mouse tracking.
>>
>> On another host machine, I get relative tracking in pvfb-using guests.
>>
>> Both are using identical versions of Fedora 12, identical domain
>> configs, and toolstacks and kernels built from the same source.  The log
>> files of the X servers are more or less identical.
>>
>> Help?  Any clues?
>>
>>     
> relative vs absolute depends on a node on xenstore called
> "request-abs-pointer" that defaults to 0 and has to be written by the
> guest.
>   

OK, it looks like it is being set, but the guest is still showing
relative behaviour:

    vkbd = ""
     0 = ""
      backend = "/local/domain/0/backend/vkbd/5/0"
      backend-id = "0"
      state = "4"
      page-ref = "1137660"
      event-channel = "11"
      request-abs-pointer = "1"

Does this mean qemu-dm's vnc server is not doing the right thing?

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Stefano Stabellini]

On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> > On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
> >   
> >> On one of my host machines, in PV guests using pvfb I get proper
> >> absolute mouse tracking.
> >>
> >> On another host machine, I get relative tracking in pvfb-using guests.
> >>
> >> Both are using identical versions of Fedora 12, identical domain
> >> configs, and toolstacks and kernels built from the same source.  The log
> >> files of the X servers are more or less identical.
> >>
> >> Help?  Any clues?
> >>
> >>     
> > relative vs absolute depends on a node on xenstore called
> > "request-abs-pointer" that defaults to 0 and has to be written by the
> > guest.
> >   
> 
> OK, it looks like it is being set, but the guest is still showing
> relative behaviour:
> 
>     vkbd = ""
>      0 = ""
>       backend = "/local/domain/0/backend/vkbd/5/0"
>       backend-id = "0"
>       state = "4"
>       page-ref = "1137660"
>       event-channel = "11"
>       request-abs-pointer = "1"
> 
> Does this mean qemu-dm's vnc server is not doing the right thing?
 
I think is probably xenfb (that is the framebuffer backend in qemu) that
is not doing the right thing.
Try adding some debug output in hw/xenfb.c:input_connect.

Re: pvfb: Absolute vs relative mouse tracking mystery

[Pasi Kärkkäinen]

On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
> > On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> > > On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
> > >   
> > >> On one of my host machines, in PV guests using pvfb I get proper
> > >> absolute mouse tracking.
> > >>
> > >> On another host machine, I get relative tracking in pvfb-using guests.
> > >>
> > >> Both are using identical versions of Fedora 12, identical domain
> > >> configs, and toolstacks and kernels built from the same source.  The log
> > >> files of the X servers are more or less identical.
> > >>
> > >> Help?  Any clues?
> > >>
> > >>     
> > > relative vs absolute depends on a node on xenstore called
> > > "request-abs-pointer" that defaults to 0 and has to be written by the
> > > guest.
> > >   
> > 
> > OK, it looks like it is being set, but the guest is still showing
> > relative behaviour:
> > 
> >     vkbd = ""
> >      0 = ""
> >       backend = "/local/domain/0/backend/vkbd/5/0"
> >       backend-id = "0"
> >       state = "4"
> >       page-ref = "1137660"
> >       event-channel = "11"
> >       request-abs-pointer = "1"
> > 
> > Does this mean qemu-dm's vnc server is not doing the right thing?
>  
> I think is probably xenfb (that is the framebuffer backend in qemu) that
> is not doing the right thing.
> Try adding some debug output in hw/xenfb.c:input_connect.
> 

Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..

-- Pasi

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 06/19/2010 04:41 PM, Pasi Kärkkäinen wrote:
> On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
>   
>> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
>>     
>>> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
>>>       
>>>> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
>>>>   
>>>>         
>>>>> On one of my host machines, in PV guests using pvfb I get proper
>>>>> absolute mouse tracking.
>>>>>
>>>>> On another host machine, I get relative tracking in pvfb-using guests.
>>>>>
>>>>> Both are using identical versions of Fedora 12, identical domain
>>>>> configs, and toolstacks and kernels built from the same source.  The log
>>>>> files of the X servers are more or less identical.
>>>>>
>>>>> Help?  Any clues?
>>>>>
>>>>>     
>>>>>           
>>>> relative vs absolute depends on a node on xenstore called
>>>> "request-abs-pointer" that defaults to 0 and has to be written by the
>>>> guest.
>>>>   
>>>>         
>>> OK, it looks like it is being set, but the guest is still showing
>>> relative behaviour:
>>>
>>>     vkbd = ""
>>>      0 = ""
>>>       backend = "/local/domain/0/backend/vkbd/5/0"
>>>       backend-id = "0"
>>>       state = "4"
>>>       page-ref = "1137660"
>>>       event-channel = "11"
>>>       request-abs-pointer = "1"
>>>
>>> Does this mean qemu-dm's vnc server is not doing the right thing?
>>>       
>>  
>> I think is probably xenfb (that is the framebuffer backend in qemu) that
>> is not doing the right thing.
>> Try adding some debug output in hw/xenfb.c:input_connect.
>>
>>     
> Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
>   

Yes, that should be fixed in current xen-unstable - it was a xenbus
race-condition.  What guest are you seeing it in?  I've found that I
still don't get absolute pointers in Centos guests.

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Pasi Kärkkäinen]

On Sat, Jun 19, 2010 at 04:48:46PM +0100, Jeremy Fitzhardinge wrote:
> On 06/19/2010 04:41 PM, Pasi Kärkkäinen wrote:
> > On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
> >   
> >> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
> >>     
> >>> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> >>>       
> >>>> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
> >>>>   
> >>>>         
> >>>>> On one of my host machines, in PV guests using pvfb I get proper
> >>>>> absolute mouse tracking.
> >>>>>
> >>>>> On another host machine, I get relative tracking in pvfb-using guests.
> >>>>>
> >>>>> Both are using identical versions of Fedora 12, identical domain
> >>>>> configs, and toolstacks and kernels built from the same source.  The log
> >>>>> files of the X servers are more or less identical.
> >>>>>
> >>>>> Help?  Any clues?
> >>>>>
> >>>>>     
> >>>>>           
> >>>> relative vs absolute depends on a node on xenstore called
> >>>> "request-abs-pointer" that defaults to 0 and has to be written by the
> >>>> guest.
> >>>>   
> >>>>         
> >>> OK, it looks like it is being set, but the guest is still showing
> >>> relative behaviour:
> >>>
> >>>     vkbd = ""
> >>>      0 = ""
> >>>       backend = "/local/domain/0/backend/vkbd/5/0"
> >>>       backend-id = "0"
> >>>       state = "4"
> >>>       page-ref = "1137660"
> >>>       event-channel = "11"
> >>>       request-abs-pointer = "1"
> >>>
> >>> Does this mean qemu-dm's vnc server is not doing the right thing?
> >>>       
> >>  
> >> I think is probably xenfb (that is the framebuffer backend in qemu) that
> >> is not doing the right thing.
> >> Try adding some debug output in hw/xenfb.c:input_connect.
> >>
> >>     
> > Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
> >   
> 
> Yes, that should be fixed in current xen-unstable - it was a xenbus
> race-condition.  What guest are you seeing it in?  I've found that I
> still don't get absolute pointers in Centos guests.
> 

Yeah, it's a CentOS 5.5 guest that gets relative pointer on my Fedora 13 dom0.
On a CentOS5 dom0 it gets absolute though..

Fedora 13 guest gets absolute pointer on my Fedora 13 dom0..

-- Pasi

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 06/19/2010 05:22 PM, Pasi Kärkkäinen wrote:
> On Sat, Jun 19, 2010 at 04:48:46PM +0100, Jeremy Fitzhardinge wrote:
>   
>> On 06/19/2010 04:41 PM, Pasi Kärkkäinen wrote:
>>     
>>> On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
>>>   
>>>       
>>>> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
>>>>     
>>>>         
>>>>> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
>>>>>       
>>>>>           
>>>>>> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
>>>>>>   
>>>>>>         
>>>>>>             
>>>>>>> On one of my host machines, in PV guests using pvfb I get proper
>>>>>>> absolute mouse tracking.
>>>>>>>
>>>>>>> On another host machine, I get relative tracking in pvfb-using guests.
>>>>>>>
>>>>>>> Both are using identical versions of Fedora 12, identical domain
>>>>>>> configs, and toolstacks and kernels built from the same source.  The log
>>>>>>> files of the X servers are more or less identical.
>>>>>>>
>>>>>>> Help?  Any clues?
>>>>>>>
>>>>>>>     
>>>>>>>           
>>>>>>>               
>>>>>> relative vs absolute depends on a node on xenstore called
>>>>>> "request-abs-pointer" that defaults to 0 and has to be written by the
>>>>>> guest.
>>>>>>   
>>>>>>         
>>>>>>             
>>>>> OK, it looks like it is being set, but the guest is still showing
>>>>> relative behaviour:
>>>>>
>>>>>     vkbd = ""
>>>>>      0 = ""
>>>>>       backend = "/local/domain/0/backend/vkbd/5/0"
>>>>>       backend-id = "0"
>>>>>       state = "4"
>>>>>       page-ref = "1137660"
>>>>>       event-channel = "11"
>>>>>       request-abs-pointer = "1"
>>>>>
>>>>> Does this mean qemu-dm's vnc server is not doing the right thing?
>>>>>       
>>>>>           
>>>>  
>>>> I think is probably xenfb (that is the framebuffer backend in qemu) that
>>>> is not doing the right thing.
>>>> Try adding some debug output in hw/xenfb.c:input_connect.
>>>>
>>>>     
>>>>         
>>> Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
>>>   
>>>       
>> Yes, that should be fixed in current xen-unstable - it was a xenbus
>> race-condition.  What guest are you seeing it in?  I've found that I
>> still don't get absolute pointers in Centos guests.
>>
>>     
> Yeah, it's a CentOS 5.5 guest that gets relative pointer on my Fedora 13 dom0.
> On a CentOS5 dom0 it gets absolute though..
>
> Fedora 13 guest gets absolute pointer on my Fedora 13 dom0..
>   

Huh, that is interesting.  Maybe there's still a race or something there...

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Pasi Kärkkäinen]

On Sat, Jun 19, 2010 at 06:40:10PM +0100, Jeremy Fitzhardinge wrote:
> On 06/19/2010 05:22 PM, Pasi Kärkkäinen wrote:
> > On Sat, Jun 19, 2010 at 04:48:46PM +0100, Jeremy Fitzhardinge wrote:
> >   
> >> On 06/19/2010 04:41 PM, Pasi Kärkkäinen wrote:
> >>     
> >>> On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
> >>>   
> >>>       
> >>>> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
> >>>>     
> >>>>         
> >>>>> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
> >>>>>       
> >>>>>           
> >>>>>> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
> >>>>>>   
> >>>>>>         
> >>>>>>             
> >>>>>>> On one of my host machines, in PV guests using pvfb I get proper
> >>>>>>> absolute mouse tracking.
> >>>>>>>
> >>>>>>> On another host machine, I get relative tracking in pvfb-using guests.
> >>>>>>>
> >>>>>>> Both are using identical versions of Fedora 12, identical domain
> >>>>>>> configs, and toolstacks and kernels built from the same source.  The log
> >>>>>>> files of the X servers are more or less identical.
> >>>>>>>
> >>>>>>> Help?  Any clues?
> >>>>>>>
> >>>>>>>     
> >>>>>>>           
> >>>>>>>               
> >>>>>> relative vs absolute depends on a node on xenstore called
> >>>>>> "request-abs-pointer" that defaults to 0 and has to be written by the
> >>>>>> guest.
> >>>>>>   
> >>>>>>         
> >>>>>>             
> >>>>> OK, it looks like it is being set, but the guest is still showing
> >>>>> relative behaviour:
> >>>>>
> >>>>>     vkbd = ""
> >>>>>      0 = ""
> >>>>>       backend = "/local/domain/0/backend/vkbd/5/0"
> >>>>>       backend-id = "0"
> >>>>>       state = "4"
> >>>>>       page-ref = "1137660"
> >>>>>       event-channel = "11"
> >>>>>       request-abs-pointer = "1"
> >>>>>
> >>>>> Does this mean qemu-dm's vnc server is not doing the right thing?
> >>>>>       
> >>>>>           
> >>>>  
> >>>> I think is probably xenfb (that is the framebuffer backend in qemu) that
> >>>> is not doing the right thing.
> >>>> Try adding some debug output in hw/xenfb.c:input_connect.
> >>>>
> >>>>     
> >>>>         
> >>> Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
> >>>   
> >>>       
> >> Yes, that should be fixed in current xen-unstable - it was a xenbus
> >> race-condition.  What guest are you seeing it in?  I've found that I
> >> still don't get absolute pointers in Centos guests.
> >>
> >>     
> > Yeah, it's a CentOS 5.5 guest that gets relative pointer on my Fedora 13 dom0.
> > On a CentOS5 dom0 it gets absolute though..
> >
> > Fedora 13 guest gets absolute pointer on my Fedora 13 dom0..
> >   
> 
> Huh, that is interesting.  Maybe there's still a race or something there...
> 

Yeah.. maybe. Note that I'm running Xen 4.0.1-rc3-pre and not xen-unstable..

-- Pasi

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 06/19/2010 10:50 AM, Pasi Kärkkäinen wrote:
> On Sat, Jun 19, 2010 at 06:40:10PM +0100, Jeremy Fitzhardinge wrote:
>   
>> On 06/19/2010 05:22 PM, Pasi Kärkkäinen wrote:
>>     
>>> On Sat, Jun 19, 2010 at 04:48:46PM +0100, Jeremy Fitzhardinge wrote:
>>>   
>>>       
>>>> On 06/19/2010 04:41 PM, Pasi Kärkkäinen wrote:
>>>>     
>>>>         
>>>>> On Tue, May 11, 2010 at 11:56:38AM +0100, Stefano Stabellini wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On 05/10/2010 07:41 AM, Stefano Stabellini wrote:
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> On Fri, 7 May 2010, Jeremy Fitzhardinge wrote:
>>>>>>>>   
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> On one of my host machines, in PV guests using pvfb I get proper
>>>>>>>>> absolute mouse tracking.
>>>>>>>>>
>>>>>>>>> On another host machine, I get relative tracking in pvfb-using guests.
>>>>>>>>>
>>>>>>>>> Both are using identical versions of Fedora 12, identical domain
>>>>>>>>> configs, and toolstacks and kernels built from the same source.  The log
>>>>>>>>> files of the X servers are more or less identical.
>>>>>>>>>
>>>>>>>>> Help?  Any clues?
>>>>>>>>>
>>>>>>>>>     
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> relative vs absolute depends on a node on xenstore called
>>>>>>>> "request-abs-pointer" that defaults to 0 and has to be written by the
>>>>>>>> guest.
>>>>>>>>   
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> OK, it looks like it is being set, but the guest is still showing
>>>>>>> relative behaviour:
>>>>>>>
>>>>>>>     vkbd = ""
>>>>>>>      0 = ""
>>>>>>>       backend = "/local/domain/0/backend/vkbd/5/0"
>>>>>>>       backend-id = "0"
>>>>>>>       state = "4"
>>>>>>>       page-ref = "1137660"
>>>>>>>       event-channel = "11"
>>>>>>>       request-abs-pointer = "1"
>>>>>>>
>>>>>>> Does this mean qemu-dm's vnc server is not doing the right thing?
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>  
>>>>>> I think is probably xenfb (that is the framebuffer backend in qemu) that
>>>>>> is not doing the right thing.
>>>>>> Try adding some debug output in hw/xenfb.c:input_connect.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, that should be fixed in current xen-unstable - it was a xenbus
>>>> race-condition.  What guest are you seeing it in?  I've found that I
>>>> still don't get absolute pointers in Centos guests.
>>>>
>>>>     
>>>>         
>>> Yeah, it's a CentOS 5.5 guest that gets relative pointer on my Fedora 13 dom0.
>>> On a CentOS5 dom0 it gets absolute though..
>>>
>>> Fedora 13 guest gets absolute pointer on my Fedora 13 dom0..
>>>   
>>>       
>> Huh, that is interesting.  Maybe there's still a race or something there...
>>
>>     
> Yeah.. maybe. Note that I'm running Xen 4.0.1-rc3-pre and not xen-unstable..
>   

I just got a Win7 hvm domain working for the first time in a while, and
found that it *isn't* getting proper abs updates.  I even set
usbdevice='tablet' in its config...

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Pasi Kärkkäinen]

On Wed, Jul 21, 2010 at 06:01:28PM -0700, Jeremy Fitzhardinge wrote:
> >>>>>>>>                 
> >>>>>>>>> On one of my host machines, in PV guests using pvfb I get proper
> >>>>>>>>> absolute mouse tracking.
> >>>>>>>>>
> >>>>>>>>> On another host machine, I get relative tracking in pvfb-using guests.
> >>>>>>>>>
> >>>>>>>>> Both are using identical versions of Fedora 12, identical domain
> >>>>>>>>> configs, and toolstacks and kernels built from the same source.  The log
> >>>>>>>>> files of the X servers are more or less identical.
> >>>>>>>>>
> >>>>>>>>> Help?  Any clues?
> >>>>>>>>>
> >>>>>>>>>     
> >>>>>>>>>           
> >>>>>>>>>               
> >>>>>>>>>                   
> >>>>>>>> relative vs absolute depends on a node on xenstore called
> >>>>>>>> "request-abs-pointer" that defaults to 0 and has to be written by the
> >>>>>>>> guest.
> >>>>>>>>   
> >>>>>>>>         
> >>>>>>>>             
> >>>>>>>>                 
> >>>>>>> OK, it looks like it is being set, but the guest is still showing
> >>>>>>> relative behaviour:
> >>>>>>>
> >>>>>>>     vkbd = ""
> >>>>>>>      0 = ""
> >>>>>>>       backend = "/local/domain/0/backend/vkbd/5/0"
> >>>>>>>       backend-id = "0"
> >>>>>>>       state = "4"
> >>>>>>>       page-ref = "1137660"
> >>>>>>>       event-channel = "11"
> >>>>>>>       request-abs-pointer = "1"
> >>>>>>>
> >>>>>>> Does this mean qemu-dm's vnc server is not doing the right thing?
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>>  
> >>>>>> I think is probably xenfb (that is the framebuffer backend in qemu) that
> >>>>>> is not doing the right thing.
> >>>>>> Try adding some debug output in hw/xenfb.c:input_connect.
> >>>>>>
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Jeremy: Did you figure this out? I'm again seeing this problem on my Fedora 13 + Xen 4.0.1-rc3-pre box..
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> Yes, that should be fixed in current xen-unstable - it was a xenbus
> >>>> race-condition.  What guest are you seeing it in?  I've found that I
> >>>> still don't get absolute pointers in Centos guests.
> >>>>
> >>>>     
> >>>>         
> >>> Yeah, it's a CentOS 5.5 guest that gets relative pointer on my Fedora 13 dom0.
> >>> On a CentOS5 dom0 it gets absolute though..
> >>>
> >>> Fedora 13 guest gets absolute pointer on my Fedora 13 dom0..
> >>>   
> >>>       
> >> Huh, that is interesting.  Maybe there's still a race or something there...
> >>
> >>     
> > Yeah.. maybe. Note that I'm running Xen 4.0.1-rc3-pre and not xen-unstable..
> >   
> 
> I just got a Win7 hvm domain working for the first time in a while, and
> found that it *isn't* getting proper abs updates.  I even set
> usbdevice='tablet' in its config...
> 

Ok. And reading my own lines above, I realize F13 worked for me earlier,
but it was centos 5.5 that didn't work.

I'll have to re-test things here aswell :)

-- Pasi

Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]


On 22 Jul 2010, at 09:52, Pasi Kärkkäinen wrote:
> Ok. And reading my own lines above, I realize F13 worked for me earlier,
> but it was centos 5.5 that didn't work.
> 
> I'll have to re-test things here aswell :)

For F13 and RHEL6 you'll probably need the connected-state patches I posted a little while ago for F13 reliably though -- http://markmail.org/message/jtkqbgs5xw7vqvst -- they were committed to qemu-xen-unstable recently.  There was a different patch earlier that caused trouble which this patch fixed.

CentOS 5.5 (and RHEL5.5) deliberately turns off request-abs-pointer in favour of relative pointers.  

The excuse given is that the RHEL5 X server isn't up to the job of dealing with absolute pointers.  The claim is that you get better responsiveness with relative pointers and a gtk-vnc-based viewers.

Having said that I fix the evdev driver, the various X configuration utilities and anaconda to get absolute pointers working in CentOS/RHEL5.4.

I haven't tried the same set of patches with 5.5 but I think a different approach is needed, one that doesn't need to touch quite so much of the Red Hat base.

jch

[-- Attachment #1.2: Type: text/html, Size: 1670 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 07/22/2010 12:04 PM, John Haxby wrote:
> CentOS 5.5 (and RHEL5.5) deliberately turns off request-abs-pointer in
> favour of relative pointers.  
>
> The excuse given is that the RHEL5 X server isn't up to the job of
> dealing with absolute pointers.  The claim is that you get better
> responsiveness with relative pointers and a gtk-vnc-based viewers.

Er, what?  How do they get it to work properly then?  Is there any way
to make it use abs?

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby]

  On 22/07/10 20:13, Jeremy Fitzhardinge wrote:
> On 07/22/2010 12:04 PM, John Haxby wrote:
>> CentOS 5.5 (and RHEL5.5) deliberately turns off request-abs-pointer in
>> favour of relative pointers.
>>
>> The excuse given is that the RHEL5 X server isn't up to the job of
>> dealing with absolute pointers.  The claim is that you get better
>> responsiveness with relative pointers and a gtk-vnc-based viewers.
> Er, what?  How do they get it to work properly then?  Is there any way
> to make it use abs?
>

The bug for this is https://bugzilla.redhat.com/show_bug.cgi?id=492866

That doesn't explain much, but the corresponding patch to the RHEL 
kernel has this to say:

>     The Xen para-virtual frame buffer protocol supports absolute and
>     relative pointer events.  The backend sends absolute pointer 
> events only
>     if the frontend has agreed to that feature.
>
>     For reasons that seemed sensible at the time, the RHEL-5 frontend 
> always
>     agrees, even though RHEL-5 user-space is incapable of actually running
>     the mouse in absolute mode without manual configuration.  So, out 
> of the
>     box, the guest kernel is doing abs -> rel coordinate conversion.  This
>     in turn causes problems for anyone connecting to the guest using 
> the VNC
>     server in the host, because their mouse pointer is prone to hit an
>     "invisible wall".
>
>     The out-of-the-box experience is much better with relative pointer
>     events.  It is better still with user-space correctly set up for
>     absolute pointer events.
>
>     This patch makes the xenkbd driver reject absolute pointers, 
> unless they
>     This patch makes the xenkbd driver reject absolute pointers, 
> unless they
>     are enabled with kernel parameter xenkbd.abs_pointer=1.  Improves the
>     out-of-the box user experience, and still allows those who care for an
>     even better experience to manually set that up.


The "out-of-the-box experience" relies on you using a gtk-vnc-based VNC 
viewer that grabs the mouse and turns off the visible local mouse 
pointer so it can work properly.  When I tried it it didn't seem that 
great and, of course, it doesn't work at all when you're using a 
java-plugin VNC viewer from Windows where you can't turn off the local 
mouse pointer.

It is possible to fix RHEL5 so that you can configure the Xen mouse 
properly -- I did it.  However, the way I did it involved fixing the X11 
evdev driver since evdev interface provides both mouse and keyboard but 
the evdev driver doesn't do XKB.   Configuring all that took some doing, 
but it can be done automatically and I even retrofitted the changes into 
anaconda so that it all worked properly at installation time as well.

Is there a better way to talk to the xen mouse?  One that means that we 
can get the absolute events and give them to the X server?   A new mouse 
driver is likely to be less painful than the far-reaching attempt I 
tried before.

jch

Re: pvfb: Absolute vs relative mouse tracking mystery

[Stefano Stabellini]

On Thu, 22 Jul 2010, Jeremy Fitzhardinge wrote:
> I just got a Win7 hvm domain working for the first time in a while, and
> found that it *isn't* getting proper abs updates.  I even set
> usbdevice='tablet' in its config...
 
Are you sure?
The vfb connection between qemu and the stubdom is definitely based on
absolute mouse events in my tests.

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 07/22/2010 04:58 AM, Stefano Stabellini wrote:
> On Thu, 22 Jul 2010, Jeremy Fitzhardinge wrote:
>   
>> I just got a Win7 hvm domain working for the first time in a while, and
>> found that it *isn't* getting proper abs updates.  I even set
>> usbdevice='tablet' in its config...
>>     
>  
> Are you sure?
> The vfb connection between qemu and the stubdom is definitely based on
> absolute mouse events in my tests.
>   

Yep.  I created a domain and its getting relative pointer:

sh-4.0# xl create  -d /etc/xen/win7-ctxs 
Parsing config file /etc/xen/win7-ctxs
(domain
	(domid -1)
	(domain_create_info)
	(hvm 1)
	(hap 1)
	(oos 1)
	(ssidref 0)
	(name win7-ctxs)
	(uuid 8badafad-1c63-8812-b082-2b1cc9002a8d)
	(cpupool Pool-0 (0))
	(xsdata (null))
	(platformdata (null))
	(domain_build_info)
	(max_vcpus 2)
	(tsc_mode 0)
	(max_memkb 1048576)
	(target_memkb 1048576)
	(nomigrate 0)
	(image
		(hvm
			(loader /usr/lib/xen/boot/hvmloader)
			(video_memkb 8192)
			(shadow_memkb 10240)
			(pae 1)
			(apic 1)
			(acpi 1)
			(nx 1)
			(viridian 1)
			(hpet 1)
			(vpt_align 1)
			(timer_mode 1)
			(device_model stubdom-dm)
			(videoram 8)
			(stdvga 0)
			(vnc 1)
			(vnclisten 0.0.0.0)
			(vncdisplay 0)
			(vncunused 1)
			(keymap (null))
			(sdl 0)
			(opengl 0)
			(nographic 0)
			(serial pty)
			(boot cda)
			(usb 0)
			(usbdevice tablet)
			(apic 1)
		)
	)
	(device
		(tap
			(backend_domid 0)
			(domid 0)
			(physpath /dev/vg_lilith-raid/xen-win7-ctxs)
			(phystype 4)
			(virtpath hda)
			(unpluggable 1)
			(readwrite 1)
			(is_cdrom 0)
		)
	)
	(device
		(vif
			(backend_domid 0)
			(domid 0)
			(devid 0)
			(mtu 1492)
			(model e1000)
			(mac 00163e23f8c2)
		)
	)
)
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001766ec
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000


    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 07/22/2010 09:51 AM, Jeremy Fitzhardinge wrote:
> 			(usb 0)
> 			(usbdevice tablet)
>   

But setting usb=1 fixes it.  I didn't have to do that before, so
presumably general usb support wasn't needed to enable mouse/tablet
support...

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Stefano Stabellini]

On Thu, 22 Jul 2010, Jeremy Fitzhardinge wrote:
> On 07/22/2010 09:51 AM, Jeremy Fitzhardinge wrote:
> > 			(usb 0)
> > 			(usbdevice tablet)
> >   
> 
> But setting usb=1 fixes it.  I didn't have to do that before, so
> presumably general usb support wasn't needed to enable mouse/tablet
> support...
> 
 
Obviously usbdevice should imply usb, this is the patch that fixed it:

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff -r b0b1a6163203 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jul 22 15:24:49 2010 +0100
+++ b/tools/libxl/libxl.c	Fri Jul 23 12:54:20 2010 +0100
@@ -984,7 +984,7 @@ static char ** libxl_build_device_model_
             flexarray_set(dm_args, num++, "-boot");
             flexarray_set(dm_args, num++, info->boot);
         }
-        if (info->usb) {
+        if (info->usb || info->usbdevice) {
             flexarray_set(dm_args, num++, "-usb");
             if (info->usbdevice) {
                 flexarray_set(dm_args, num++, "-usbdevice");

Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby]

On 19/06/10 16:48, Jeremy Fitzhardinge wrote:
> Yes, that should be fixed in current xen-unstable - it was a xenbus
> race-condition.  What guest are you seeing it in?  I've found that I
> still don't get absolute pointers in Centos guests.
>
>    

Do you know what the changeset it?  This has been bugging me for a while 
-- every now and again (just to taunt me) I get an absolute pointer.

BTW, RHEL5 does some strange stuff to force relative pointers which 
seems crazy to me.

jch

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

On 06/21/2010 03:57 PM, John Haxby wrote:
> On 19/06/10 16:48, Jeremy Fitzhardinge wrote:
>> Yes, that should be fixed in current xen-unstable - it was a xenbus
>> race-condition.  What guest are you seeing it in?  I've found that I
>> still don't get absolute pointers in Centos guests.
>>
>>    
>
> Do you know what the changeset it?  This has been bugging me for a
> while -- every now and again (just to taunt me) I get an absolute
> pointer.

It's in the qemu code, so you may need to explicitly make sure that has
been updated: "cd tools/ioemu-remote; git pull".

    J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 03:59:36PM +0100, Jeremy Fitzhardinge wrote:
> On 06/21/2010 03:57 PM, John Haxby wrote:
> > On 19/06/10 16:48, Jeremy Fitzhardinge wrote:
> >> Yes, that should be fixed in current xen-unstable - it was a xenbus
> >> race-condition.  What guest are you seeing it in?  I've found that I
> >> still don't get absolute pointers in Centos guests.
> >>
> >>    
> >
> > Do you know what the changeset it?  This has been bugging me for a
> > while -- every now and again (just to taunt me) I get an absolute
> > pointer.
> 
> It's in the qemu code, so you may need to explicitly make sure that has
> been updated: "cd tools/ioemu-remote; git pull".
> 

Xen 4.0.1-rc4 with 2.6.32.16 pvops dom0 kernel seems to be OK,
no absolute/relative problems anymore.

Fedora 13 PV guest installer gets absolute mouse every time now.

-- Pasi

Re: pvfb: Absolute vs relative mouse tracking mystery

[Joshua West]

  On 06/21/2010 10:59 AM, Jeremy Fitzhardinge wrote:
> On 06/21/2010 03:57 PM, John Haxby wrote:
>> On 19/06/10 16:48, Jeremy Fitzhardinge wrote:
>>> Yes, that should be fixed in current xen-unstable - it was a xenbus
>>> race-condition.  What guest are you seeing it in?  I've found that I
>>> still don't get absolute pointers in Centos guests.
>>>
>>>
>> Do you know what the changeset it?  This has been bugging me for a
>> while -- every now and again (just to taunt me) I get an absolute
>> pointer.
> It's in the qemu code, so you may need to explicitly make sure that has
> been updated: "cd tools/ioemu-remote; git pull".
>
>      J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
Jeremy,

Do you know if this will be fixed in the Xen 3.4.x series as well?  In 
the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?

I ask because this is an issue for me on RHEL5 domU's which are 
paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not yet 
ready to switch production clusters to 4.0.x.

Thanks.

-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

  On 08/01/2010 12:11 PM, Joshua West wrote:
>  On 06/21/2010 10:59 AM, Jeremy Fitzhardinge wrote:
>> On 06/21/2010 03:57 PM, John Haxby wrote:
>>> On 19/06/10 16:48, Jeremy Fitzhardinge wrote:
>>>> Yes, that should be fixed in current xen-unstable - it was a xenbus
>>>> race-condition.  What guest are you seeing it in?  I've found that I
>>>> still don't get absolute pointers in Centos guests.
>>>>
>>>>
>>> Do you know what the changeset it?  This has been bugging me for a
>>> while -- every now and again (just to taunt me) I get an absolute
>>> pointer.
>> It's in the qemu code, so you may need to explicitly make sure that has
>> been updated: "cd tools/ioemu-remote; git pull".
>>
>>      J
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> Jeremy,
>
> Do you know if this will be fixed in the Xen 3.4.x series as well?  In 
> the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?
>
> I ask because this is an issue for me on RHEL5 domU's which are 
> paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not 
> yet ready to switch production clusters to 4.0.x.

RHEL/CentOS5 deliberately avoids using the absolute pointer mode for 
reasons I don't understand, so it is broken as expected.

     J

Re: pvfb: Absolute vs relative mouse tracking mystery

[Joshua West]

  On 08/02/10 15:00, Jeremy Fitzhardinge wrote:
>  On 08/01/2010 12:11 PM, Joshua West wrote:
>> Jeremy,
>>
>> Do you know if this will be fixed in the Xen 3.4.x series as well?  
>> In the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?
>>
>> I ask because this is an issue for me on RHEL5 domU's which are 
>> paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not 
>> yet ready to switch production clusters to 4.0.x.
>
> RHEL/CentOS5 deliberately avoids using the absolute pointer mode for 
> reasons I don't understand, so it is broken as expected.
>
>     J

Ahh yes, but thats if you're using the RHEL/CentOS Xen kernel.  I'm not 
using a RHEL kernel... instead I'm using linux-2.6.18-xen.hg, but still 
the issue persists on RHEL5 domU's.


-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: pvfb: Absolute vs relative mouse tracking mystery

[Jeremy Fitzhardinge]

  On 08/02/2010 12:37 PM, Joshua West wrote:
>  On 08/02/10 15:00, Jeremy Fitzhardinge wrote:
>>  On 08/01/2010 12:11 PM, Joshua West wrote:
>>> Jeremy,
>>>
>>> Do you know if this will be fixed in the Xen 3.4.x series as well?  
>>> In the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?
>>>
>>> I ask because this is an issue for me on RHEL5 domU's which are 
>>> paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not 
>>> yet ready to switch production clusters to 4.0.x.
>>
>> RHEL/CentOS5 deliberately avoids using the absolute pointer mode for 
>> reasons I don't understand, so it is broken as expected.
>>
>>     J
>
> Ahh yes, but thats if you're using the RHEL/CentOS Xen kernel.  I'm 
> not using a RHEL kernel... instead I'm using linux-2.6.18-xen.hg, but 
> still the issue persists on RHEL5 domU's.

OK, in that case it would be worth looking at backporting the changes to 
older Xens.

     J

Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby]

On 2 Aug 2010, at 20:40, Jeremy Fitzhardinge wrote:

> On 08/02/2010 12:37 PM, Joshua West wrote:
>> On 08/02/10 15:00, Jeremy Fitzhardinge wrote:
>>> On 08/01/2010 12:11 PM, Joshua West wrote:
>>>> Jeremy,
>>>> 
>>>> Do you know if this will be fixed in the Xen 3.4.x series as well?  In the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?
>>>> 
>>>> I ask because this is an issue for me on RHEL5 domU's which are paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not yet ready to switch production clusters to 4.0.x.
>>> 
>>> RHEL/CentOS5 deliberately avoids using the absolute pointer mode for reasons I don't understand, so it is broken as expected.
>>> 
>>>    J
>> 
>> Ahh yes, but thats if you're using the RHEL/CentOS Xen kernel.  I'm not using a RHEL kernel... instead I'm using linux-2.6.18-xen.hg, but still the issue persists on RHEL5 domU's.
> 
> OK, in that case it would be worth looking at backporting the changes to older Xens.


I'm not sure if it will make much difference.

The 2.6.18.x X server uses the PS/2 mouse driver which is strictly relative, in fact that driver basically maps on to the kernel's mousedev driver which carefully converts the absolute pointer events from the xen driver to relative ones and most of the problems with tracking arise from a built-in assumption that the absolute coordinates are on a 1024x768 screen (this is why the local mouse and the guest mouse appear to be connected by a pantograph, albeit a poorly functioning pantograph).

One solution is to use xorg-x11-drv-evdev which _does_ take the absolute pointer events and passes them directly to the X server.   Unfortunately while this is possible it is difficult to configure because the 2.6.18.x kernel has a combined xen mouse and keyboard device and the X server wants to distinct devices (if linux-2.6.18-xen.hg has separated the drivers (and you can see distinct keyboard and mouse devices in /proc/bus/input/devices) then just configure a evdev driver as a pointer for X.

For RHEL/CentOS 5 I appear to have a solution: an X input driver that takes only the mouse events from the kernel's evdev driver.   I have something that works and that I believe I can publish but I need to check both of those when I get back to work (I'm not quite on the beach at the moment, but not far off it).  Of course, for 5.5 you need to re-enable request-abs-pointer on the kernel command line, but that's not too onerous.

jch

Re: pvfb: Absolute vs relative mouse tracking mystery

[Joshua West]

  On 08/03/2010 12:23 PM, John Haxby wrote:
> On 2 Aug 2010, at 20:40, Jeremy Fitzhardinge wrote:
>
>> On 08/02/2010 12:37 PM, Joshua West wrote:
>>> On 08/02/10 15:00, Jeremy Fitzhardinge wrote:
>>>> On 08/01/2010 12:11 PM, Joshua West wrote:
>>>>> Jeremy,
>>>>>
>>>>> Do you know if this will be fixed in the Xen 3.4.x series as well?  In the 3.4.x ioemu-remote qemu code and the 2.6.18.8 xen kernel?
>>>>>
>>>>> I ask because this is an issue for me on RHEL5 domU's which are paravirtualized.  Using Xen 3.4.3 w/ Xen kernel 2.6.18.8 and I'm not yet ready to switch production clusters to 4.0.x.
>>>> RHEL/CentOS5 deliberately avoids using the absolute pointer mode for reasons I don't understand, so it is broken as expected.
>>>>
>>>>     J
>>> Ahh yes, but thats if you're using the RHEL/CentOS Xen kernel.  I'm not using a RHEL kernel... instead I'm using linux-2.6.18-xen.hg, but still the issue persists on RHEL5 domU's.
>> OK, in that case it would be worth looking at backporting the changes to older Xens.
>
> I'm not sure if it will make much difference.
>
> The 2.6.18.x X server uses the PS/2 mouse driver which is strictly relative, in fact that driver basically maps on to the kernel's mousedev driver which carefully converts the absolute pointer events from the xen driver to relative ones and most of the problems with tracking arise from a built-in assumption that the absolute coordinates are on a 1024x768 screen (this is why the local mouse and the guest mouse appear to be connected by a pantograph, albeit a poorly functioning pantograph).
>
> One solution is to use xorg-x11-drv-evdev which _does_ take the absolute pointer events and passes them directly to the X server.   Unfortunately while this is possible it is difficult to configure because the 2.6.18.x kernel has a combined xen mouse and keyboard device and the X server wants to distinct devices (if linux-2.6.18-xen.hg has separated the drivers (and you can see distinct keyboard and mouse devices in /proc/bus/input/devices) then just configure a evdev driver as a pointer for X.
>
> For RHEL/CentOS 5 I appear to have a solution: an X input driver that takes only the mouse events from the kernel's evdev driver.   I have something that works and that I believe I can publish but I need to check both of those when I get back to work (I'm not quite on the beach at the moment, but not far off it).  Of course, for 5.5 you need to re-enable request-abs-pointer on the kernel command line, but that's not too onerous.
>
> jch
Ahh... So then if we get the PVFB going with 1024x768 resolution, 
instead of wonderful 1990's 800x600, we're all set ;-)

I've been testing with evdev driver as well (Option "Device" 
"/dev/input/event1" for me), but that has not worked.  I see what you're 
saying though - I can see two entries in /proc/bus/input/devices, and my 
mouse handlers are "mouse0 event1 ts0", but both the keyboard and mouse 
physical device is the same: "xen/device/vkbd/0".  And this is all with 
linux-2.6.18-xen.hg.

I'm looking forward to your custom RHEL/CentOS driver to get this going.

One last question -- even if using linux-2.6.18-xen.hg, are you saying 
we still need request-abs-pointer kernel argument?  Wasn't that just to 
enable absolute pointer mode in the RHEL mouse driver if using RHEL 5.5 
and their Xen kernel (looked that way from their patch)?  Or is RHEL's 
Xorg somehow also looking for this directive?

Thanks.

-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby]

  On 04/08/10 01:35, Joshua West wrote:
> Ahh... So then if we get the PVFB going with 1024x768 resolution, 
> instead of wonderful 1990's 800x600, we're all set ;-)
>

Did you ever have one of those plastic pantographs when you were a kid?  
I remember having a couple and they were rubbish, the enlarged (or 
reduced) drawing looked nothing like the original.   The mapping from 
absolute to relative in mousedev has the same sort of problem, although 
if I'm feeling really generous it might just be rounding errors (though 
I doubt it).

> I've been testing with evdev driver as well (Option "Device" 
> "/dev/input/event1" for me), but that has not worked.  I see what 
> you're saying though - I can see two entries in 
> /proc/bus/input/devices, and my mouse handlers are "mouse0 event1 
> ts0", but both the keyboard and mouse physical device is the same: 
> "xen/device/vkbd/0".  And this is all with linux-2.6.18-xen.hg.

Hmm.  It should work.  I don't have a linux-2.6.18-xen.hg handy, but if 
you send me your xorg.conf and /proc/bus/input/devices (off list) I'll 
take a look.

>
> I'm looking forward to your custom RHEL/CentOS driver to get this going.

Sorting it out now.

>
> One last question -- even if using linux-2.6.18-xen.hg, are you saying 
> we still need request-abs-pointer kernel argument?  Wasn't that just 
> to enable absolute pointer mode in the RHEL mouse driver if using RHEL 
> 5.5 and their Xen kernel (looked that way from their patch)?  Or is 
> RHEL's Xorg somehow also looking for this directive?

It's just in the Red Hat/CentOS 5.5 kernels, you don't need it for any 
of the others.  And it's just to get the xenkbd front end to set 
request-abs-pointer in xenstore.  For my money, it would be better to 
have absolute pointers by default and have guests ask for relative ones 
if they really really want them.  I think this was propose a little 
while ago, but I don't recall what happened.

jch