Added a configure option called --enable-standalone-xpbproxy which is useful for deveoping xpbproxy.
The 'active' switch in preferences just disables the in-server xpbproxy (not this standalone).
(cherry picked from commit 42944936326ef8732f622db9f75b79a92980550d)
This prevents visuals with odd sizes. The machine I use didn't have
this problem, but it shows up on some others.
(cherry picked from commit ed181382ddeb77019577d39b9c06b1cd839e18e4)
Use the settings queried from the system in xprScreen.c, rather than those 2 calls.
The 2 calls increased the total number of visuals a great deal (when using GLXEXT),
and not all of the visuals were usable with GLX. Some of the visuals aren't usable
with GLX still, such as DirectColor, but that seems to be acceptable based on my
understanding of the manual that states "a subset of visuals are made available
for OpenGL rendering."
(cherry picked from commit 373b8a5f32509722e06d8776109e6c3f06645ee0)
It was returning inverted values in comparison to the 1.4 branch. This resulted in
the windows not drawing due to a deep path of: RootlessReorderWindow ->
SCREENREC(pScreen)->imp->DoReorderWindow(winRec) - > xprDoReorderWindow ->
AppleWMDoReorderWindow.
(cherry picked from commit d1d398db762fe7d5720f9b5fafa2bbe8372fceac)
GL/capabilities.c: Add handleDepthModes(), and extend
handleRendererDescription() for the various depth and multisampling flags.
Add initialization of the new config options to initConfig().
GL/capabilities.h: Add depth and multisample config members.
GL/visualConfigs.c: Add depth and multisampling support to the visual config
setup.
(cherry picked from commit f527381eea6a8ae6cd791475b2060d21fcf8efb2)
GL/capabilities.c: #if 0 (for now) any capabilities above 8 bits per channel,
because they introduce drawing problems.
GL/indirect.c: Comment out some visual setup code that shouldn't be running, and
actually seemed to cause some problems. The current visualConfigs.c code seems
to do a reasonable job of setting up visuals for XQuartz.
GL/visualConfigs.c: Make use of the proper visual .class. Eliminate depth 0.
It seems we really just want 24 for now, and 0 I think was a flaw in the original
code.
(cherry picked from commit 1e5f63f15e13a40a6e69a1505934d10d6990b6a2)
This is used in libGL to determine a preferred visual. glxinfo -v will also
report "visualCaveat=Slow" for such visuals.
(cherry picked from commit d5c17f585a240be9f9135975738e62951cde3353)
It seems that we were calling copy_completed: too soon. Now we return instead
of falling through to the free_propdata, and copy_completed:.
(cherry picked from commit 5797d5b662817a3369a74a673f4a7c995cde75cf)
Eterm ends up setting the type of the property to TARGETS, instead of ATOM.
That's why it wasn't working.
(cherry picked from commit 9be5998ede7427f14dd9597e117b3d6b427ba4e5)
This may work, unfortunately I don't have test apps that fail.
The way it works is by using an NSImage class initWithPasteboard:
method, which we then get the TIFFRepresentation of, and convert
to PNG or JPEG.
The TIFFRepresentation uses NSTIFFCompressionNone; which should be
lossless.
(cherry picked from commit 8d048cfa956f4a0860250cc836a6748912b37ad8)
This gives us a *lot* more visuals, and they should be more accurate.
Some of the visuals may have been wrong before. This may enable more
OpenGL programs to behave correctly.
I also suspect libGL needs a little work to handle some of these correctly.
(cherry picked from commit 98a084ce9c455260ecdb5f8eecb67f33dbb53b69)
We need to revisit the GL/indirect.c changes. I think indirect.c should
be using the same feature detection and GLX visual config code. The
indirect changes will require testing...
(cherry picked from commit 49b7a7c6f20ca85d4d624444eb83db2f91344591)
Jeremy Huddleston
Ben Byer
George Staplin
George Peter Staplin
Daniel Stone