Jeremy, Please pardon my ignorance, but if it is waiting patiently, why is the CPU time counted and the fan is blowing at full speed? I would understand if it were wating in its own loop, but this is a unix. Maybe we have found a bug in darwin?
have you seen this with other apps?
No, I haven't seen this with other apps, but I don't run too many. Other than firefox and emacs-app, I hardly use anything on this mac; occasionally I run Apple utilities, such as (now very useful) Activity Monitor. I mostly use this machine as a terminal and a drawing pad. I use it as a computer, too, but my computation does not involve GUI, so I cannot tell. Negative, based on whatever little I have seen.
Does it happen only when using your stylus?
No, it happens without the stylus attached. Gimp skips mouse events just as well. On the account of the lost events, I have just tried the stylus with Ink, and it works smoothly, even if I write extremely quickly. So I don't think the events are lost in the kernel space. I've made a couple more experiments since my last message. First, I tried to attach gdb to it, in the hope that I could stop it inside one of those crazy idle loops and get a meaningful backtrace. Guess what. It didn't do that with gdb attached. Almost as soon as I detached gdb, the same X11.bin went crazy again. While in gdb, I could work normally without any perceptible impediment, except gimp was missing the pointer events (from the stylus, as well as the mouse). Then I randomly fooled around with it, hoping to find a trigger for this behavior. 4 times in a row, it started at the same moment the screen timed out and turned off. I could hear the fan kick into high speed seconds later, and found that X11.bin was at 100% by logging in from another machine (without touching the keys). I had almost finished typing the announcement of this finding, when I noticed that the 5th screen time-out experiment turned out negative, and so did the 6th and the 7th. So seemed to be the 8th, but then I left for 30 minutes without touching it, and when I came back, X11.bin was again spinning the fan. So I am still not sure whether there is a reliable way to reproduce it, but statistically, this has been a likely sequence: 1. Start X11 2. Start gimp and do something in it. 3. Switch to another app for a while. Even transferring focus to Activity Monitor may be enough. Sometims it takes only 10-15 seconds to activate the fan; sometimes multiple minutes, and almost as often as not, nothing will happen during a very long time. 4. But if it does happen, any activity in gimp or any other X11 client brings it back to normal. Until it loses focus or until the screen turns off, in which case the high idle is likely to occur again. Returning to normal seems to be new in 2.3.2.1. In rc3 and rc4, I had to restart the machine (another fact suggestive of a kernel-space problem). By the way, when it does this, ps shows it as running (as does Activity Monitor): 35884 ?? R 20:49.98 /Applications/Utilities/X11.app/Contents/MacOS/X11.bin -psn_0_3273503 35897 ?? S 0:00.05 /usr/X11/bin/xterm 35898 ?? S 0:00.02 /bin/sh /usr/X11/bin/startx 35964 ?? S 0:00.01 /usr/X11/bin/xinit /usr/X11/lib/X11/xinit/xinitrc -- /usr/X11/bin/X :0 -nolisten tcp -auth /Users/selkovjr/.serverauth.35898 35968 ?? S 0:00.00 /usr/X11/bin/X :0 -nolisten tcp -auth /Users/selkovjr/.serverauth.35898 Attaching gdb as an anchor to lull it could be a fine hack, but it doesn't solve the event-skipping problem in gimp, which makes it useless as a drawing tool. That may very well be a bug in gimp, and I was going to set off in that direction, but Tom's observation of missing keystrokes made me think again. Is it possible that something is broken where all events are handled? Also, the same version of gimp and the same tablet work fine with the recent Xorg in linux. How much code does that isolate as suspect? Thanks, --Gene