Bug 523914

Created attachment 361445 [details]
X.log

Created attachment 361447 [details]
output of lshal

This bug is a must-fix for F12  GA, we absolutely cannot release Fedora when the mouse doesn't work right from the start of the installer.

This turns out to be a very complex situation :-(  It only worked previously because 2 bugs cancelled each other out - 2 wrongs do make a right !


 * The Xen paravirt pointer host<->guest protocol defaults to relative motion events
 * The Xen host OS backend driver advertises that it is able to optionally supply absolute motion events
 * The Xen guest OS frontend driver enables the wire protocol feature for absolute motion events if it sees it advertised by the backend.
 * The Xen guest OS frontend driver always registers a kernel input device with EV_ABS and EV_REL bits set - ie indicates it can emit absolute and relative events over the same device

 * The Xen host OS backend device model receives input from the client user (often VNC). If it sees absolute mode enabled for the wire protocol it will always send absolute motion events, otherwise it converts to relative events.


So in essence, you have a frontend input device supporting ABS & REL events, but if wire protocol has enabled ABS events, it will typically only ever emit ABS events in the guest.


Enter evdev. When auto-configuring an input device it applies the following logic:

    if (pEvdev->flags & (EVDEV_TOUCHPAD | EVDEV_TOUCHSCREEN))
        EvdevInitTouchDevice(device, pEvdev);
    else if (pEvdev->flags & EVDEV_RELATIVE_EVENTS)
        EvdevInitRelClass(device, pEvdev);
    else if (pEvdev->flags & EVDEV_ABSOLUTE_EVENTS)
        EvdevInitAbsClass(device, pEvdev);

Since the Xen Virtual Pointer is advertised as a MOUSE, the first 'if' won't match. Since Xen VP advertises ABS and REL events, the first 'else if' will match, so evdev   configures the relative axis.


In versions of evdev <= 2.2.2,  even though it configured the relative axis, evdev would still quite happily process & dispatch any absolute motion events it received.

In evdev 2.2.3, this BZ  was fixed

http://bugs.freedesktop.org/show_bug.cgi?id=21832

with this commit:

http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?h=evdev-2.2-branch&id=4dda242d56a7830d5b44d7e58cf6a95f62a617ce


It now explicitly discards all ABS events if it configured the REL axis, and vica-verca.

Since Xen advertises REL + ABS axis, but normally only emits ABS events, with evdev configuring the REL axis you now get no pointer movement in X.


IMHO, evdev should be processing both REL + ABS events it receives on any device that advertises both REL + ABS axis.

The evdev.c  source code has a comment


    /* We don't allow relative and absolute axes on the same device. The
     * reason is that some devices (MS Optical Desktop 2000) register both
     * rel and abs axes for x/y.
     *
     * The abs axes register min/max; this min/max then also applies to the
     * relative device (the mouse) and caps it at 0..255 for both axes.
     * So, unless you have a small screen, you won't be enjoying it much;
     * consequently, absolute axes are generally ignored.


IMHO it would be better to blacklist the known broken devices, rather than having to add in hacks to force tablets to use ABS axis, and then arbitrarily dropping ABS events from all other devices.

I guess comment 4 provides exhaustive analysis of the issue (in more than one meaning of the word ;)), so just passing to Peter.

(In reply to comment #4)
> IMHO it would be better to blacklist the known broken devices, rather than
> having to add in hacks to force tablets to use ABS axis, and then arbitrarily
> dropping ABS events from all other devices.

The "known broken device" is virtually every wireless keyboard+mouse combo. Blacklisting those isn't really an option. This whole issue is there because of an inherent server limitation - the server can't have both rel and abs axes.

Anyway, I've added a configuration option to evdev.  A scratch build is available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1718641

If you're setting up the devices through HAL, please add the following snippet to /etc/hal/fdi/policy/xen.fdi (or some other name of your liking):

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.product" contains="Xen Virtual Pointer">
          <merge key="input.x11_options.IgnoreRelativeAxes" type="string">true</merge>
      </match>
  </device>
</deviceinfo>

Let me know if that fixes the problem.

Yes, after installing new evdev and configuring hal, mouse works as expected.

BTW what will happend if for some reason Xen Virtual Pointer doesn't provide absolute axes? Will this configuration kill all mouse events?

"For some reason" = the Xen PVFB backend can't do absolute mouse events (really ancient versions, FC6?), or the frontend is configured not to do them (kernel parameter xenkbd.abs_pointer=0).

So, simply ignoring relative axes for this device is rather problematic.

I can't think of a better solution.

The server requires that absolute axes are set up with an axis range. Any value above or below that range is clipped. Switching a single axes once it is set up isn't possible due to protocol restrictions.

So now we have a number of devices that advertise a relative x+y from the mouse and at the same time absolute x+y from something. The axis ranges for the abs are quite small, somewhere in the 0-255 area. For those devices, and there's a few of them around, any mouse motion would be capped at 255.

External configuration to the driver is the only solution I can think of right now but I'm open for suggestions.

I think external configuration for Xen Virtual Pointer might be ok. But either the configuration has to be made conditional to allow ignoring relative axes only if absolute axes are advertised or evdev has to be made smart enough to refuse ignoring the only available option.

If I'm not mistaken, xen virtual pointer won't advertise absolute axes if it doesn't support them. I'm not 100% sure of it but I'd consider it buggy if it did so.

The PVFB frontend always advertizes relative and absolute axes.  It then uses whatever the backend uses.  Nothing in the kernel source suggests that's wrong.

In fact, there are other devices that seem to advertize both axes, e.g. drivers/hid/hid-wacom.c and drivers/input/tablet/aiptek.c.  How does evdev handle those?  Comment#1 makes me suspect it special-cases them.

Note that PVFB *does* set a useful range on absolute axes.

What about discarding the absolute axes when the ranges are both suspiciously low (less than 0..255), and relative axes are also offered?  Hmm, that would still break PVFB mouse if the screen really is that small.  Maybe we can lie about the ranges in that case.

It might be feasible to make the PVFB frontend advertize only the range that the backend promised to use.  Involves delaying device registration until feature negotiation is complete.  If my reading of the kernel interface is correct (advertizing both axes is just fine), then the change would be a workaround for newly broken userspace, and thus could be a hard sell.

(In reply to comment #11)
> In fact, there are other devices that seem to advertize both axes, e.g.
> drivers/hid/hid-wacom.c and drivers/input/tablet/aiptek.c.  How does evdev
> handle those?  Comment#1 makes me suspect it special-cases them.

It doesn't. These devices aren't yet well supported with evdev because of the special treatment they need. We still have xorg-x11-drv-aiptek and linuxwacom as specialised X drivers for those devices. This isn't limited to the rel/abs issue, at least with wacom there's some button mapping that needs to be handled inside the driver to map TOOL_TOUCH to button 1, etc.

> It might be feasible to make the PVFB frontend advertize only the range that
> the backend promised to use.  Involves delaying device registration until
> feature negotiation is complete.  If my reading of the kernel interface is
> correct (advertizing both axes is just fine), then the change would be a
> workaround for newly broken userspace, and thus could be a hard sell.  

From the kernel's POV advertising both axes is fine - the kernel can label the axes accordingly. The problem is in the X server and while we have parts of the infrastructure to deal with that, we don't have the driver hooks and the API yet. The server doesn't provide an option to differ between ABS_X and REL_X, an axis can only be "X". An once an axis is set up as abs or rel, it can't be changed. That's why we can't do fancy guesswork based on the axis we receive either. The whole issue isn't something that can easily be fixed, it'll take at least until the next server release to get all that in place.

Even worse, the "newly broken" is unfortunately a "newly fixed", depending on which way you look at it, the previous behaviour was buggy.

*** Bug 518391 has been marked as a duplicate of this bug. ***

Another scratch build that gets us a bit closer but still not there:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1732254

Instead of the options above this one provides a IgnoreAxes options with multiple values. The one suitable for the problem here would be "IgnoreAxes" "RelIfAbs" which causes the driver to ignore relative axes but only if the absolute axes are present. On devices that don't have absolute axes this option would be a no-op.
Other values are "Rel", "Abs", "Both", "None", and "AbsIfRel".

The fdo key would now be:
<merge key="input.x11_options.IgnoreAxes" type="string">RelIfAbs</merge>

This can only fix the problem as long as the Xen Virtual Pointer only advertises absolute axes when it's actually providing them. I really don't know what else to do.

We might be able to work around our "X not there yet" problems by dropping support for relative axes in Xen PV pointer.  See
http://lists.xensource.com/archives/html/xen-devel/2009-10/msg00299.html

Turns out the situation is even more screwed up than I thought. Besides the "normal" Xen PVFB back end, which always provides absolute, we have XCI.  XCI passes through the physical graphics device, and routes events from the physical pointer device (commonly relative) unchanged through the Xen PV keyboard/pointer protocol.

The XCI back end offers absolute pointer to the front end, even though it may pass on relative pointer events from its physical pointer.  Of course, this is a bug.  But the current front end doesn't care, and evdev used not to care either.

What are our options?

* Don't cope with relative back ends like XCI.  Ignore relative motion in evdev by configuring IgnoreRelativeAxes for Xen PV pointer.

* Punt to the user: let him confure what to ignore in evdev.  Correct choice depends on the back end.  Switch from one kind of back end to the other, lose the mouse.  To get it back, you need to reconfigure evdev.  And restart X, I guess.

* Could evdev offer the old, buggy behavior as a per-device option? Pretty-please?  Note this is the only option that can work with an unfixed XCI.  If that matters.

* If none of the above is acceptable, i.e. we absolutely must cope with relative back ends, with absolutely no manual configuration, then I don't see a way around messing with the Xen PV pointer protocol: outlaw relative motion when absolute mode was agreed upon, and vice versa. Restructure the back end delay pointer device registration until we know absolute vs. relative mode.  I'd regard this a kernel work-around for a user space defect.  Users won't care, they just want a working pointer.

How about changing the behaviour of the driver that if either of these options is set to "false", the axes are explicitly "unignored"?

So for the Xen pointer you have both options set to false, thus avoiding the driver-internal magic to pick one of the two. The result would be that the axes are set up as absolute, but rel events can still be passed through - essentially forcing the buggy behaviour we had before.
Do you think this approach would work?

Note that this isn't a silver bullet either. If the abs axes are set up with - say 0-10 on a 1024 screen, each relative movement by 1 pixel would scale up to a movement by 102.4 pixels. Would this be a problem in this case?

So you found a way to optionally provide the old, buggy behavior? Sounds great to me!

The absolute pointer resolution is supposed to track the framebuffer resolution.  Is that okay?  Hmm, tracking looks broken.  If it is, then absolute pointer resolution is stuck at 800x600.  I'll find out.

(In reply to comment #18)
> The absolute pointer resolution is supposed to track the framebuffer
> resolution.  Is that okay?

yes. issues with scaling only arise if the abs axes range is significantly larger or smaller than the screen res. If they're the same (or at least roughly the same) you shouldn't notice a difference. I still have to figure out whether that plays havoc with pointer acceleration though (right now, I don't think it does).

http://koji.fedoraproject.org/koji/taskinfo?taskID=1746744

scratch build for the above approach. Simply set IgnoreRelativeAxes and IgnoreAbsoluteAxes both to false and the device inits and accepts both relative and absolute axes. This essentially restores the old behaviour. please let me know that works for you.

Assuming this works okay, do we have to do anything to make sure that evdev is configured in this way by default for xen pv input?

> scratch build for the above approach. Simply set IgnoreRelativeAxes and
> IgnoreAbsoluteAxes both to false and the device inits and accepts both relative
> and absolute axes. This essentially restores the old behaviour. please let me
> know that works for you.  

Yes, that works fine for xen pn input with absolute axes.

These two builds are necessary.
Updated HAL for the default configuration:
http://koji.fedoraproject.org/koji/buildinfo?buildID=137205
Updated evdev for the above options:
http://koji.fedoraproject.org/koji/buildinfo?buildID=137198

Once they're installed, the pointer should just work again. Please give this a quick test (make sure you remove the fdi file created for testing first and restart HAL). If it works fine, I'll get them tagged for F12 final.

Great. After removing the testing fdi file for xen pointer, mouse stops working. Then after installing these new evdev and hal packages, the mouse starts working again. Thanks.

The new hal and xorg-x11-drv-evdev packages work for me (reporter of bug 518391) too.

Thanks peter

tag request was https://fedorahosted.org/rel-eng/ticket/2558

Fixed by hal-0.5.13-9.fc12 and xorg-x11-drv-evdev-2.3.0-1.fc12

Since this bug was opened again rawhide, I'm reopening it. The exact same symptoms are back with F13 Xen PV guests: 

pointer stuck, but clicking/scrolling work, and X log contains

(II) Xen Virtual Pointer: initialized for relative axes.

(WW) Xen Virtual Pointer: ignoring absolute axes.

updating to block F13VirtBlocker. Discussed at the blocker review meeting today: we agree this is a blocker as it infringes Beta criterion "The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation".

https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria

Peter, can you take a look at this please? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This should be fixed with xorg-x11-server-1.8.0-2.fc13 and later. Sorry, I must have forgotten to put the reference to this bug into koji.

The quirk is now in 10-quirks.conf as provided by the server package.

Thanks, Peter. Andrew, can you test with a recent F13 (including at least that version of xorg-x11-server) and confirm or deny the fix? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

ping - Andrew? we're very tight on time for the F13 schedule at this point, it'd really help to have confirmation ASAP. Thanks!

(or if anyone else reading this bug is able to test, please do; I'm not set up for it at present).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Mouse pointer moves just fine for me when installing F-13
from May 02 images as a PV guest under RHEL-5.5.
X.log shows it is using "Xen Virtual Pointer".

I just retested with latest f13 compose. Mouse works fine when running as a Xen guest now. Sorry for the delay.

since a later xorg-x11-server than -2.fc13 has been tagged already, let's close this. Thanks for testing.