It's deprecated in SnowLeopard. Ben and I both have no idea what it is for. It says something about unicode input, but urxvt seems fine taking in unicode, so /shrug... bye.
(cherry picked from commit 29cb904e4d)
xextproto had Xlib client headers moved into libXext.
Protocol header files are named fooproto.h, header files with constants
foo.h or fooconst.h where foo.h was already in use for client-side headers.
(cherry picked from commit d3f6b43a24)
Its last remaining purpose in life has been destroyed by input
properties. Au revoir: it's been fun, by which I mean awful.
(cherry picked from commit 22e64108ec)
This extension provided bug-compatibility with pre-X11R6, but has been
stubbed out in our server since 2006 to return BadRequest when you actually
asked for it.
(cherry picked from commit 25827fde68)
I don't understand the *why* ... I just see that it works better this way for games like Quake2 through wine. It *should* be better the other way, but somehow it's not.
I guess this will go in my list of puzzles to unravel.
With trying to match depths so that you didn't end up with a depth 24
fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth
24 X visual, which angered other applications. But in fixing that, the
pickFBconfigs code for "minimal" also could end up breaking GLX visuals if
the same FBconfig was chosen for more than one X visual.
We have no reason to not expose as many visuals as possible, but the old
"all" mode didn't match any existing X visuals to GLX visuals, so normal
GL apps didn't work at all.
Instead, replace it with a simple combination of the two modes: Create GLX
visuals by picking unique FBconfigs with as many features as possible for
each X visual in order. Then, for all remaining FBconfigs that are
appropriate for display, add a corresponding X and GLX visual.
This gets all applications (even ones that aren't smart enough to do FBconfigs)
get all the options to get the visual configuration they want. The only
potential downside is that the composite ARGB visual is unique and gets a
nearly full-featured GLX visual (except that the root visual might have taken
the tastiest FBconfig), which means that a dumb compositing manager could
waste resources. Write compositing managers using FBconfigs instead, please.
(cherry picked from commit c40bad88475debf7a1774e22dce835577ad32154)
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 516f8e2cad)
The main change is cleanup of the visualConfigs and setting up alpha correctly there to match the visuals being added earlier (so the default visual has a corresponding GLX visual)
(cherry picked from commit 7351db5c87)
This was in place to work around the issue that was correctly solved with the
previous commit (changing the Windows menu behavior). Reverting this change
no longer causes crashing, so it's safe to show the dialog now.
