[Xquartz-dev] 2.3.3_rc1

[Jack Howarth]

On Tue, Mar 10, 2009 at 04:59:50PM -0600, George Peter Staplin wrote:
> Quoted Jack Howarth <howarth at bromo.med.uc.edu>:
>
>> Jeremy,
>>   Okay. I have figured out the Apple Software Render usage. When that
>> was used for the OpenGL render in vmd-xplor, I had not deleted or
>> renamed the copies of libGL and libGLU provided in   
>> vmd-xplor-1.5.1-Darwin_8/bin.MACOSX.
>> If I remove those local copies from the vmd-xplor installation, hardware
>> rendering is used under X11 2.3.3-rc1 on a dual G4 with Radeon 7500 graphics
>> and vmd-xplor behaves normally. However if I do the same on my MacBook Pro
>> with Radeon X1600 graphics, I get the following errors with vmd-xplor
>> -debug -nowin and with...
>>
>> LIBGL_DIAGNOSTIC=1
>> export LIBGL_DIAGNOSTIC
>>
>> added to the vmd-xplor startup script...
>>
>> Info) VMD for MACOSX, version 1.8.5 (September 19, 2006)
>> Info) http://www.ks.uiuc.edu/Research/vmd/
>> Info) Email questions and bug reports to vmd at ks.uiuc.edu
>> Info) Please include this reference in published work using VMD:
>> Info)    Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
>> Info)    Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
>> Info) -------------------------------------------------------------
>> Info) Multithreading available, 2 CPUs detected.
>> ERROR) filetype argument '-debug' needs a filename.
>> Xlib:  extension "Generic Event Extension" missing on display   
>> "/tmp/launch-FIgrW9/:0".
>> initializing libGL in apple_init_glx
>> DIAG: CGL major 1 minor 2
>> Xlib:  extension "Generic Event Extension" missing on display   
>> "/tmp/launch-FIgrW9/:0".
>> WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x1106b5
>> WARNING: unknown GLX tag from server: tag 0x17c7dab0 value 0x0
>> WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
>> WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
>> WARNING: unknown GLX tag from server: tag 0xb0dac717 value 0x0
>> WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
>> ...
>> WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
>> WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
>> WARNING: unknown GLX tag from server: tag 0xb0dac717 value 0x0
>> WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
>> DIAG: apple_glx_create_context: ac 0xc4e080 ac->context_obj 0x100cc00
>> DIAG: apple_glx_drawable_create: new drawable 0x100f200
>> X Error of failed request:  BadRequest (invalid request code or no   
>> such operation)
>>   Major opcode of failed request:  128 (Apple-DRI)
>>   Minor opcode of failed request:  2 ()
>>   Serial number of failed request:  40
>>   Current serial number in output stream:  40
>
> I now think I know what is wrong -- PPC binaries have a different byte  
> order, so when the X server request comes in, there is no expectation  
> that a LocalClient() would need byte swapping.  X assumes that if  
> LocalClient is true, then we have the same byte order, and the AppleDRI 
> extension makes that assumption too.  This may explain why indirect 
> worked before, because in that case the LocalClient would return false, 
> and swapping occurs due to the use of indirect.
>
> If you run the X server with Rosetta it should all work.  This may help:
> http://support.apple.com/kb/HT1730
>
> Specifically this is the path that is failing:
>    if (!LocalClient(client))
>         return DRIErrorBase + AppleDRIClientNotLocal;
>
>     switch (stuff->data)
>     {
>     case X_AppleDRIAuthConnection:
>         return ProcAppleDRIAuthConnection(client);
>     case X_AppleDRICreateSurface:
>         return ProcAppleDRICreateSurface(client);
>     case X_AppleDRIDestroySurface:
>         return ProcAppleDRIDestroySurface(client);
>     case X_AppleDRICreatePixmap:
> 	return ProcAppleDRICreatePixmap(client);
>     case X_AppleDRIDestroyPixmap:
> 	return ProcAppleDRIDestroyPixmap(client);
>
>     default:
>         return BadRequest;
>     }
>
> That's from:
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/xpr/appledri.c?h=xorg-server-1.4-apple
>
> I haven't changed that path in a way that would make this fail.  It's an 
> old bug.  Hopefully we can resolve this in a better way in the future.  
> Perhaps the client could send its current byte order, but that wouldn't 
> work either, because we would need all X protocol requests to do that.  
> The LocalClient should really change to understand the Mac Rosetta case 
> better, but we would also need to byte-order swap in the AppleDRI code, 
> and handle the local case with swapping to make this work properly.
>
>
> George
> -- 
> http://people.freedesktop.org/~gstaplin/
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

George,
    Oddly I don't seem to have an 'Open in Rosetta' checkbox for the X11
application in 10A286? Do you have one in your copy of Snow Leopard?
I guess I had better file a bug report about that one.
                 Jack