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.
This should fix some issues when building on different versions of OSX. We only use extensions that OpenGL.framework's glext.h header tells us are supported.
This happened because we put a byte in the fd to wake up dispatch, but we never actually enqueued anything in mieq because the num_events was 0.
(cherry picked from commit c21ca7558d)
Currently no code path exhibits the broken behavior since we only toggle into rootless if we don't have the root.
(cherry picked from commit 970f100ca3)
The changes actually caused all windows to move to the current space. Instead, we're going with a fix entirely within Xplugin that depends on quartz-wm being the window-manager for now.
(cherry picked from commit 997b6f3142)
Otherwise if X11.app was activated with a mouse click, the location of the even is the last location of the cursor before X11 was deactivated
(cherry picked from commit c7457d7b31)
Patch courtesy of Codeweavers
Fix mouse movement tracking. For a non-window-related mouse-move event,
calculate the new position by adding the event's delta-x and delta-y values
to the previous mouse position. Do not rely on the current mouse position
because it may have been changed by a XWarpPointer call.
(cherry picked from commit 7a67935b05)
