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>)
Created attachment 25222 [details] output of evtest This shows that x coordinates are passed correctly
Created attachment 25223 [details] xorg log file
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
It is indeed related to it :) My xorg version is only one day old. I reverted the patch and the problem is gone.
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]);
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.
(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.
Created attachment 25240 [details] second try of debug Ok. Hope this time it is allrigt :)
> 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
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 :-)
> 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?
> Else, Peter how does one handle debugging in the signal loop? ErrorF should work fine in the signal handler, AFAICT.
> --- 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.
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.
Can this bug be closed with 35fce4e5c7fa34f98b3e4010c6cb09ce38a9205c being pushed?
(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.
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.
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
(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.