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.
If HAL isn't available when we try to connect, the registered NameOwnerChanged
signal handler waits until HAL is available. Once we connected to HAL, we
unregister the signal handler again.
This allows HAL to be started in parallel or after the server has started.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yes, this is an ugly piece mess of #ifdefs, but it beats having two nearly
identical functions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- use DEST in the createPixmap wrapper, because stipple already takes MASK (in case someone uses swappers).
- Anticipate some of the less common situations when fbValidateDrawable will access tile related pixmaps.
- I did some testing with full fallbacks forced by the driver.
- I ran rendercheck, expedite and the (full) x11perf test suite.
- Thanks to ajax for pointing out this should be unneeded.
This is probably required, but apparently not sufficient, for making migration
heuristics other than "always" work correctly again. Not that I really care
about them...
If we have a busted xkb setup, the XKB initialization on the core devices
fails and leaves us with dev->key->xkbInfo == NULL. This in turn causes
segfaults lateron.
Return BadValue when the XKB configuration for a master device failed, and if
that happens for the VCP/VCK, die semi-gracefully.
The VCP init can only fail on OOM.
Reported by Aaron Plattner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
This patch gets the shadow scanout buffer repainted on panning area changes.
It does not, however, track the mouse correctly.
Signed-off-by: Keith Packard <keithp@keithp.com>
When the shadow scanout buffer can be re-used, the underlying framebuffer
area must be damaged so that the scanout will be repainted. This patch
delays the addition of that damaged area until after the transform in the
crtc has been updated, otherwise the old transform would have been used and
the wrong area repainted.
Signed-off-by: Keith Packard <keithp@keithp.com>
If the computation of the composite fixed-point transform for RandR
overflows at any point, take the resulting floating point transform and
scale that back to fit in a fixed point matrix. This ensures that a matrix
will always be available, although perhaps at reduced precision. Someday we
should add floating point matrices to Render.
Signed-off-by: Keith Packard <keithp@keithp.com>
dbus-core.c:30:1: warning: "DBUS_API_SUBJECT_TO_CHANGE" redefined
<command-line>: warning: this is the location of the previous definition
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add parenthesis around the whole expression.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
