Bug 21456

Summary: input devices react slowly in x-direction
Product: xorg Reporter: Christian Schmitt <chrschmitt>
Component: Server/Input/CoreAssignee: Peter Hutterer <peter.hutterer>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: simon.thum
Version: git   
Hardware: PowerPC   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
output of evtest
none
xorg log file
none
xorg log with debugging
none
second try of debug
none
xorg log with even more debug and crash
none
patch to use lroundf() insterad of casted roundf()
none
test code none

Description Christian Schmitt 2009-04-28 02:24:17 UTC
After an update to xorg git I encounter issues with the mouse pointer in combination with the synaptics driver as well as the evdev driver (when attaching an external mouse). Moving the pointer into y, -y or x directions works as expected, but -x is very slow, like a "speed limit" that brings the pointer to a stop when exceeding a certain movement speed.
Both, synaptics and evdev drivers are from git, but I also encountered the problem with synaptics 1.0.
A temporary fix was to disable the acceleration scheme in hal, which made the input device work again as expected. (<merge key="input.x11_options.AccelerationScheme" type="string">none</merge>)
Comment 1 Christian Schmitt 2009-04-28 02:25:24 UTC
Created attachment 25222 [details]
output of evtest

This shows that x coordinates are passed correctly
Comment 2 Christian Schmitt 2009-04-28 02:27:09 UTC
Created attachment 25223 [details]
xorg log file
Comment 3 Simon Thum 2009-04-28 04:27:22 UTC
Can you qualify the xorg server git version? Maybe it is related to this recent fix:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=06aebecb19dd9d90d73b742a09b6068b862f1d05
Comment 4 Christian Schmitt 2009-04-28 06:44:40 UTC
It is indeed related to it :)
My xorg version is only one day old. I reverted the patch and the problem is gone. 
Comment 5 Simon Thum 2009-04-28 08:25:57 UTC
hmm - this was an important bugfix.

Would it be possible for you to put the following code in acceleratePonterPredictable (just where the commit was), cause the bug to happen & post your log again?

if (dx) {
     tmp = mult * fdx + pDev->last.remainder[0];
     *px = (int)roundf(tmp);
     pDev->last.remainder[0] = tmp - (float)*px;
}
if (dy) {
    tmp = mult * fdy + pDev->last.remainder[1];
    *py = (int)roundf(tmp);
    pDev->last.remainder[1] = tmp - (float)*py;
}
ErrorF("remainders x: %.3f y: %.3f\n", pDev->last.remainder[0], pDev->last.remainder[1]);

Comment 6 Christian Schmitt 2009-04-28 12:46:56 UTC
Created attachment 25238 [details]
xorg log with debugging

Here we go. The output was generated by me voving the synaptics mouse pointer into the -x direction several times. It stopped repeatedly.
Comment 7 Simon Thum 2009-04-28 13:08:43 UTC
(In reply to comment #6)
> Here we go. The output was generated by me voving the synaptics mouse pointer
> into the -x direction several times. It stopped repeatedly.

I'm sorry, I missed to instruct you to enable PTRACCEL_DEBUGGING at the top of that file. I can't see what went wrong from your data...

Big sorry! May you repeat that with PTRACCEL_DEBUGGING? I'd really like to nail it down.
Comment 8 Christian Schmitt 2009-04-28 14:24:30 UTC
Created attachment 25240 [details]
second try of debug

Ok. Hope this time it is allrigt :)
Comment 9 Simon Thum 2009-04-29 02:45:19 UTC
> Ok. Hope this time it is allrigt :)
Thanks a lot! Yes it is, but I still don't get why it's not behaving.

If you've got the nerves to try once more, extend the debug statement like this:

ErrorF("pos (%i | %i) remainders x: %.3f y: %.3f delta x:%.3f y:%.3f\n", *px, *py, pDev->last.remainder[0], pDev->last.remainder[1], fdx, fdy);

Thanks in advance,

Simon
Comment 10 Christian Schmitt 2009-04-29 04:33:32 UTC
Created attachment 25254 [details]
xorg log with even more debug and crash

This time xorg crashed directly after moving the mouse. Hope this was intentional :-)
Comment 11 Simon Thum 2009-04-29 05:27:17 UTC
> This time xorg crashed directly after moving the mouse. Hope this was
> intentional :-)
No, definitely not. The expected output shows up once, so this can't really be the culprit.

Problem is, I think DebugF & friends are unreliable in the signal handling loop, but I never managed to trigger it. Bois down to: Is it repeatable and does it vanish if you remove the ErrorF line?

If neither, try to gather more data from your problem case please. 

Else, Peter how does one handle debugging in the signal loop?
Comment 12 Peter Hutterer 2009-04-29 19:10:43 UTC
> Else, Peter how does one handle debugging in the signal loop?

ErrorF should work fine in the signal handler, AFAICT.
Comment 13 Peter Hutterer 2009-04-29 19:12:01 UTC
> --- Comment #10 from Christian Schmitt <chrschmitt@gmail.com>  2009-04-29 04:33:32 PST ---
> Created an attachment (id=25254)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=25254)
> xorg log with even more debug and crash
> 
> This time xorg crashed directly after moving the mouse. Hope this was
> intentional :-)

addr2line -e /path/to/Xorg 
and then enter the memory addresses of the crashes to get the line.
Comment 14 Simon Thum 2009-04-30 04:18:40 UTC
Created attachment 25303 [details] [review]
patch to use lroundf() insterad of casted roundf()

I suspect (without much evidence) a rounding problem; maybe you can try this patch. It fixes a warning on newer gccs and may be related to your issue too.

I also have a pad, but I never had such problems.
Comment 15 Peter Hutterer 2009-05-10 21:55:55 UTC
Can this bug be closed with 35fce4e5c7fa34f98b3e4010c6cb09ce38a9205c being pushed?
Comment 16 Simon Thum 2009-05-10 22:45:20 UTC
(In reply to comment #15)
> Can this bug be closed with 35fce4e5c7fa34f98b3e4010c6cb09ce38a9205c being
> pushed?
I don't have a PPC based system to test; it would be better to have confirmation first. The symptoms can't really be explained 100% by a rounding problem, except in cases where it would amount to a libc bug. That or I'm misreading the roundf()/lrintf spec.

On my system, rounding behaviour is also a bit off, maybe PPC is even worse.
Comment 17 Simon Thum 2009-05-10 22:50:51 UTC
Created attachment 25715 [details]
test code

Test program to show rounding behaviour of different rounding methods. Interesting cases are 0.5, 1 ,1.5, 2.5.
Comment 18 Simon Thum 2009-05-19 04:22:49 UTC
Below commit changes the (likely) relevant code. Since there was nothing obviously wrong with it, chances are it is fixed now. Christian, could you please retest?

http://cgit.freedesktop.org/xorg/xserver/commit/?id=35fce4e5c7fa34f98b3e4010c6cb09ce38a9205c
Comment 19 Christian Schmitt 2009-05-19 16:11:19 UTC
(In reply to comment #18)
> Below commit changes the (likely) relevant code. Since there was nothing
> obviously wrong with it, chances are it is fixed now. Christian, could you
> please retest?

Yes, that looks good now. I am back to xorg from git and I see no more problems on the PPC machine. Thanks for fixing this.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.