Xen devel - Feb 2011 - More issues with xl on 4.1.0-rc

I have spotted another couple of bugs when testing with xl on 4.1.0-rc and 
a xen/next-2.6.38 based kernel.

If I use pygrub as a boot loader and run xl create -c host then 
the console disconnects once pygrub is finished. I can reconnect to the 
console session but it is a bit annoying to have to do so.

If I set vfb = [ ''sdl'' ] in the configuration file, then I can
type in the
window produced, but the mouse doesn''t work (the pointer stays fixed in
the middle of the window). Alao clicking on the window doesn''t trigger
the
"grab keyboard and mouse" mode, though I can manually trigger it and
leave
it using the ctrl-alt key combination.

 	Michael Young

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

On Thu, 3 Feb 2011, M A Young wrote:
> I have spotted another couple of bugs when testing with xl on 4.1.0-rc and 
> a xen/next-2.6.38 based kernel.
> 
> If I use pygrub as a boot loader and run xl create -c host then 
> the console disconnects once pygrub is finished. I can reconnect to the 
> console session but it is a bit annoying to have to do so.
> 
> If I set vfb = [ ''sdl'' ] in the configuration file, then
I can type in the
> window produced, but the mouse doesn''t work (the pointer stays
fixed in
> the middle of the window). Alao clicking on the window doesn''t
trigger the
> "grab keyboard and mouse" mode, though I can manually trigger it
and leave
> it using the ctrl-alt key combination.
> 
Thank you very much for reporting these bugs.
I have just fixed the first one, but I cannot reproduce the second one
(however I am using X remoting because I don''t have an X server on my
testbox).

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

On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> On Thu, 3 Feb 2011, M A Young wrote:
>> I have spotted another couple of bugs when testing with xl on 4.1.0-rc
and
>> a xen/next-2.6.38 based kernel.
>>
>> If I use pygrub as a boot loader and run xl create -c host then
>> the console disconnects once pygrub is finished. I can reconnect to the
>> console session but it is a bit annoying to have to do so.
>>
>> If I set vfb = [ ''sdl'' ] in the configuration file,
then I can type in the
>> window produced, but the mouse doesn''t work (the pointer stays
fixed in
>> the middle of the window). Alao clicking on the window doesn''t
trigger the
>> "grab keyboard and mouse" mode, though I can manually trigger
it and leave
>> it using the ctrl-alt key combination.
>>
>
> Thank you very much for reporting these bugs.
> I have just fixed the first one, but I cannot reproduce the second one
> (however I am using X remoting because I don''t have an X server on
my
> testbox).
Thanks for the first fix. The mouse problem is reproducible over remote X 
(ssh -X) and if I use vnc rather than sdl. Do you have any idea how we 
might debug this?

 	Michael Young

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

On Fri, 4 Feb 2011, M A Young wrote:
> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> 
> > On Thu, 3 Feb 2011, M A Young wrote:
> >> I have spotted another couple of bugs when testing with xl on
4.1.0-rc and
> >> a xen/next-2.6.38 based kernel.
> >>
> >> If I use pygrub as a boot loader and run xl create -c host then
> >> the console disconnects once pygrub is finished. I can reconnect
to the
> >> console session but it is a bit annoying to have to do so.
> >>
> >> If I set vfb = [ ''sdl'' ] in the configuration
file, then I can type in the
> >> window produced, but the mouse doesn''t work (the pointer
stays fixed in
> >> the middle of the window). Alao clicking on the window
doesn''t trigger the
> >> "grab keyboard and mouse" mode, though I can manually
trigger it and leave
> >> it using the ctrl-alt key combination.
> >>
> >
> > Thank you very much for reporting these bugs.
> > I have just fixed the first one, but I cannot reproduce the second one
> > (however I am using X remoting because I don''t have an X
server on my
> > testbox).
> 
> Thanks for the first fix. The mouse problem is reproducible over remote X 
> (ssh -X) and if I use vnc rather than sdl. Do you have any idea how we 
> might debug this?
Does the mouse work if you just have the console and gpm in the guest?
What is the output of "xenstore-ls /local/domain/$DOMID/device/vkbd"?


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

