Composite extension is always enabled for pretty long time now, but some
drivers (eg. xf86-video-intel) still relying on this symbol being set,
otherwise assuming to run w/o composite and doing crazy things.
Fixes: d708b28adc
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It always had it's own lifecycle (not been part of Xorg releases),
doesn't make sense to maintain a competing implementation that we
won't use anyways.
Once that's gone, we can also drop few things in core/dix that had
been added just for xwayland only.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
in struct _Screen (include/scrnintstr.h) there is a PRIVATE_LAST-sized array,
having another private increases PRIVATE_LAST, the array increases in size,
moving everything below it down. this breaks ABI for nvidia driver
Signed-off-by: dasha_uwu <dasha@linuxping.win>
Adding data structure and initial data for namespace configuration.
Built-in namespaces are ROOT and ANONYMOUS.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add tiny skeleton for the namespace extension. Disabled by default,
can be enabled via +extension arg, but doesn't actually do something yet.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify cases where callers need to check whether an entry already is
in a list before adding / appending.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function walks through the list and checks whether an entry is already
present. This check sometimes is neccessary, since trying to add an entry
twice has catastrophic consequences: iteration will become endless loop.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Up until now, xorg_list's always need to be explicitly initialized by
calling xorg_list_init(), otherwise next access attempt will segfault.
This is adding extra complexity and risk of subtle bugs.
Adding some extra NULL check are trivial and their cost is so tiny
that it's even hard to practically measure.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, and shouldn't be used by them.
Needs to _X_EXPORT'ed, as long as glx is a separate module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This allows us to do further probing in the included meson files:
Individual subdirectories (eg. DDXes, extensions, OS layer, ...)
can now probe things that are only relevant to them - no need to fill
the already too fat includes/meson.build with even more things.
Preparation for upcoming commits that'll make us of that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Lots of logging functions, especially init and teardown aren't called
by any drivers/modules, so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
systemd is linux specific and the actual implementation is under the
os-support layer of xfree86 ddx. Thus no need to keep it in global
include directory, putting it onto the linux specific os-support instead.
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>
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>
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>
Since we're not indirectly writing via FILE anymore, this option has
become meaningless: it meant flushing out our in-process buffer to
the kernel, but we're now doing direct write() calls anyways.
xf86 still accepts the "flush" config file flag for backwards compatibility,
but it hasn't any practical meaning anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult
dasha_uwu