No need for extra call to some demuxer function for nothing but setting a
simple int variable. Setting verbosity level really is nothing more than just
writing some value into a variable, so it's trivial to just to do that, instead
of having an unncessarily complex "universal setter" for that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for extra call to some demuxer function for nothing but setting a
simple int variable. Setting verbosity level really is nothing more than just
writing some value into a variable, so it's trivial to just to do that, instead
of having an unncessarily complex "universal setter" for 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>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The only consumer seems to be one BSD specific file, the few drivers using
the *_iopl seem to include it on their own. Thus, no need to keep it in
public headers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it clear that stuff from this file really isn't supposed to be used
by dynamically loaded modules like drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The DDX callbacks (where core/DIX calls into DDX) aren't supposed to be
called by drivers directly, so unexport them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These functions shouldn't be called by drivers or extensions, thus
shouldn't be exported. Also moving it to separate header, so the
already huge ones aren't cluttered with even more things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are only used inside xkb.c, nowhere else, so no need to
keep them in public header.
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>
Resolve name conflict with Sun's <sys/kbd.h> by renaming STRING enum
value to XF86_TOKEN_STRING.
This way, don't need the special #undef hack anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not good having the public server api headers clobbered with private
definitions, so cleaning them up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xorg-server.pc missed a few dependencies, so consumers might not
get them and break build.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On SunOS, the BSD socket API as well as hostname lookups isn't
implemented in libc, but separate libraries. We need to link them
explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several feature defines need to be set before including system headers,
otherwise build breaks:
> /usr/include/X11/Xtrans/Xtranssock.c: In function '_XSERVTransSocketRead':
> /usr/include/X11/Xtrans/Xtranssock.c:2161:14: error: 'struct msghdr' has no member named 'msg_control'
> 2161 | .msg_control = cmsgbuf.buf,
> | ^~~~~~~~~~~
> /usr/include/X11/Xtrans/Xtranssock.c:2162:14: error: 'struct msghdr' has no member named 'msg_controllen'
> 2162 | .msg_controllen = CMSG_LEN(MAX_FDS * sizeof(int))
> | ^~~~~~~~~~~~~~
>
> ../os/access.c:339:14: error: implicit declaration of function 'asprintf'; did you mean 'Xasprintf'? [-Werror=implicit-function-declaration]
> 339 | length = asprintf(addr, "%s%c%s", type, delimiter, value);
> | ^~~~~~~~
> | Xasprintf
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>
Several places using _X_ATTRIBUTE_PRINTF macro from X11/Xfuncproto.h
but missing to include it, so it depends on other headers whether it's
included by mere accident, which quickly causes trouble if include order
changes. Cleaning that up by adding explicit include statements.
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>
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>
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>
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>
XServer refuses the create windows with different color depth than the parent's,
just in the special case that neither border pixmap nor border pixel is given,
even if the screen supports it. (that's also one of the reasons why Xnest fails
to run with different color depths than the default one)
it really doesn't make sense to deny this, while it's allowed when having a
border color or pixmap set.
Fixes: ded6147b - R6.6 is the Xorg base-line
Closes:https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1644
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since we're now using xcb for upstream X11 connection, it's cleaner to
use it's type for the window IDs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that we completely ported from Xlib to XCB, we can finally stop
importing Xlib :)
FIN.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no Xlib operations (besides opening and closing connection)
aren't used anymore, we can move over the last pieces and use XCB
instead of Xlib for connecting the upstream Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no X11 calls are being done via Xlib anymore, we're free to
also move over event receiving, leaving Xlib pretty much unused.
Also need to add a simple event queue mechanism, because we've go a
screen operation (see xnestBitBlitHelper) that needs to collect up
certain events for it's return value.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
