seeking Apple X11 developer...

Do any of you know someone who works on X11 for Apple?

The XScreenSaver configuration tool is basically unusable on MacOSX because it crashes the X server all the time. This has been the case for a couple of years and after many updates to, and I can't figure out any way to work around it.

I'm not really sure what the cause is, but it's easy to reproduce: run xscreensaver-demo; click on any GL program in the list; then click on any other GL program in the list. X crashes. It doesn't crash if you click on a GL program; then a non-GL program; then a GL program, but I haven't been able to figure out any workaround other than that.

So I'd like to find someone at Apple who can run a development version of their server and either: A) actually fix it, or B) give me some hint what's going wrong so that I can work around the bug...

(I haven't tried it under non-Apple XDarwin because there doesn't seem to be a binary download available, and life is far too short to spend it compiling X11.)

Update: Apple Bug 4356702, FWIW.

Update 2: Hey, they fixed it! Yay! It'll be a while before the fix is in shipping code, of course...

Tags: , , ,

29 Responses:

  1. boggyb says:

    Probably something you've already tried, but I'll throw it in anyway just in case. Also bear in mind I don't use xscreensaver, due to being one of them evil Windows users.

    What happens with changing between programs in the list? Do they use the same rendering enviroment (window, GL context, etc.) or do you clean up after the old program and load the new one with a fresh window/context/whatever? How is this different for switching to/from a non-GL program?

    This is a wild guess and probably something you've already looked into, but you never know. Good luck fixing it!

    • jwz says:

      Believe me, I've tried all kinds of things; I can't even come up with a smaller reproducible test case that doesn't involve the whole xscreensaver-demo framework, which strongly suggests some kind of race condition. I destroy the old window and create a new one before launching the new program, so there's no re-use of data on the client side. Introducing all manner of delays between death and launch affects nothing.

      I suspect the root of this bug is that the DRI layer is failing to clean itself up properly, but damned if I can figure out what noise to throw at it to make it reset itself. Since non-GL programs don't use DRI, it could be that something about launching one of those makes DRI reset to a sane state, but this is a wild-assed guess.

      • jwz says:

        But, it's not as simple as "just open a non-GL server connection" because the bug still happens if you do: select GL program; launch xterm; select GL program.

        • ralesk says:

          Since you say it doesn't happen when you do a GL, non-GL, GL sequence with xscreensaver, how about somehow "emulating" this - I don't know how it works, but you could launch a blank, non-GL saver for a little time, quit it, and then proceed with the selected GL one.

  2. edibiase says:

    In theory, the best way to get in touch with the X11 team is through the Apple Developer Connection Bug Reporter.

    • jwz says:

      That's a fascinating theory.

      • edibiase says:

        Sometimes it even works in practice, too!

        You hadn't mentioned if you'd tried reporting it as a bug or not, so I figured I'd mention the site. I've heard some really good stories from people about getting support there, and also some really bad ones (it seems to be easy to get your bug marked "duplicate" and then to never hear anything else about it).

        • anricat says:

          Well, if it's a dupe, it's a dupe. We can't have a gagillion bugs that are all identical and have to keep track of each and every one. If you get a bug that is a dupe you just have to hope we are working on it. We usually are :)

          Though, filing bugs that get marked as dupe is actually a good thing because when the owner of the bug sees another dupe, they see that people are running into it and hence it needs to get fixed.

          <lj user="otterley"> sent me over here to see if I can help, but unfortunately, X11 is outside of my jurisdiction and I don't know anyone on the X11 engineering team. Developer connection is probably your best bet on this one.

          • edibiase says:

            Thanks for the response!

            As for the dupes, I'm just hoping that one day I'll get access to the original bug when one I file is marked as a duplicate. Although, I have to admit, the current scheme does provide a good incentive for me to be the first person to report a bug!

            • anricat says:

              Yah, it's a bummer you don't have access to those. Luckily when my bugs get marked as dupes, I can always keep tabs on them. But then, that's part of my job (keeping tabs on bugs).

              • strspn says:

                It's more than a bummer. More people would bother to file bug reports if they thought there was a likely chance they would be able to see it through to conclusion. Opaque duplicates are absurd. Bugs should only be opaque when they are sequrity related. If you're worried about customer-identifiable information in the description and comments, that should be handled with a privacy policy telling people to redact stuff if they don't want dupe filers to see it. (Grumble.)

          • sc00ter says:

            As long as the original ticket # is put in the dupe ticket then that would be fine. That way at least the person that created the dupe could go look at the original ticket to keep track or add notes.

            • anricat says:

              I'm not sure what it looks like from the developer side, but internally, it will say "This is a duplicate of 123456." Then there is a button for me to open the dupe so I can track that.

              • smackfu says:

                From a consumer perspective, a dupe is just a blackhole since we can't query by number. We can only see problems we opened.

      • chanson says:

        Have you filed a bug? If so, you should post the number so people at Apple can look it up. If you haven't filed a bug, please do so.

  3. this_old_man says:

    Ask Jordan Hubbard. I used to work with Jordan on OS X. I don't know the X11 team, but Jordan should be able to point you in the right direction. You can explain that I sicced you on him. Contact me for his address.

  4. Do any of you know someone who works on X11 for Apple?

    If you don't have any luck asking here, you may wish to try and ask on OmniGroup's MacOSX-Talk list - I know at least one or two Apple employees are active on the list, as they've gotten in touch with me before after seeing posts I've made to the list. Hope this helps.

  5. ajaxxx says:

    according to their changelog, the only person who seems to touch is John Harper, he formerly of the sawfish window manager.

  6. defenestr8r says:

    i'm sure david long could put you in touch with the right people at apple. if you need his contact info (although i suspect you have it), email me.

  7. violentbloom says:

    I have friends at apple. Send me a good bug report and I'll get it to the right people.

  8. pfig says:

    and give us a native aqua version :)

    • jwz says:

      Yeah yeah. But every time I think about trying again to wrap my brain around XCode, I think of something a lot more fun to do. Like laundry.

  9. jaydubbee says:

    I guess you don't want to build sources, but I dumped the X11 package that comes with Tiger (because it had serious problems in rooted (full-screen) mode) and built the latest release of This solved several problems for me, including some serious GLX errors, which I now no longer remember specifically.

    I used fink to build from sources, which took me virtually no time as I just started it and left for the evening. It was built and installed when I returned. It's all shell and makefiles so I didn't need to screw with XCode.

    Now you might say that you want to target the standard X11 package because that's what everyone is using, but really it has so many problems that I can't imagine anyone using it for serious daily work.

    • jwz says:

      So not interested in just making it work on my machine by running something non-default.

      I've had no other problems with Apple's X, but then the only thing I've ever used it for is remote XEmacs and the occasional remote GTK program. But I'm sure that's more than what 99% of the people who use it use it for, which is xterm.