This header makes use of types and functions defined in gcstruct.h and
privates.h. It should include them, instead of demanding it's consumers
having done that before including this file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Tidy it up a bit and split the actual request handler from the request
reading loop, making upcoming reworks easier to review (smaller diffs).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code easier to read/understand by scoping variables to where
exactly they're needed. Also a preparation for subsequent reworks
(keep the diff smaller and thus easier to review)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Canonicalize all reply structures onto stack allocation and static
initialization, like already done in most other extension. So make
the code easier to understand and allow further simplifications by
subsequent commits. Also gaining a little bit efficiency by skipping
some heap allocations.
Dynamically sized buffers (where the upper bound isn't known), are
still allocated on heap.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The current way of switching between Xinerama and single-screen handlers
is quite complicated and needs call vector tables that are changed on
the fly, which in turn makes dispatching more complicated.
Reworking this into a simple and straight code flow, where individual request
procs just look at a flag to decide whether to call the Xinerama or single
screen version.
This isn't just much easier to understand (and debug), but also removes the need
or the call vectors, thus allowing further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Most of the complexity here isn't needed at all. It can be really trivial,
since we just have one operation anyways.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In order to allow simplifying the reply send path, collect the reply
fragments into one buffer, instead of arbitrary number of WriteToClient()
calls. This also makes it much easier for potentially new purely packet-based
transports which (eg. binder) that would need their own stream parsing logic.
This xres function is an exceptionally hard case, since payload is constructed
step by step, and it's size only known when finished. The current way of the
fragment handling still has lots of room for improvement (eg. using very small
number of allocations), but leaving this for later exercise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect the few bits in a local array, so one WriteToClient() call is
sufficient. That's also easing further simplifications in upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
The upper bound is determined by the number of resource types registered
in the server - this can only be increased by writing new extensions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect the few bits in a local array, so one WriteToClient() call is
sufficient. That's also easing further simplifications in upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
Note: there's an upper bound by compile time defines (theoretically, can
be increased by special cmdline args, that virtually nobody ever using).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify the dispatching by moving the branching between Xinerama
vs. single screen into the actual request handlers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Split reply header and payload buffers. Making it more coherent with all the
other request handlers, and allows a lot of further simplification by using
generic macros (coming in subsequent commits).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When using static struct initialization, fields not explicitly
stated are automatically zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's some piece ifdef'ed code that doesn't serve any practical purpose.
Instead add a little comment telling why that funny way of dispatching
(based on request size) is necessary.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's safer to zero-out the cursor-private memory on allocation,
instead of relying on being cleared initialized somewhere later.
Fixes: 3f3ff971ec - Replace X-allocation functions with their C89 counterparts
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1652>
We alread have several of these calls, that aren't interested in result value,
explicitly casting to void. Fixing this up for the remaining ones.
This is helpful for the human reader as well as quality analysis tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1648>
pkg-config path is wrong: it's using /usr/share/pkgconfig from the *host*
instead of sysroot, which is leading to wrong pathes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1655>
The vidmode extension emulation in Xwayland reports the modeline based
on the current mode.
To do so, it searches for the mode using `xwl_output_find_mode(-1, -1)`
which is supposed to return the current mode, whatever that mode is.
With XRandR emulation, in rootless mode, the default value is the mode
at index 0. That assumption, however is not true when running rootful.
That means that the vidmode extension will always return the highest
mode available, which is 5120x2880, with Xwayland running rootful:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"5120x2880" 1276.50 5120 5560 6128 7136 2880 2883 2888 2982 -hsync +vsync
Luckily, when Xwayland is running rootful, we have the current mode size
conveniently stored in dedicated fields of the xwayland output struct,
so we can use that to search for the right mode being used and report
that through the vidmode extension:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"1024x768" 63.50 1024 1064 1176 1328 768 771 775 798 -hsync +vsync
That fixes legacy games using the vidmode extension and rendering at the
wrong size when running within Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1641>
The code here assumed a `leave` event always occurs between two `enter`
events. On Sway (and presumably other compositors) this happens even if
the client has destroyed the `wl_surface`, but the client gets a null
`surface` here. (Which presumably on on the wire is the id of the
destroyed surface.)
This seems like a bad thing to rely on, and is easy to avoid. But if
this is correct to assume, the Wayland protocol should be explicit about
this.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1527>
Now that we won't enable DRI3 if <sys/eventfd.h> is not available, there
is not point in trying to include that header without DRI3.
That allows to build Xwayland with GLAMOR enabled (without DRI3) on
platforms which do not support eventfd.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1523>
DRI3 version 1.4 which supports explicit buffers synchronization relies
on the eventfd interface.
As result, building would fail with DRI3 enabled on platforms without
the eventfd interface.
Check for the availability of the sys/eventfd.h header and disable DRI3
support if missing.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1523>
This rewrites the shader so that we use the same (more flexible) CSC as
we have for I420 and NV12. This also fixes the reverse of odd/even which
caused chroma shift.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1633>
UYVY videos should be aligned by 2 to avoid breakups in the shader
Fixes: 832b392f7 - glamor: xv: enable UYVY acceleration
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1633>
Enrico Weigelt, metux IT consult
Olivier Fourdan
Ian Douglas Scott
Nicolas Dufresne
Konstantin