Commit d8ec33fe05 added libglxvnd.la to
Xwayland_LDFLAGS but GLX can be disabled through --disable-glx.
In this case, build fails on:
make[3]: *** No rule to make target '../../glx/libglxvnd.la', needed by 'Xwayland'. Stop.
make[3]: *** Waiting for unfinished jobs....
Fixes:
- http://autobuild.buildroot.org/results/397f8098c57fc6c88aa12dc8d35ebb1b933d52ef
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Drop installing packages which were used by the autotools build (or
maybe even monolithic build!) but are no longer required by the meson
build
Also, alphabetically sort within tools, protocol headers, devel
libraries, miscellaneous groups to match [1]
[1] https://x.cygwin.com/docs/cg/prog-build-prerequisites.html
Also, update to require xkbcomp-devel, split from xkbcomp
Using YAML line-folding doesn't seem possible, as setup doesn't tolerate
spaces between package names, so instead drop some unneeded double quotes,
double quote the whole thing and escape newlines
As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
want to create a fence, then initialize it in their own way. This currently
can't be done without adding a function directly to Xext/sync.c due to the fact
that the RTFence resource type is private and there is no external interface to
add to it.
To facilitate other X extensions creating fences and initializing them, this
change exports SyncCreate() and adds the resource directly within it. Callers no
longer need to call AddResource() after SyncCreate(), they only need to
initialize the SyncObject.
To prevent FreeFence() and FreeCounter() from segfaulting if the call to
AddResource() fails before the sync object is initialized, this adds a new
'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
FreeCounter() to skip de-initialization and simply free the object.
Initialization after adding the resource shouldn't otherwise be a problem due to
the single-threaded nature of X.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
We had various helper functions trying to come up with the
internalformat/format/type/render formats for pixmaps, and it's much
nicer to just detect what those should be once at startup. This gives
us a chance to do the right thing for GLES.
It also, notably, fixes our format/type for depth 15 and 16 setup for
desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
drivers instead of 32bpp (GL_RGB/UBYTE).
GLES still has regressions over desktop (2 regressions in llvmpipe
XTS, many in rendercheck), but I think this is a good baseline.
Signed-off-by: Eric Anholt <eric@anholt.net>
For GLES, we're going to need a lot more logic for picking the
iformat/format/type of texture setup, so we'll want the pixmap's depth
and is_cbcr flag.
Signed-off-by: Eric Anholt <eric@anholt.net>
"format" is a bit of a confused term (internalformat vs GL format),
and all we really needed was "is this GL_RED?"
Signed-off-by: Eric Anholt <eric@anholt.net>
../hw/kdrive/src/kdrive.c:999:1: warning: no previous prototype for ‘xf86_find_platform_device_by_devnum’ [-Wmissing-prototypes]
Place the same guards around this stub as are around including the
hotplug.h header which declares the prototype.
If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
macro evaluating to -1 by systemd-logind.h, leaving paused
uninitialized.
../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’:
../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition]
We hide CWBackingStore from the screen hook if nothing's actually
changing, which means compChangeWindowAttributes no longer needs to
compare the requested state with the present one.
miHandleExposures does two things: computes the region for which to
generate expose events, and (if the destination is a window) paints the
exposed regions with the background. The bit of this conditional we're
deleting here asserts that the source is either a pixmap or a window
without backing store. The only other possibility is a window _with_
backing store. In the old backing store implementation, this was where
you would recover bits from backing store. Since our "backing store" is
the redirected window pixmap, we know we've already copied all we could,
because CopyArea had already seen the entire window pixmap. So now in
that third case, we are still drawing to a pixmap (so there's no
background to paint) and we are still not generating events, so we can
exit early.
The comment above the function about recovering bits from backing store
is clearly misleading, so delete that too.
Drivers may need to loop over the allocated screens during PreInit, for example
to consolidate xorg.conf options that apply to a GPU device as a whole.
Currently, this works for protocol screens becuase x86Screens is exported, but
does not work for GPU screens.
Export xf86GPUScreens and xf86NumGPUScreens for consistency with xf86Screens and
xf86NumScreens.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
If the user sets Option "Enable" "TRUE" for a monitor, the X
server will connect the connector a crtc but tell the user it
is disconnected.
However the user in this case is mutter, when it gets it's view
of the output configuration it sees the output is disconnected
and never sets it up again, which seems like the right thing to do.
If we let the user enable a monitor, lets just set it as always
connected.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Up to twice, for a total of 3 attempts maximum.
This will hopefully avoid spurious CI pipeline failures due to
intermittent GitLab/docker infrastructure issues.
Inspired by
6140ed3d2c
Reviewed-by: Eric Anholt <eric@anholt.net>
This cleans up some code duplication. No functional change.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Terms:
dev->last.valuator[] is the last value given to us by the driver
dev->valuator.axisVal[] is the last value sent to the client
dev->last.scroll[] is the abs value of the scroll axis as given by the driver,
used for button emulation calculation (and the remainder)
This function updates the device's last.valuator state based on the current
master axis state. This way, relative motion continues fluidly when switching
between devices. Before mouse 2 comes into effect, it's valuator state is
updated to wherever the pointer currently is so the relative event applies on
top of that.
This can only work for x/y axes, all other axes aren't guaranteed to have the
same meaning and/or may not be present:
- xtest device: no valuator 2
- mouse: valuator 2 is horizontal scroll axis
- tablet: valuator 2 is pressure
Scaling the current value from the pressure range into the range for
horizontal scrolling makes no sense. And it causes scroll jumps:
- scroll down, last.valuator == axisVal == 20
- xdotool click 1, the XTest device doesn't have that valuator
- scroll up
- updateSlaveDeviceCoords reset last.valuator to 0 (axisVal == 20)
- DeviceClassesChangedEvent includes value 20 for the axis
- event is processed, last.value changes from 0 to -1
- axisVal is updated to -1, causing a jump of -21
The same applies when we switch from tablet to mouse wheel if the pressure
value is 0 on proximity out (basically guaranteed). So let's drop this code
altogether and only leave the scaling for the relative x/y motion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For really testing glamor, we want it installed. Use master instead
of whatever version is in repos, because we'll want to update when new
tests are added.
Signed-off-by: Eric Anholt <eric@anholt.net>
We cover all Render ops under the "blend" group, so when we're doing
the cross products of some formats for the masking operation, skip
most of the ops (covering just zero, one, and src/dst alpha blend
factors along with a definitely non-glamor-accelerated one) .
All the tests now complete in <20s of runtime on my skylake.
Signed-off-by: Eric Anholt <eric@anholt.net>
This gets us parallelism between rendercheck tests at the cost of
spinning up more Xvfbs, and nicer logging of the tests that are run.
Signed-off-by: Eric Anholt <eric@anholt.net>
I've found that it's hard to find the original error in a dump full of
xserver debug spam for the passing cases, and when I needed to look at
this I end up using a proper editor on the file from the artifacts
view anyway.
Signed-off-by: Eric Anholt <eric@anholt.net>
Michel noted that I could do this instead of bumping the tag as I
developed, so leave that note for the next person.
Signed-off-by: Eric Anholt <eric@anholt.net>
For testing xephyr-glamor on top of Xvfb in CI better, I want to be
able to make one command line describing the nested server invocation,
but that means I need to get two simple-xinits to split client/server
on different "--" arguments.
Signed-off-by: Eric Anholt <eric@anholt.net>
There shouldn't be a difference for users, but this way we do manage
all of our containers from freedesktop.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
systemd-logind since version 234 (released 2017-07-12) supports being
restarted without losing state [1]. From the systemd NEWS file [2]:
* systemd-logind may now be restarted without losing state. It stores
the file descriptors for devices it manages in the system manager
using the FDSTORE= mechanism. Please note that further changes in
other components may be required to make use of this (for example
Xorg has code to listen for stops of systemd-logind and terminate
itself when logind is stopped or restarted, in order to avoid using
stale file descriptors for graphical devices, which is now
counterproductive and must be reverted in order for restarts of
systemd-logind to be safe. See
https://cgit.freedesktop.org/xorg/xserver/commit/?id=dc48bd653c7e101.)
This reverts commit dc48bd653c.
Closes: #531
[1] https://github.com/systemd/systemd/pull/5600
[2] 9f09a95a7e
Applying get_pkgconfig_variable() to a not-found dependency was always
documented as an error, but meson 0.49 now actually raises an error[1]:
meson.build:110:4: ERROR: 'xkbcomp' is not a pkgconfig dependency
Check xkbcomp_dep is a suitable dependency type before applying
get_pkgconfig_variable() to it.
[1] but this is more by accident than design (see the discusssion at [2]
et seq.), so who knows where things will come to rest...
[2] https://github.com/mesonbuild/meson/pull/4444#issuecomment-442443301
xwl_present_cleanup frees the struct xwl_present_window memory,
so if there's a pending callback, we have to destroy it to prevent
use-after-free in xwl_present_sync_callback.
Should fix issue #645.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This is maybe one more comparison, but it catches FullyObscured windows
slightly earlier, so it's kind of a wash. The important thing is this
allows for paintable but unmapped windows, which will have non-empty
clipList.
If `_glamor_create_tex()` fails to allocate the FBO because of
GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL.
However, `glamor_get_pixmap_texture()` doesn't actually check whether
the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer
dereference trying to access the `pixmap_priv->fbo->tex`.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/647