[Xquartz-dev] 2.3.3_rc1

[George Peter Staplin]

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/