On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> On Fri, 4 Feb 2011, M A Young wrote:
>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
>>
>>> On Thu, 3 Feb 2011, M A Young wrote:
>>>> I have spotted another couple of bugs when testing with xl on
4.1.0-rc and
>>>> a xen/next-2.6.38 based kernel.
>>>>
>>>> If I set vfb = [ ''sdl'' ] in the configuration
file, then I can type in the
>>>> window produced, but the mouse doesn''t work (the
pointer stays fixed in
>>>> the middle of the window). Alao clicking on the window
doesn''t trigger the
>>>> "grab keyboard and mouse" mode, though I can manually
trigger it and leave
>>>> it using the ctrl-alt key combination.
>>>
>>> ... I cannot reproduce the second one
>>> (however I am using X remoting because I don''t have an X
server on my
>>> testbox).
>>
>> Thanks for the first fix. The mouse problem is reproducible over remote
X
>> (ssh -X) and if I use vnc rather than sdl. Do you have any idea how we
>> might debug this?
>
> Does the mouse work if you just have the console and gpm in the guest?
> What is the output of "xenstore-ls
/local/domain/$DOMID/device/vkbd"?
The mouse mostly works with a console and gpm - I get a reverse video 
cursor which will move, cut and paste, though it isn''t quite in step
with
where the pointer would be, eg. if I enter the window from the bottom the 
cursor appears more to the right than it should be.

 	Michael Young

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

On Fri, 4 Feb 2011, M A Young wrote:
> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
>
>> On Fri, 4 Feb 2011, M A Young wrote:
>>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
>>> 
>>>> On Thu, 3 Feb 2011, M A Young wrote:
>>>>> I have spotted another couple of bugs when testing with xl
on 4.1.0-rc
>>>>> and
>>>>> a xen/next-2.6.38 based kernel.
>>>>> 
>>>>> If I set vfb = [ ''sdl'' ] in the
configuration file, then I can type in
>>>>> the
>>>>> window produced, but the mouse doesn''t work (the
pointer stays fixed in
>>>>> the middle of the window). Alao clicking on the window
doesn''t trigger
>>>>> the
>>>>> "grab keyboard and mouse" mode, though I can
manually trigger it and
>>>>> leave
>>>>> it using the ctrl-alt key combination.
>>>> 
>>>> ... I cannot reproduce the second one
>>>> (however I am using X remoting because I don''t have an
X server on my
>>>> testbox).
>>> 
>>> Thanks for the first fix. The mouse problem is reproducible over
remote X
>>> (ssh -X) and if I use vnc rather than sdl. Do you have any idea how
we
>>> might debug this?
>> 
>> Does the mouse work if you just have the console and gpm in the guest?
>> What is the output of "xenstore-ls
/local/domain/$DOMID/device/vkbd"?
>
> The mouse mostly works with a console and gpm - I get a reverse video
cursor
> which will move, cut and paste, though it isn''t quite in step with
where the
> pointer would be, eg. if I enter the window from the bottom the cursor 
> appears more to the right than it should be.
Sorry, I forgot to add the output from
xenstore-ls /local/domain/6/device/vkbd/0
which is
backend = "/local/domain/0/backend/vkbd/6/0"
backend-id = "0"
state = "4"
page-ref = "284456"
event-channel = "14"
request-abs-pointer = "1"

 	Michael Young

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

On Fri, 4 Feb 2011, M A Young wrote:
> On Fri, 4 Feb 2011, M A Young wrote:
> 
> > On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> >
> >> On Fri, 4 Feb 2011, M A Young wrote:
> >>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> >>> 
> >>>> On Thu, 3 Feb 2011, M A Young wrote:
> >>>>> I have spotted another couple of bugs when testing
with xl on 4.1.0-rc
> >>>>> and
> >>>>> a xen/next-2.6.38 based kernel.
> >>>>> 
> >>>>> If I set vfb = [ ''sdl'' ] in the
configuration file, then I can type in
> >>>>> the
> >>>>> window produced, but the mouse doesn''t work
(the pointer stays fixed in
> >>>>> the middle of the window). Alao clicking on the window
doesn''t trigger
> >>>>> the
> >>>>> "grab keyboard and mouse" mode, though I can
manually trigger it and
> >>>>> leave
> >>>>> it using the ctrl-alt key combination.
> >>>> 
> >>>> ... I cannot reproduce the second one
> >>>> (however I am using X remoting because I don''t
have an X server on my
> >>>> testbox).
> >>> 
> >>> Thanks for the first fix. The mouse problem is reproducible
over remote X
> >>> (ssh -X) and if I use vnc rather than sdl. Do you have any
idea how we
> >>> might debug this?
> >> 
> >> Does the mouse work if you just have the console and gpm in the
guest?
> >> What is the output of "xenstore-ls
/local/domain/$DOMID/device/vkbd"?
> >
> > The mouse mostly works with a console and gpm - I get a reverse video
cursor
> > which will move, cut and paste, though it isn''t quite in step
with where the
> > pointer would be, eg. if I enter the window from the bottom the cursor
> > appears more to the right than it should be.
> 
If you are getting mouse events in the guest''s kernel, I think the
basic
mechanism must be working correctly.
Could it be a problem with your xserver?

