> > That I've seen before, analysed a bit and posted:
quoted text
> > http://permalink.gmane.org/gmane.linux.kernel.input/4281
>=20
> Ahh.. And this is presumably triggered either by some new Xorg behavior i=
n=20
quoted text
> fc9 or just the scheduler timing changes that caused other things too?

I tend to think it's actually a regression, I've done exactly what I
described there dozens of times before on older kernels and it doesn't
seem to be a race condition, X always locks the input device and I never
had trouble with that before.

quoted text
> Your suggested solution sounds ok, but I'm also wondering why those thing=
s=20
quoted text
> aren't properly refcounted? It does sound like a bug to free the thing=20
> before all users are gone - regardless of anything else. Hmm?

I have to admit to not understanding the depths of the input code, I
just took a quick look when I posted that. Mind you, that was 5 weeks
ago!

quoted text
> But the ungrab sounds like the best short-term fix. Do we have a patch fo=
r=20
quoted text
> testing? Please? It's pretty late in the 2.6.25 cycle for these kinds of=20
> things..

I don't. I think Dmitry just said in the other mail that he did, but I
haven't seen that yet.

johannes