Post by Matthieu HerrbOn Wed, Aug 3, 2011 at 1:49 AM, Matthieu Herrb
Post by Matthieu HerrbPost by Super BisquitMy apologies before hand.
I'm wondering how the OpenBSD PPC port dealt with the mouse grabbing.
Sorry, I don't understand the question. What kind of grabbing
are you
Post by Matthieu Herrbtalking about? At the X server level, there is nothing MI in this
area.
The mouse pointer will get caught on the left edge of the screen
and then
only a restart of X allows the pointer to be free again.
And thanks for the reply.
On OpenBSD/macppc, I don't remember having seen that problem, but I
may be wrong, and I don't use it on a daily basis anymore. We had it
on other architectures though.
The main reason for this bug is the SIGIO handler in the
Xserver. By default X processes all the data from the mouse driver in
the signal handler attached to SIGIO. With the new pointer
acceleration code this includes a good amount of floating point
computations, and may even trigger some MMX/SSE2 operations in
libpixman to repaint the pointer on the screen.
If your signal handling code doesn't preserve the FPU (and the
altivec) registers, this is likely to trigger the bug.
The easiest solution is to disable the code that uses SIGIO to
asynchronously update the pointer. pass --disable-use-sigio-by-default
to configure for this, or set the option in xorg.conf.
Post by Matthieu HerrbPost by Super BisquitI would like- if possible and with permission- to use the
same method
Post by Matthieu Herrbwith
Post by Super BisquitFreeBSD PowerPC to solve/prevent the grabbing.
Again, my apologies beforehand if this post to the mailing
list seems or
--
Matthieu Herrb
Thank you for the help and tell DeRaadt thanks also. I'm forwarding
this mail to the FreeBSD PowerPC list for the others to see it.
That's a really fascinating problem. Our signal handling code explicitly
preserves FP and Altivec registers. Our setjmp()/longjmp() code does
not, for various reasons, but that shouldn't be related to this problem.