Otherwise you need to add some printf in qemu in
hw/xenfb.c:xenfb_mouse_event.



> Sorry, I forgot to add the output from
> xenstore-ls /local/domain/6/device/vkbd/0
> which is
> backend = "/local/domain/0/backend/vkbd/6/0"
> backend-id = "0"
> state = "4"
> page-ref = "284456"
> event-channel = "14"
> request-abs-pointer = "1"
looks all right

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

On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> On Fri, 4 Feb 2011, M A Young wrote:
>> On Fri, 4 Feb 2011, M A Young wrote:
>>
>>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
>>>
>>>> On Fri, 4 Feb 2011, M A Young wrote:
>>>>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
>>>>>
>>>>>> On Thu, 3 Feb 2011, M A Young wrote:
>>>>>>> I have spotted another couple of bugs when testing
with xl on 4.1.0-rc
>>>>>>> and
>>>>>>> a xen/next-2.6.38 based kernel.
>>>>>>>
>>>>>>> If I set vfb = [ ''sdl'' ] in the
configuration file, then I can type in
>>>>>>> the
>>>>>>> window produced, but the mouse doesn''t
work (the pointer stays fixed in
>>>>>>> the middle of the window). Alao clicking on the
window doesn''t trigger
>>>>>>> the
>>>>>>> "grab keyboard and mouse" mode, though I
can manually trigger it and
>>>>>>> leave
>>>>>>> it using the ctrl-alt key combination.
>>>>>>
>>>>>> ... I cannot reproduce the second one
>>>>>> (however I am using X remoting because I don''t
have an X server on my
>>>>>> testbox).
>>>>>
>>>>> Thanks for the first fix. The mouse problem is reproducible
over remote X
>>>>> (ssh -X) and if I use vnc rather than sdl. Do you have any
idea how we
>>>>> might debug this?
>>>>
>>>> Does the mouse work if you just have the console and gpm in the
guest?
>>>> What is the output of "xenstore-ls
/local/domain/$DOMID/device/vkbd"?
>>>
>>> The mouse mostly works with a console and gpm - I get a reverse
video cursor
>>> which will move, cut and paste, though it isn''t quite in
step with where the
>>> pointer would be, eg. if I enter the window from the bottom the
cursor
>>> appears more to the right than it should be.
>>
>
> If you are getting mouse events in the guest''s kernel, I think the
basic
> mechanism must be working correctly.
> Could it be a problem with your xserver?
>
> Otherwise you need to add some printf in qemu in
> hw/xenfb.c:xenfb_mouse_event.
I am still having problems with this. My debugging output of 
xenfb_mouse_event looked the same as a different computer that didn''t
have
the proble. Do you have any further debugging suggestions?

 	Michael Young

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

On Sun, 6 Mar 2011, M A Young wrote:
> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> 
> > On Fri, 4 Feb 2011, M A Young wrote:
> >> On Fri, 4 Feb 2011, M A Young wrote:
> >>
> >>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> >>>
> >>>> On Fri, 4 Feb 2011, M A Young wrote:
> >>>>> On Fri, 4 Feb 2011, Stefano Stabellini wrote:
> >>>>>
> >>>>>> On Thu, 3 Feb 2011, M A Young wrote:
> >>>>>>> I have spotted another couple of bugs when
testing with xl on 4.1.0-rc
> >>>>>>> and
> >>>>>>> a xen/next-2.6.38 based kernel.
> >>>>>>>
> >>>>>>> If I set vfb = [ ''sdl'' ] in
the configuration file, then I can type in
> >>>>>>> the
> >>>>>>> window produced, but the mouse
doesn''t work (the pointer stays fixed in
> >>>>>>> the middle of the window). Alao clicking on
the window doesn''t trigger
> >>>>>>> the
> >>>>>>> "grab keyboard and mouse" mode,
though I can manually trigger it and
> >>>>>>> leave
> >>>>>>> it using the ctrl-alt key combination.
> >>>>>>
> >>>>>> ... I cannot reproduce the second one
> >>>>>> (however I am using X remoting because I
don''t have an X server on my
> >>>>>> testbox).
> >>>>>
> >>>>> Thanks for the first fix. The mouse problem is
reproducible over remote X
> >>>>> (ssh -X) and if I use vnc rather than sdl. Do you have
any idea how we
> >>>>> might debug this?
> >>>>
> >>>> Does the mouse work if you just have the console and gpm
in the guest?
> >>>> What is the output of "xenstore-ls
/local/domain/$DOMID/device/vkbd"?
> >>>
> >>> The mouse mostly works with a console and gpm - I get a
reverse video cursor
> >>> which will move, cut and paste, though it isn''t quite
in step with where the
> >>> pointer would be, eg. if I enter the window from the bottom
the cursor
> >>> appears more to the right than it should be.
> >>
> >
> > If you are getting mouse events in the guest''s kernel, I
think the basic
> > mechanism must be working correctly.
> > Could it be a problem with your xserver?
> >
> > Otherwise you need to add some printf in qemu in
> > hw/xenfb.c:xenfb_mouse_event.
> 
> I am still having problems with this. My debugging output of 
> xenfb_mouse_event looked the same as a different computer that
didn''t have
> the proble. Do you have any further debugging suggestions?
 
