This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several sources including it without need. For consistency, those who still
need someting from there should include exitinit_priv.h (which also pulls
in extinit.h)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On NetBSD, pccons is (almost) dead: only remaining port is arc,
but only on some specific kernel, which is unlikely to be used
for running X.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's more robust / easier understandable programming style to use explicit
switch statements, case'ing on the constants defined in the protocol header,
instead of implicitly via a some opaque call table. It's also done this
way in the other extensions, so making the code a bit more consistent.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When using struct initializers, all fields not set explicitly are zero.
Also no need to swap fields that are known to be zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The `majorVersion` and `minorVersion` fields are CARD16, thus need to be swapped.
OTOH, the lengths field is zero anyways, so no need to swap it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file became obsolete with 33350ef8ff, but was forgotten to
be removed.
Fixes: 33350ef8ff
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These 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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The original intention was negotiating versions before any further requests
can be processed, so requests that might become incompatible in future versions
still can be dispatched correctly. But practically that's never been the case:
there's just one major version, and it's unlikely that a new *major* version
(that might be incompatible with the current one, using same request codes for
different things) will come in the forseeable future.
So this extra logic isn't practically needed and just complicates dispatching.
Dropping it clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The diffenciation between Xinerama and single screen version is by tweaking
call vectors unncessarily complicated: it the only reason why these are
needed in the first place. Finally, it's just about one function, so it's
much easier just branching off in ProcDamageCreate() in case of Xinerama
is enabled.
This also clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move extra complexity out of the dispatch functions, so they're
really just switch/case statements calling the actual handler procs.
Preparation for further steps.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These 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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These 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.
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>
A little bit of code simplification by using static initialization
of struct right at the point of declaration. Also dropping a few now
unneccessary zero assignments.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Coherently moving all reply struct decls and assignments into static
initialization right at declaration, just before it is getting byte-
swapped and sent out. Zero-assignments can be dropped here, since the
compiler automatically initializes all other fields to zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This part moves the request payload structs (or pointers to them) into the
per-version branches. Within each branch following our usual scheme for
extension request handlers (eg. using the REQUEST*() macros and having a
pointer named `stuff` to the current request struct)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This part is splitting the huge request handlers into upper and lower half,
where the upper is doing the version check and converting v1 requests into v2,
while the lower one is doing the actual request processing, operating on the
struct pointer passed in from the upper one, instead of the client struct's
request buffer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This moving the request size check into the if-version-X branches, to make it
some bit easier to undertand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These 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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These code pieces have been commented out since their introduction back
almost two decades ago, so probably no need for them anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have one function doing nothing more than calling another one
with the same prototype.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of highjacking core request handlers, use the recently introduced
DDX/driver API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't have a standard protocol for enabling VRR yet, but some time ago an
ad-hoc had been made in the amdgpu driver (later also copied to modsetting),
which works by client setting the _VARIABLE_REFRESH window property.
The way it's currently done - driver is highjacking the X_ChangeProperty and
X_DeleteProperty request handlers - is pretty fragile, and is also a violation
of layers: drivers never should be twisted with core protocol details. (And in
the future, this should be done by some suitable extension).
Another problem is Xinerama: when it's enabled, this only works on the first
screen - the others won't ever see this signal, no matter on which one(s) the
Window is physically placed (for the wire protocol, all windows are on screen 0,
unless the client explicitly creates them on another one)
This commit adds a generic Screen proc for telling the DDX, whether the VRR mode
shall be changed (for now, it's only DISABLED and ENABLED). Drivers can hook into
here in order to receive this signal, w/o having to highjack any core request
handlers. Catching the property change is now entirely done in the DIX.
The (non-standard) status qou of (ab)using window properties is kept, but it's
now also easy to add a new signaling mechanism, in case a standard is agreed on.
Yet a quite naive implementation (eg. not acting on moving windows between screens),
but enough to fix the most pressing problems supporting extra screens in general,
as well as stopping the highjacking of core request handlers by drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult