[Xquartz-dev] XRandR crash fixed (was Re: XQuartz-2.6.0_alpha1 (SL Only))
doh123 at doh123.com
Mon Aug 2 19:13:42 PDT 2010
using this fixed version works much better.. without all the crashing... actually I've tested a ton and it never crashed at all!
I can open a buncha bug reports if you'd like... i think all the main issues are in the switching from rootless screen 0 to any of the other screens... or vise versa, and you already said it was disgusting, so you might be expecting all these problems.... so I thought I'd write out what I've seen here first.
Wine still has issues, and quartz-wm I believe.
Running a fullscreen only game (Neverwinter Nights) all went well, it launched and went into fullscreen and I went in the options it saw all the modes available and i could click through and use each one, very nice! (this game has no window option)
Running Neverball was a different story...
If its set to fullscreen at any resolution and I launch the game, it does come up fine, eventually even though its hung on a blue res change screen 5 to 8 seconds... (sometimes very fast, sometimes the blue screen and res changing happens multiple times before the game shows up... and takes over 10 seconds)... i can change a few screen resolutions around, and it seems to work, but occasionally, usually while going up to a higher res, or back to max screen res, i just see a quick white fullscreen window do the genie effect down to X11.app... the game music keeps playing, but the game is no longer accessible... although the music is still playing and the wine processes are still going along like nothings wrong. Its not listed in X11 as a running app anymore on the top menu or right clicking the dock icon, though the xterm i started it from thinks its still going. This same thing happens if I use CMD+H to hide the app... its gone... with the sound still playing, and I can't ever get back to it without killing wine (or ending the process I launched from the xterm) and starting over. Going back and forth between rootless and fullscreen a few times does this as well...
When switching from fullscreen back to a window... quartz-wm doesn't kick in... so theres no top bar.... when starting in a window and switching to fullscreen, quartz-wm doesn't stop and there is a top bar... and there are all kinds of problems with things being drawn in the right place like this. I'm not sure if this is a Wine issue though... but its not a problem on Linux I've ever noticed.
I'll find some more programs I can use to test with to confirm issues... finding ones that work right in Wine on Linux is my first choice, so the error isn't a Wine issue...
ohhh... also, I noticed when it changes to fullscreen, xterm windows shift off the bottom so the top bar of their windows are barely on the bottom of the screen and I have to drag them up... didn't know if this was intentional to get them out of the way, but they never come back up on their own.
anyways... I'm excited, this is awesome :-)
On Aug 1, 2010, at 10:23 PM, Jeremy Huddleston wrote:
> Ok, it seems there were two problems. Both seem to be fixed with this binary:
> Download, decompress, set executable, and use it too replace XQuartz.app/Contents/MacOS/X11.bin
> The code for switching between rootless and fullscreen modes is disgusting and needs to be refactored. Things are all kinds of ugly there.
> Thanks for being good little guinea pigs. It really helps!
> On Aug 1, 2010, at 03:44, Per Johansson wrote:
>> I knew you'd say that. :) Next time I'll do it beforehand.
>> Running xrandr without arguments first or after the first xrandr -s 1 does not make any difference for me.
>> Pelle Johansson
>> 31 jul 2010 kl. 18.15 skrev Jeremy Huddleston:
>>> I can reproduce this. It's likely the current mode or something isn't getting initialized properly. Running 'xrandr' before making any changes seems to be a workaround.
>>> (would you mind putting this in a bug report at http://xquartz.macosforge.org?)
>>> On Jul 31, 2010, at 02:34, Per Johansson wrote:
>>>> Nice. RandR doesn't seem very stable yet though. If I launch Xquartz and type xrandr -s 1 in the xterm, all Xquartz windows will disappear. The screen is otherwise unchanged (still rootless). If I then type xrandr -s 0 in the invisible window, Xquartz crashes:
>>>> Thread 3 Crashed:
>>>> 0 libSystem.B.dylib 0x00007fff83e6538d usleep$NOCANCEL + 0
>>>> 1 libSystem.B.dylib 0x00007fff83e8497c abort + 93
>>>> 2 X11.bin 0x0000000100107653 System + 0
>>>> 3 X11.bin 0x000000010000cef1 xf86SetRootClip + 0
>>>> 4 X11.bin 0x000000010010df19 AbortServer + 29
>>>> 5 X11.bin 0x000000010010d924 FatalError + 264
>>>> 6 X11.bin 0x0000000100105dc8 OsSigHandler + 151
>>>> 7 libSystem.B.dylib 0x00007fff83df635a _sigtramp + 26
>>>> 8 com.apple.CoreFoundation 0x00007fff84c70181 CFEqual + 145
>>>> 9 X11.bin 0x00000001000123c4 QuartzRandRSetModeCallback + 275
>>>> 10 X11.bin 0x00000001000120b6 QuartzRandRSetConfig + 372
>>>> 11 X11.bin 0x000000010005d5c6 RRCrtcSet + 617
>>>> 12 X11.bin 0x00000001000645ac ProcRRSetScreenConfig + 807
>>>> 13 X11.bin 0x00000001000bc88c Dispatch + 127
>>>> 14 X11.bin 0x00000001000b328f dix_main + 198
>>>> 15 X11.bin 0x00000001000117c2 server_thread + 43
>>>> 16 libSystem.B.dylib 0x00007fff83dcf456 _pthread_start + 331
>>>> 17 libSystem.B.dylib 0x00007fff83dcf309 thread_start + 13
>>>> Jul 31 11:17:45 Falken [0x0-0x27b27b].org.macosforge.xquartz.X11: Segmentation fault at address 0x81
>>>> Jul 31 11:17:45 Falken [0x0-0x27b27b].org.macosforge.xquartz.X11: Fatal server error:
>>>> Jul 31 11:17:45 Falken [0x0-0x27b27b].org.macosforge.xquartz.X11: Caught signal 0 (). Server aborting
>>>> Jul 31 11:17:45 Falken [0x0-0x27b27b].org.macosforge.xquartz.X11: OsVendorFatalError
>>>> Jul 31 11:17:45 Falken [0x0-0x27b27b].org.macosforge.xquartz.X11: AbortDDX
>>>> Jul 31 11:17:46 Falken org.macosforge.xquartz.startx: Xquartz: start_x11_server: (ipc/mig) server died
>>>> If I click the desktop and the the Xquartz icon after I do xrandr -s 1 I get too fullscreen mode and the window is visible. Still crashes on xrandr -s 0 though (or xrandr -s 2 for that matter).
>>>> xrandr -s 2 changes the mode, but it's still rootless and the window is still missing. xrandr -s 0 does not crash after that and changes back the mode. The xterm window can then be found in the upper right corner of the screen, almost off screen.
>>>> I'm on a MacBook Pro 15" (summer 2009) with 10.6.4.
>>>> PS. I have a game that seem to require 16 bit mode. Is there any way to run it now that there's no color depth switch in System Preferences?
>>>> Pelle Johansson
>>>> 31 jul 2010 kl. 02.23 skrev Jeremy Huddleston:
>>>>> I just uploaded 2.6.0_alpha1 for testing.
>>>>> Firstly, this release was built using a recent trunk of llvm-clang rather than the current XCode. I intend to use that compiler to build our alphas and betas and will switch back to the stable XCode toolchain for rcs and final releases.
>>>>> The main changes in 2.6.0_alpha 1 are the jump to the 1.9 server (currently 184.108.40.2065) with the addition of initial support for RandR. RandR support will be maturing over the next few months, but it is at a fairly usable state. Please report any issues that come up.
>>>>> Additionally, 2.6.0_alpha1 includes the fixes that I intend to ship in 2.5.3 next week:
>>>>> * properly cleaning up /tmp
>>>>> * addressing AIGLX regressions
>>>>> * xmore-1.0.2
>>>>> * xrandr-1.3.3
>>>>> You can get it by checking for updates in XQuartz. If it say's you're on the latest release, you'll need to change to the beta update stream:
>>>>> defaults write org.macosforge.xquartz.X11 SUFeedURL http://static.macosforge.org/xquartz/downloads/sparkle/beta.xml
>>>>> Or you can just grab it here:
>>>>> Xquartz-dev mailing list
>>>>> Xquartz-dev at lists.macosforge.org
>>>> Xquartz-dev mailing list
>>>> Xquartz-dev at lists.macosforge.org
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
More information about the Xquartz-dev