| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] pvfb: Absolute vs relative mouse tracking mystery
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home