Bug 248752

I can confirm this, the same happens on my fully updated F7 system with an USB
Graphire 4 tablet attached to the computer. GDM mouse movement is next to
impossible, however attaching another standard mouse to it, it works just fine?
I'm on x86_64 and I'm not sure what might be the problem here.

When you log in does it also misbehave?

Note, at startup the gdm greeter will warp the pointer to the center of the screen.

It could be this warping that is confusing the input driver.

Can you attach your xorg.conf ?  Do you have a "SendCoreEvents" string next to
the device name in the top of the file?  If you remove that, does it work around
the problem?  (Note you won't be able to use the tablet as a normal mouse then,
you'll only be able to use it in apps that specifically support it like gimp or
inkscape)

Created attachment 159807 [details]
xorg.conf

(In reply to comment #2)
> When you log in does it also misbehave?
> 

No once logged in everything works fine.

> Can you attach your xorg.conf ?  Do you have a "SendCoreEvents" string next
to
> the device name in the top of the file?  If you remove that, does it work
around
> the problem?	(Note you won't be able to use the tablet as a normal mouse
then,
> you'll only be able to use it in apps that specifically support it like gimp
or
> inkscape)

Attached, I can remove the SendCoreEvents, but I can guarantee that things then
won't work as there is no mouse attached. When I write "mouse" above, I mean a
wacom "mouse", a piece of plastic shaped like a mouse to which the tablet
responds by sending relative events when it is moved while on the tablet.

The wacom tablet has 3 pointers, the pen (absolute), the eraser (drawing with
the backside of the pen) (absolute) and the "mouse" (relative)

So normally, having "/dev/input/mice" and additional mouse devices is bad news.
 It means you'll get double events (one from the aggregate mouse device and one
from the additional mouse device).

In your case, I'm guessing it wouldn't though, since the tablet is hooked up via
the serial port.  Does the tablet move the mouse pointer if you just have Mouse0
?  If not, then the above problem isn't something you have to worry about.

If you want to see if its the mouse cursor centering code that's triggering your
problem, you could try recompiling gdm with the gdm_wm_center_cursor function in
gui/gdmwm.c made into a no-op.

Also, do you ever have the mouse stylus and pen stylus on the pad at the same time?

(In reply to comment #4)
> So normally, having "/dev/input/mice" and additional mouse devices is bad news.
>  It means you'll get double events (one from the aggregate mouse device and one
> from the additional mouse device).
> 
> In your case, I'm guessing it wouldn't though, since the tablet is hooked up via
> the serial port.  Does the tablet move the mouse pointer if you just have Mouse0
> ?  If not, then the above problem isn't something you have to worry about.
> 

The tablet doesn't move the mouse when the special tablet entries are removed
from xorg.conf.

> If you want to see if its the mouse cursor centering code that's triggering your
> problem, you could try recompiling gdm with the gdm_wm_center_cursor function in
> gui/gdmwm.c made into a no-op.
> 

Does this function get called only once, or could it get called continuously? 

The problem seems to be continuous, if I move the mouse / stylus on the tablet
the pointer moves, in case of the stylus it even jumps to the location where I
move the stylus (absolute coordinates) and then it immediately jumps back to the
lower right corner, so it seems it gets warped to these coordinates continuously.

If you still think this function is the culprit I would be happy to give things
a go with the function made into a no-op.

> Also, do you ever have the mouse stylus and pen stylus on the pad at the same
time?
> 

No.

I'm guessing it may be a driver bug where that call causes the driver to confuse
its own internal state.

I don't really know though, it's just a guess.

(In reply to comment #6)
> I'm guessing it may be a driver bug where that call causes the driver to confuse
> its own internal state.
> 
> I don't really know though, it's just a guess.

Why would it start to work fine again then after the greeter is gone? It really
feels look likes it is getting warped continuously. Well I guess I will just
have to dive into the code when I find some time for it (IOW not now).

FWIW, I really doubt its a greeter bug.  Out of curiosity, do you see the
problem with the plain greeter as well?

Hans, Gian, can you attach the X.org configuration and logs after the problem is
triggered?

Thanks

Not responding to the inquiries made in comment #8 and comment #9, as I just had
this exchange which upstream, which I think explains (but does not fix) this:

---

Comment #1 from Brian Cameron    (gdm developer, points: 21)
2007-07-30 17:00 UTC [reply]

This does sound strange.  Do you also see this problem after you log into your
session, or does the problem only happen with GDM?

Does it work better if you enable accessibility in GDM?  I believe the
dwellmouselistener plugin causes XInput devices to be treated like the main
cursor.


Comment #2 from Hans de Goede (reporter, points: 6)
2007-08-03 07:03 UTC [reply]

Actually, Fedora has accessibility enabled by default, disabling this fixes
this. Which makes sense as the tablet is configured to send core events as it
is the only pointing device on the PC. So the dwellmouselistener plugin seems
to be causing problems here, I guess it should check if an xinput device sends
core events before enabling itself for this device.

---

Let me know if you still want Xorg logs, or me to try with the plain greeter.

ah okay

so inside the dwellmouselistener plugin there is:

                if (latch_core_pointer)
                    XWarpPointer (motion->display, None,
                              motion->root,
                              0, 0, 0, 0, motion->axis_data[0],
motion->axis_data[1]);

if it's stuck in the lower right hand corner of the screen then that means the x
and y values in axis_data are stuck at big values.

Out of curiosity, if you set the Mode to absolute instead of relative do you
still see the problem?

(In reply to comment #13)
> Out of curiosity, if you set the Mode to absolute instead of relative do you
> still see the problem?

It doesn't work both when using the tablets mouse-thingy (relative) and when
using the pen (absolute).

So it looks like gtk+ (in the implementation of its input apis) does something like:

device_width = device_maximum_x - device_minimum_x;
x = (screen_width / device_width) * (axis_data[0] - device_minimum_x);

and similar for y

so it looks like devices can have a different scale than XWarpPointer expects.

It looks like this module is only used to start ATs.  Since we already provide
other methods to start ATs, and the module seems to have a lot of issues (see my
comments in the upstream bug report).  I think we should just remove the module
from the default configuration.

I can't imagine it's ever worked on anything but maybe touch / cintiq screens.

okay, I've removed the gesture listening plugin from the default configuration in

gdm-2.19.5-3.fc8

Gian,

would you mind trying the latest rawhide packages but enabling the
dwellmouselistener plugin?

I think it should work somewhat better now.

gdm-2.18.4-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

gdm-2.18.4-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.