Reduce cluttering public interface with non-exported stuff, moving those
things into a separate internal header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The client.h file is part of the public module API, but it also contains
definitions that aren't useful for being used in modules. Splitting them
out into their own client_priv.h file, which isn't part of the API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file isn't included by any driver - not even indirectly, and hard
to imagine any driver ever needs it, so no need to keep it installed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, so no need to keep them exported.
As already touching them, give them a proper name prefix for clarity.
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>
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>
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