Is there any difference in the VMs between the system that works and the
one that does not? In particular I am think about kernel or xorg
versions.

You could try to add some debug messages to
drivers/input/xen-kbdfront.c:input_handler in the guest kernel and see
if you are actually receiving the events you should be receiving.

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

On Mon, 7 Mar 2011, Stefano Stabellini wrote:
> On Sun, 6 Mar 2011, M A Young wrote:
>
> Is there any difference in the VMs between the system that works and the
> one that does not? In particular I am think about kernel or xorg
> versions.
I think this could be it. The mouse doesn''t work on newer VMs but does 
work on older ones (I am not sure my earlier test results quite fitted 
that pattern but I could be mis-remembering or have been mis-testing).

I am attaching the Xorg log files from a working guest where the mouse 
works and one where it doesn''t. In particular abssolute axis support 
doesn''t seem to have been set up in the problem guest.

 	Michael Young


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

On 08/03/11 22:03, M A Young wrote:
> On Mon, 7 Mar 2011, Stefano Stabellini wrote:
>
>> On Sun, 6 Mar 2011, M A Young wrote:
>>
>> Is there any difference in the VMs between the system that works and
the
>> one that does not? In particular I am think about kernel or xorg
>> versions.
>
> I think this could be it. The mouse doesn''t work on newer VMs but
does
> work on older ones (I am not sure my earlier test results quite fitted
> that pattern but I could be mis-remembering or have been mis-testing).

I thought this sounded familiar.  In the bad log you have

(==) Using system config directory "/usr/share/X11/xorg.conf.d"
...
(II) config/udev: Adding input device Xen Virtual Pointer
(/dev/input/event1)
(**) Xen Virtual Pointer: Applying InputClass "evdev pointer catchall"
(II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
(**) Xen Virtual Pointer: always reports core events
(**) Xen Virtual Pointer: Device: "/dev/input/event1"
(--) Xen Virtual Pointer: Found 12 mouse buttons
(--) Xen Virtual Pointer: Found scroll wheel(s)
(--) Xen Virtual Pointer: Found relative axes
(--) Xen Virtual Pointer: Found x and y relative axes
(--) Xen Virtual Pointer: Found absolute axes
(--) Xen Virtual Pointer: Found x and y absolute axes
(II) Xen Virtual Pointer: Configuring as mouse
(II) Xen Virtual Pointer: Adding scrollwheel support
(**) Xen Virtual Pointer: YAxisMapping: buttons 4 and 5
(**) Xen Virtual Pointer: EmulateWheelButton: 4, EmulateWheelInertia:
10, EmulateWheelTimeout: 200
(**) Option "config_info"
"udev:/sys/devices/virtual/input/input1/event1"
(II) XINPUT: Adding extended input device "Xen Virtual Pointer" (type:
MOUSE)
(II) Xen Virtual Pointer: initialized for relative axes.
(WW) Xen Virtual Pointer: ignoring absolute axes.
(**) Xen Virtual Pointer: (accel) keeping acceleration scheme 1
(**) Xen Virtual Pointer: (accel) acceleration profile 0
(**) Xen Virtual Pointer: (accel) acceleration factor: 2.000
(**) Xen Virtual Pointer: (accel) acceleration threshold: 4


The critical bit it "ignoring absolute axes".   If you look at the
evdev
man page it says

                                                                  The X
              server cannot deal with devices that have  both  relative
              and  absolute  axes.  Evdev  tries  to guess wich axes to
              ignore given the device type and disables  absolute  axes
              for  mice and relative axes for tablets, touchscreens and
              touchpad.

Your "good" log file indicates that something was done about this in
the
configuration, but the easiest thing to do is to put this in
/usr/share/X11/xorg.conf.d/xen.conf (that file doesn''t exist):

Section "InputClass"
    Identifier "Xen Virtual Pointer"
    MatchProduct "Xen Virtual Pointer"
    Option "IgnoreRelativeAxes" "True"
EndSection

When you start up the X server the log file will show that this option
has been taken and all will be sweetness and light.

The underlying problem seems to be that the xen virtual mouse driver is
advertising both relative and absolute axes (duh) but the back end is
only supplying absolute axes.

I haven''t had the time to look since I discovered this a week ago --
but
I think that the front end shouldn''t be advertising relative axes if
the
back end is supplying absolute ones.   Perhaps now I should actually
look ...

jch

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

On Wed, Mar 09, John Haxby wrote:
> (II) Xen Virtual Pointer: initialized for relative axes.
> (WW) Xen Virtual Pointer: ignoring absolute axes.
The bug is in the PV driver, it should send either absolute or relative,
but not advertise both to the kernel evdev driver. The current
xorg-input driver gets confused if both are advertised (it may have a
reason to do it that way for real hardware).

I have a kernel patch which I will send out later this week.

Olaf

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

On Wed, 9 Mar 2011, John Haxby wrote:
> Your "good" log file indicates that something was done about this
in the
> configuration, but the easiest thing to do is to put this in
> /usr/share/X11/xorg.conf.d/xen.conf (that file doesn''t exist):
>
> Section "InputClass"
>    Identifier "Xen Virtual Pointer"
>    MatchProduct "Xen Virtual Pointer"
>    Option "IgnoreRelativeAxes" "True"
> EndSection
In my case (on the vm I have tested so far) I needed

     Option "IgnoreAbsoluteAxes" "False"

which made it work, because the X server guesses correctly, though adding
     Option "IgnoreRelativeAxes" "True"
and/or
     Option "Mode" "Absolute"
as well stops the guesswork.

 	Michael Young

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

On Wed, 9 Mar 2011, Olaf Hering wrote:
> On Wed, Mar 09, John Haxby wrote:
> 
> > (II) Xen Virtual Pointer: initialized for relative axes.
> > (WW) Xen Virtual Pointer: ignoring absolute axes.
> 
> The bug is in the PV driver, it should send either absolute or relative,
> but not advertise both to the kernel evdev driver. The current
> xorg-input driver gets confused if both are advertised (it may have a
> reason to do it that way for real hardware).
> 
> I have a kernel patch which I will send out later this week.
Ok, I count on you :)

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

On Wed, Mar 09, Stefano Stabellini wrote:
> On Wed, 9 Mar 2011, Olaf Hering wrote:
> > On Wed, Mar 09, John Haxby wrote:
> > 
> > > (II) Xen Virtual Pointer: initialized for relative axes.
> > > (WW) Xen Virtual Pointer: ignoring absolute axes.
> > 
> > The bug is in the PV driver, it should send either absolute or
relative,
> > but not advertise both to the kernel evdev driver. The current
> > xorg-input driver gets confused if both are advertised (it may have a
> > reason to do it that way for real hardware).
> > 
> > I have a kernel patch which I will send out later this week.
> 
> Ok, I count on you :)
I just sent a patch for linux-2.6.18.hg:
fbfront: advertise either absolute or relative coordinates

The code in linux-2.6-xen.git looks identical, please try this patch.

Olaf

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

On Thu, 10 Mar 2011, Olaf Hering wrote:
> On Wed, Mar 09, Stefano Stabellini wrote:
> 
> > On Wed, 9 Mar 2011, Olaf Hering wrote:
> > > On Wed, Mar 09, John Haxby wrote:
> > > 
> > > > (II) Xen Virtual Pointer: initialized for relative axes.
> > > > (WW) Xen Virtual Pointer: ignoring absolute axes.
> > > 
> > > The bug is in the PV driver, it should send either absolute or
relative,
> > > but not advertise both to the kernel evdev driver. The current
> > > xorg-input driver gets confused if both are advertised (it may
have a
> > > reason to do it that way for real hardware).
> > > 
> > > I have a kernel patch which I will send out later this week.
> > 
> > Ok, I count on you :)
> 
> I just sent a patch for linux-2.6.18.hg:
> fbfront: advertise either absolute or relative coordinates
> 
> The code in linux-2.6-xen.git looks identical, please try this patch.
 
yes, porting it to an upstream kernel should be trivial

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