On Wed, May 11, 2011 at 2:53 AM, Dave Airlie <airl...@gmail.com> wrote: > Hey, > > So we got a bug reported against F15 where we were getting an illegal > input event type 0, after passing it around the RH X team I eventually > came to look at it. > > The problem appears to be that we are using llvmpipe as our swrast > renderer and on systems that fallback to that we end up with threads > inside the X server, that we didn't spawn. It appears SIGIO gets > delivered to one of these threads while the main thread keeps on > trucking and fail ensues. > > So I'm crossposting this as there are two fixes we can do that aren't > exclusive but could act as belt and braces on Linux at least (other > OSes get the belt only). > > Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging > up this nugget, "From Linux 2.6.32 onwards, use F_SETOWN_EX to > target SIGIO > and SIGURG signals at a particular thread.". So on > Linux we would use that instead of F_SETOWN to make sure SIGIO only > goes to the main X process/thread. Though I'm not sure how to get the > defintion for gettid which we need, though I'll look into this a bit > more. > > Fix 2: block all signals in the gallium thread spawning code, this > involves using pthread_sigmask around the pthread_create function. > Calling it once with a full set of signals to block, and get a copy of > the current signals, then calling it again to put back the current > signals. I think this might be a good plan for some other things, as I > can't see a good reason for a DRI driver to ever get SIGIO, esp as it > may interfere with the parent app. > > I've built a test package with 2 in it for Fedora and am awaiting > feedback from the tester, but just though I'd raise the subject here > for some discussion/feedback.
A different solution could be to use the input thread idea and stop taking SIGIO. Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
