The `buflength` variable doesn't exist anymore, it's `rlength`.
And even if the reply struct might have the same size as XGenericReply,
it's cleaner to let the compiler compute it explicitly, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It seems xf86bigfont hasn't been compile-tested for long time,
some includes were missing.
Note that fontstruct.h needs to come before libxfont2.h, because X11
headers tend to be not self-consistent :(
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This fixes a regression in 5499a2999 (xkb: let SendDeviceLedFBs() fill buffer instead of writing directly, 2024-07-16).
We need to write the whole buffer, and the updated length has to take
into consideration that `sz` now contains `led_len` so we need to
subtract that or properly calculate the remaining size.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Since Redhat deleted everything related to Xlibre from freedesktop.org,
the driver repos had to be moved to github.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nvidia has a strange habit of messing with really internal stuff,
so need to add it to the executable's symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As long as the wfb module is still a separate shared object, this
function needs to be in the symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nvidia has a strange habit of messing with really internal stuff,
so need to add it to the executable's symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Yet another temporary re-export for Nvidia's proprietary driver.
This symbol really shouldn't be used at all by drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Support having more than one auth token per namespace, so separate tokens
can be handed out to clients that are still landing in the same namespace.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This loads the configuration (simple text file) passed via command line.
For now just supporting static configuration, that's loaded on server
startup.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Filter property access. Right now just allowed inside same namespace,
or when caller is in root namespace.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Whitelisting some XI operations in various hooks.
Note that some additional filtering needs to be done in send or
receive hook in order to prevent clients to receive possibly sensible
input data from the root window.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Filter message sending by clients. Only sending within the same
namespace is allowed (except for clients in a NS with superpowers,
e.g. root)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Filter device access, whitelist several commonly used operations that
should be safe (eg. query keyboard layout).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
CreateWindow() needs access to root window, in order to create
top level windows. Whitelisting this operation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Whitelist several extension calls that are safe. Also allow namespaces
to be configured for unrestricted access.
TBD: doesn't actually reject yet
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only namespaces with allowMouseOption flag enabled can receive
raw mouse motion events. Raw key press events are always blocked.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Redirecting access to root window properties to the per-namespace
virtual root windows. This isolates a lot of communication via root
window, e.g. the cut buffers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For each namespace creating a fake (invisible) root window, which can be
used for storing per-namespace properties (eg. cut buffers), etc.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Selection names (as seen by the client) are internally prefixed with the
namespace ID, so each client can only access those within it's namespace.
If a client within namespace "foo" want's to operate on "PRIMARY",
it actually will be doing so on "<foo>PRIMARY", w/o ever noticing it.
Events will sent back to the client still pointing to "PRIMARY".
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
When looking up the window to select on and security hook returns
BadAccess, the request is just silently ignored, instead of rejected.
This way, security hook can prevent untrusted clients to listen on
arbitrary windows, without the client even noticing. The client won't
get this BadAccess error, but instead thinking everything's fine,
just not getting the actual events.
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>
This helper checks whether a given XID belongs to some screen's
root window. It does so by looking up the window and comparing that
with the window's screen's root window pointer. The resource lookup
is intentionally being on behalf of the serverClient, so the fired
XACE hook doesn't treat it as an actual client's request.
It's explicitly designed for being used by callback handlers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a little helper that's looking up the ClientPtr to the client
of the owner of given XID. The lookup is solely done on the ID space,
the actual resource doesn't even need to exist.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add hooks for filtering and fully rewrite rewrite selection requests
and events (what existing XACE hooks cannot do), e.g. for supporting
separate selection name spaces.
The hook can change individual fields in the parameter struct, so
operation continues with these changed values (eg. replace the original
selection name atom by a different one). It's also possible to stop
operations completely (with given result code) - in that case the
hook needs to take care of the remaining work to do (eg. sending events)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This hook allows extensions to intercept client requests for changing
window attributes. It can either change the parameters or skip the
entire call (eg. handle all itself) so just the hook provided result
code is returned to the client.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
a) no need to checking for win->optional == NULL before calling
MakeWindowOptional(), because it checks itself
(except some cases where it's presence has it's own semantics,
or prevent unnecessary allocations)
b) lots of call sites didn't check for allocation failure.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Allow extensions to catch in right after a screen's root window has
been finally initialized
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are used by the in-tree libwfb.so module. As long as this an shared
object, instead of being directly linked into the executable, these symbols
need to be in the executable's symbol table. Nevertheless, they're not making
them part of the public SDK/module ABI, unless there's a really hard reason.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Xwayland is a separate project/team and has it's own releases, so it's better
trying to to intefer with them and disable it by default.
It still can be easily enabled via meson arguments, and it's still enabled
in the CI. Let distros and operators decide on their own whether they want it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Modules are now placed into a sub-directory by major Xserver release,
so we have less hassle with trying to load drivers w/ incompatible ABI.
The legacy directories are still searched (after the versioned ones)
for backwards compat with badly maintained proprietary drivers (Nvidia).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs those fields for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia yet again doing crazy shit in their proprietary drivers:
This is an DIX-*internal* function for triggering client teardown when
connection broke or somehow lack of resources to accept new connections.
Video drivers have no business with that whatsoever - having them messing
with client client connections is just insane.
But still trying to be kind with Nvidia victims, thus adding a little wrapper
function under the old name. It spills out a log warning calling users to file
bug reports their driver vendor.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since *a lot* has changed since last Xserver release, need to increase
the ABI version.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia yet again lagging behind a year with trivial cleanups,
even though they're informed about this function being deprecated
and dropped.
It spills out a log warning calling users to file bug reports their
driver vendor.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's chance of buffer overflow happending due lack of zero-termination
of printed string. Making sure the buffer is always propertly terminated.
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1821
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used externally, and not actually necessary - we can use the
xf86Info.vidModeEnabled field directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used externally, and not actually necessary - we can use the
xf86Info.vidModeAllowNonLocal field directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used externally, and not actually necessary - we can use the
xf86FlipPixels field directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of having several separate exern declarations in various
source files, using one central one xf86Config.h
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, and this header isn't even installed
in the SDK, so no need to keep this field exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code is easier to understand when variables are declared where they're
used for the first time, scoped to where they're needed and not reused
for separate things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, we're only registering the depths of our visuals, which are
mirroring upstream's visuals. But forgotten to register the pixmap depths
that don't have an assiocated visual.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No release yet, so we have to use a specific commit (latest master).
Desperately need some bug fixes not in last release yet.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No release yet, so we have to use a specific commit (latest master).
Desperately need some bug fixes not in last release yet.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's needs a bunch of fixes that still aren't upstreamed yet.
Intel driver team seems to be in sleeping beauty's coma :o
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>
Parses an option that may either be used for setting an integer value or
given one or multiple times (without argument) to increase an value
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>
The variables that can be set via this function are all now being
accessed directly. Not callers left, so drop it.
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 bool variable. Setting the sync flag 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>
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>
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>
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>
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>
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>
xnestWindowExposures() is a micro-optimization for the specific case that
a newly created window receives exposure events (from our upstream server)
inside the region we're already exposing on our own (miWindowExposures()):
it peeks the Xlib event queue for all expose events, checks whether their
areas are inside our exposure region and requeue's those that aren't.
Unfortunately, this depends on Xlib's internal queue mechamism, thus standing
in the way of moving to XCB (which doesn't have that).
Removing this doens't seem to make any practical difference, even with
demanding applications like GIMP. The only cost is potentially having some
initial window content painted twice, *if* the application really draws
something complicated right after creating the window.
*If* there'll really be a demand for such an optimization some day, it can
be reimplemented without any message queue: just redirecting all expose events
into recording them in a region, which is flushed out later. But for now,
there really doesn't seem to be any practical need for that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use the visuals lookup table introduced by previous commit for
looking up local vs upstream visuals and their colormaps.
Replacing the the old Xlib visuals table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Record the associations between host's and our visuals as well their
corresponding cmaps in a global table, which's used later for lookups.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This is a temporary measure, until xcbproto / libxcb is fixed:
keep an own copy of the fixed xcb_xkb_get_kbd_by_name(), renamed
as xcb_xkb_get_kbd_by_name_1().
Once xcbproto/libxcb is fixed (and new xcb release is out), this
commit can be reverted.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no Xlib drawing functions used anymore, we can finally switch over
to using GC XID's directly, instead of Xlib's GC struct.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Replace XDrawImageString() by xcb_image_text_8(), as well as their 16-bit
counterparts.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Replace XDrawString8() by xcb_poly_text_8(), as well as XDrawString16()
by xcb_poly_text_16(). Some care needs to be taken to prepend the xTextElt
header before sending the request out.
GC operation handlers don't need to care about poly-strings or length
above 254, as this is already handled by their caller, doPolyText().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of going through mi machinery, just pass the ClearArea
request to the upstream window.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use xcb_create_colormap() and XFreeColormap() instead of XCreateColormap()
and XFreeColormap().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using xcb_shape_rectangles() and xcb_shape_mask() instead of Xlib's
XShapeCombineRegion() and XShapeCombineMask().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Upcoming patches will need to retieve GC's XIDs on the upstream connection.
Moving this out into separate .c file, in order to not creating more
dependencies on Xlib headers, which we wanna get rid of.
For now, looking at the Xlib GC structure, attached to our DDX GCs.
When all users of the Xlib GC have gone (ie. moved all consumers to xcb),
we'll create the GC via xcb directly, thus replacing the Xlib GC struct
by XID - the interface of this helper will remain the same.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fetching the setup data from xcb instead of Xlib, storing in our own struct,
holding all information needed for one particular upstream connection.
For now, there's only one, but future multi-upstream implementation will
change this to an array (and storing pointers to particular upstream in
various places).
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>
Instead of having lots of #ifdef's, consolidating the conditionally
compiled fsync() call into a tiny inline helper.
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>
Instead of maintaining both the logfile fd, as well as ANSI FILE pointer,
simplify it to just a fd.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Neither used by any drivers, nor makes sense doing so, thus no need
to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, and wouldn't even make sense doing so,
thus no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These functions are entry points of the DDX (or stubs thereof), not supposed
to be called by any drivers, so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, and it doesn't seem make much
sense doing so, thus no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are only used inside xkb internally, so no need to keep them
in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are only used inside xkb, not by any drivers, so no need to
keep them in public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make sure everything it needs is explicitly included, so we don't need
to rely on some specific include order.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers/modules, so no need to keep it public.
Since modesetting is using it, still needs _X_EXPORT, as long as it's
a module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ProcVidModeGetAllModeLines() is a bit complicated, because reply structs
differ depending the active protocol version. In order to make it easier to
understand and allow further simplification of the request/reply marshalling
(see ticket #1701), splitting the two protocol versions into separate functions.
Also collecting the whole payload in a stack buffer (size is already known
anyways), in order to save arbirary number of individual WriteToClient() calls,
but send out the whole reply in one pass, which in turn allows further
simplifications in the sending path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
WriteToClient() already checks for zero-length buffer and does nothing
in that case. So we can make the code a bit easier to read and also
allow further simplification of reply submission by upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to understand by declaring the variables
where they're first used instead of at the very top of the function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary buffer,
so we can send it as one block. This allows for further simplifications by
subsequent commits, as well as packet based transports and message based
compression.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can simply call SwapLongs() before writing out the CARD32 arrays.
No need using for complicated call back logic.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Semantically these are separate values in each branch any only used there,
so it's a bit more clean to move the declaration into the branches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The WriteSwappedDataToClient() already checks whether client is swapped
and directly calls WriteToClient() if it's not.
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>
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>
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>
* use static initialization where applicable
* drop unneeded setting of zero values
* use scoped variables
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>
Allocate reply buffers on stack and put multiple fragments into one buffer,
in order to make it easier doing write out by generic macros, in subsequent
commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to read by using initialization of the reply
structs, at the point of declaration. Most of them aren't written to later,
just passed into WriteReplyToClient(). Also dropping some useless zero
assignments (struct initializers automatically zero-out unmentioned fields).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In general safer coding practise to always use calloc() instead of risking
forgetting to zero-out some fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Canonicalize all reply structs 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 (we can then use generic macros for doing the
actual sending, as well as byteorder swapping, size computation, etc),
Also gaining a little bit efficiency by skipping some heap allocations.
Dynamically sized payload 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>
There're lots of forward declarations for functions that don't exist
at all (possibly have been removed, but forgotten their prototypes).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using the type "Bool", which is defined in Xdefs.h, therefore this
header should be include, so we don't need to rely on it being
included indirectly by somebody else.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's no use in redefining function names via preprocessor this
funny ways. Perhaps there once was back when that header used to
live outside the server tree, but that's decades ago.
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>
Instead of trying to calloc() zero-size blocks when there's no actual payload
to send, skip the whole part. This also helps reducing analyzer noise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use static initialization where possible
* put the lists into one one block, so they can be written in one pass
* simplify size computations
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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some test cases are recycling the ClientRec between swapped/unwapped runs.
Make sure the Client's swapped flag is always reset in those cases.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to read by using initialization of the reply
structs, at the point of declaration. Most of them aren't written to later,
just passed into WriteReplyToClient(). Also dropping some useless zero
assignments (struct initializers automatically zero-out unmentioned fields).
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>
Instead of dozens of little WriteToClient() calls, collect the sub-replies in
a buffer and send the whole reply out at once. This also allows more upcoming
simplifications in the send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetGeometryReply,
called in two different cases, ProcXkbGetGeometry() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleGeometry() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetIndicatorMapReply,
called in two different cases, ProcXkbGetIndicatorMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleIndicatorMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetCompatMapReply,
called in two different cases, ProcXkbGetCompatMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleCompatMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetMapReply,
called in two different cases, ProcXkbGetMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For easier reading, move th sub-reply structs down to where they're used
first and use static initialization for the common fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move down the declaration of the reply struct, right before swapping and sending
and use static initialization.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code flow a bit easier to understand and allow further simplification
by now just having to write out one additional payload as one block.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Putting both payload pieces into one buffer, so it can be written out
with only one call.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's hard to see which fields of the xkbGetDeviceInfoReply struct it's
reading or writing, and that complicates further simplifications of the
caller. So instead let the caller pass in the relevant fields and do the
modifications on the reply structs on its own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A bit simplification in code flow.
The extra length check (did we write as much as intended?) isn't necessary,
since the buffer size is computed by the very same data before this
function is called.
Hint: the size computation must be done before calling this one, because
the reply might be encapsulated in another one (xkbGetKbdByName).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it a bit simpler and easier to read.
calloc() and WriteToClient() can handle zero lengths very well.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use static initializaton as much as possible and drop unnecessary
or duplicate zero assignments.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This macro isn't used anywhere (also not in drivers), so no need
to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external modules, and an implementation
detail anyways, so no need to keep it in public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
USE_BACKGROUND_PIXEL and USE_BORDER_PIXEL aren't used anywhere,
neither in Xserver nor any drivers, so can be dropped now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
../hw/xwin/InitOutput.c:89:2: warning: redundant redeclaration of ‘winValidateArgs’ [-Wredundant-decls]
89 | winValidateArgs(void);
| ^~~~~~~~~~~~~~~
In file included from ../hw/xwin/InitOutput.c:35:
../hw/xwin/win.h:1008:1: note: previous declaration of ‘winValidateArgs’ was here
1008 | winValidateArgs(void);
| ^~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's last users gone about 15 years ago with commit
a715de7f11, so no need
to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
micmap.c is the only consumer of these, so move them into there,
instead of maintaining them in the public API w/o any practical need.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This .c file is the only consumer of that define, so move it
there instead of carrying it around in public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it public.
Also add some type-safety by implementing it as static inline function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only ever used inside dix/grabs.c, no outside users,
no no need to keep it public.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not using anything from colormapst.h
* but several other includes have been missing (consumers had to
include them separately before that file)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Drop a several includes of colormapst where we don't actually
need something from that file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All relevant things are now in dix/colormap_priv.h, so no need
to include colormapst.h anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All relevant things are now in dix/colormap_priv.h, so no need
to include colormapst.h anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All relevant things are now in dix/colormap_priv.h, so no need
to include colormapst.h anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Formulate the buffer/field size computations a bit more verbose in
ProcXvQueryImageAttributes(), so they're easier to understand on
reading the code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make sure it's really a 32bit integer, since we're hard-casting since
we're relying on the buffer being made of 32bit integers (and treating
it like CARD32's). If we encounter an arch, where int isn't 32bits,
the compiler should shout out loud now.
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.
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>
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>
We're clearing the whole object size anyways, so we can directly
use calloc() instead of malloc() plus memset().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
a) an internal function that's not used by any drivers
b) conflicting with function/define of same name on win32
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When destroying a resource, the lookup needs to be done with
DixDestroyAccess (instead of DixWriteAccess) flag - otherwise
xace hooks can't properly differenciate what's happening.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fixes: 6c46645cfc
Several places outside Xi (eg. dix, security hooks, ...) need to know the
actual XI base opcode. This formerly had been done by a global variable,
which is filled on XI init. This has some drawbacks, eg. requires that
XI really is initialized before anybody else attempting to access this
variable - changes in extension init order could be dangerous.
Since extension opcodes are now (compile-time) fixed for all known
extensions (including XI), this isn't needed anymore. We can really
rely on the XI extension always having the same opcode base. So we
can drop that variable entirely and use the corresponding define instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Assign fixed opcodes for known (in-tree) extensions and add
defines for them. Other places (eg. security extensions) that
need to know those opcodes now can directly use those defines
not having to look them up at runtime.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In order to allow extensions being registered at fixed opcodes,
there need to be a reserved slot range. Thus `NumExtensions` needs
to start out with the upper ceiling of the reserved slot space.
Thus it cannot tell whether the array already had been allocated,
and some slots now may be NULL, so we need some extra checks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's no actual caller of this hook - removed almost a decade ago
(see commit 6cb34816af), but some remains
had been forgotten to clean up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
nothing else to do for it anymore, since all previous callers now have been
migrated to do the byte-swapping directly, so it can be dropped entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIGetFocus reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIGetSelectedEvents reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIGetProperty reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIListProperties reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIPassiveGrabDevice reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIGrabDevice reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIQueryDevice reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIQueryVersion reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIGetClientPointer reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_XIQueryPointer reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_GetDeviceProperty reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_ListDeviceProperties reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_ChangeDeviceControl reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_GetDeviceControl reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_SetDeviceValuators reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_QueryDeviceState reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_SetDeviceButtonMapping reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_GetDeviceButtonMapping reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_SetDeviceModifierMapping the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetDeviceModifierMapping the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetDeviceKeyMapping the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetFeedbackControl the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetDeviceFocus the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GrabDevice the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetDeviceMotionEvents the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Improve code readability by moving variable declarations to where
they're actually needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We already have a standard function for swapping 32 bit ints,
so let's use this one instead of rolling our own loop.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetDeviceDontPropagateList the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_GetSelectedExtensionEvents the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_SetDeviceMode the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_OpenDevice the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out X_ListInputDevices the reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Write out the X_GetExtensionVersion reply directly (and do the swapping
within the request handler) instead of going through separate callback
that's having demux the replies again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* name all of them "rep", as throughout most of the Xserver codebase
* always declare them where initialized
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function returns X result codes, but -1 isn't a valid value here.
Therefore all callers explicitly translate -1 to BadValue, so we can return
that directly instead of -1.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using simple case statements with actual opcode define's instead
of call vector arrays where the exact order matters.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request handler already does byte-swapping on its own, and
there's no extra reply-swap handler for it, so no need to call
into callbacks here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../hw/xwin/winscrinit.c: In function ‘winFinishScreenInitFB’:
> ../hw/xwin/winscrinit.c:381:18: error: ‘struct _Screen’ has no member named ‘CreateWindowA’; did you mean ‘CreateWindow’?
> 381 | pScreen->CreateWindow = winCreateWindowRootless;
> | ^~~~~~~~~~~~
> ../hw/xwin/winscrinit.c:405:18: error: ‘struct _Screen’ has no member named ‘CreateWindowA’; did you mean ‘CreateWindow’?
> 405 | pScreen->CreateWindow = winCreateWindowMultiWindow;
> | ^~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../hw/xwin/winclipboard/xevents.c: In function ‘winClipboardSelectionNotifyData.constprop’:
> ../hw/xwin/winclipboard/xevents.c:313:23: warning: ‘codepage’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 313 | int iUnicodeLen = MultiByteToWideChar(codepage, 0,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 314 | pszReturnData, -1, NULL, 0);
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ../hw/xwin/winclipboard/xevents.c: In function ‘winClipboardFlushXEvents’:
> ../hw/xwin/winclipboard/xevents.c:550:35: warning: ‘codepage’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 550 | int iConvertDataLen = WideCharToMultiByte(codepage, 0,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 551 | (LPCWSTR) pszGlobalData, -1,
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 552 | NULL, 0, NULL, NULL);
> | ~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Windows headers are pretty nitpicking about include order:
> In file included from /usr/i686-w64-mingw32/include/X11/Xwinsock.h:57,
> from /usr/i686-w64-mingw32/include/xcb/xcb_windefs.h:34,
> from /usr/i686-w64-mingw32/include/xcb/xcb.h:41,
> from ../hw/xwin/winmultiwindowicons.c:43:
> /usr/share/mingw-w64/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to hard-crash the whole server if some strdup() calls failing,
those fields already may be NULL, so consumers can handle that situation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for RunXkbComp() to hard-crash (by calling XNFstrdup()) the server
if strdup() fails to allocate more memory - it's callers already handling
the situation gracefully.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have it split into two functions one just wrapping
another, so move it all into one.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to directly hard-crash the Xserver when strdup() fails, instead
try to handle the situation gracefully.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers/modules, so no need to keep it exported.
Also adding a bit of documentation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The supported platforms already have asprintf() and vasprintf(),
so there's no need for having our own implementation anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Little helper function for checking whether a resource XID
belongs to the server itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Almost all callers have ClientPtr anyways, so we're just doing duplicate
array lookups. Just using ClientPtr directly is easier anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Retrieves the ClientPtr for the owner of given resource.
This way reducing the sites directly accessing clients[] array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can write down the function name directly. Nobody else than a few
define's in here using that macro.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving the owning client of an OtherClients.
It's an actual function, so callers don't need access to internal
knowledge (definition of struct _OtherClients, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving the owning client of an InputClients.
It's an actual function, so callers don't need access to internal
knowledge (definition of struct _InputClients, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving the owning client of a grab.
It's an actual function, so callers don't need access to internal
knowledge (definition of GrabRec, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect the Add() proto funcs from adding duplicate auth keys.
If adding a duplicate is attempted, the XID of the already
existing one is returned instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for loading the address into temporary variable and later doing
indirect call, since we can easily do direct call in each branch.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XID = 0 already is used as sign for error in several places,
so let's use that here, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Generate the auth object XIDs inside the proto funcs and only
on success, so we don't unnecessarily allocate XIDs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to explicitly hard-code strings lengths when we can use
standard strlen(). Those code pathes are so cold that trying to
spare a few cycled for an (usually inlined) strlen() doesn't seem
to justify any extra care.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code is easier to understand, but also more robust (eg. against struct
layout changes) if structs are initialized with explicit field names
instead of as lists.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some callers treating XID = 0 as a sign for non-existing resource.
Practically should not happen, but nevertheless adding extra
protection, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The old PCCONS driver only seems to be used on minimal install disks and
cannot coexist with newer ones (at least that's the feedback I've gotten
from BSD community), so there's probably no practical use case for
supporting it in Xorg anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that the name clash on GC type between Xserver and xlib has been fixed,
there's no need to do the special renaming hack anymore.
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 function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only caller already has a pointer to client struct, so no need to
let this function look it up again in the global clients array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have it ripped into two pieces, just making upcoming
changes more complicated.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Align the function's parameter names with those defined in the prototype.
Especially it makes code easier to understand if the result parameter
is also named "result" here, as in the prototype.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Improve in-code docs of some request handlers, so it becomes a bit
more obvious what they're doing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header isn't part of SDK and no external module using those functions,
so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file had been changed manually several times or at least a decode now,
so the claim it's being auto-generated isn't valid anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file had been changed manually several times or at least a decode now,
so the claim it's being auto-generated isn't valid anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Usually no*Extension fields shouldn't be needed by drivers, but there
are a few exceptions: some drivers need to know whether composite or
Xinerama are active.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only used inside EXA code, not used by any drivers, so no need to
keep it exported any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by anybody, neither Xserver nor drivers, so no need to
keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither Xserver nor drivers, so no need to keep it anymore.
According to git history, it had been introduced introduced in 2003 (*1),
but never called (inside the Xserver) - unclear whether it ever had been
actually used somewhere.
*1) 9508a382f8
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any driver for these cards anymore,
so no need for trying to probe them anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sungt driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg12 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg8 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg4 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg2 driver anymore, no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sunbw2 driver anymore, so no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always enabled for very long time now (at least since meson transition),
there doesn't seem to be any need to ever disable it again. So we can reduce
code complexity by removing all the ifdef's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new PostCreateScreenResources screen hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new PostCreateScreenResources screen hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new PostCreateScreenResources screen hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extensions that need to be called after the CreateScreenResources
proc had been run, must wrap the screen proc vector directly (all of them
forming kind of daisy chain), and so - when called - temporarily restore the
previous one, call it, wrap again, and if the call was successful finally
doing it's own stuff. (same is done for many other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
Instead introducing a simple approach for letting extension hook into a
post-CreateScreenResources callback list safely, w/o having to care much
about side effects with the call chain. Extensions now can simply register
their business logic and get called back - w/o ever having to mess with the
ScreenRec's internal structures.
Note that these hooks are executed *AFTER* the original CreateScreenResources()
proc had been called SUCCESSFULLY (returned TRUE), so callees can rely on
the DDX/driver had already done it's job.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific pixmap destruction procedures are implemented
by wrapping the ScreenRec's DestroyPixmap() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
It's even getting worse: the proc also has to do ref counting, and only destroy
the pixmap if refconter reaching zero - that's all done in the individual screen
drivers. Therefore, all extensions must check for refcnt == 1, in order to know
when to really act.
This commit introduces a simple approach for letting extension hook into the
pixmap destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
This one doesn't look so trivial at first glance, but I've checked that
other functions called by xf86CrtcCloseScreen() just free'ing up some
memory and removing the CRTCs from some lists - thus a change in
execution order really shouldn't matter at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on screen closing implemented by wrapping
the ScreenRec's PositionWindow() proc pointer: the extensions are storing the
original pointer in their private data and putting in their own one. On each
call, their proc restores the original one, calls it, and switches back again.
When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
screen closing path safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their hook proc (and an
opaque pointer) and get called back - w/o ever having to mess with the
ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window position notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window position notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window position notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on window positioning are implemented
by wrapping the ScreenRec's PositionWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window positioning path safely, w/o having to care much about side effects
with the call chain. Extensions now can simply register their hook proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific window destruction procedures are implemented
by wrapping the ScreenRec's DestroyWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Allow using it by other places outside this file, so we can also support
callback lists in dynamically allocated structures:
Those cases need to explicitly call DeleteCallbackList() before free()ing
the structures - otherwise we're getting heap corruptions, because the
actual deletion can happen asynchronously.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of retrieving the screen index from ScreenRec and passing this,
so the ScreenRec is looked up again, just pass in the ScreenPtr that
already have anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it possible to call FreeGC() w/o prior NULL checks.
In case of NULL, BadMatch is returned.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xwin relies on mi_priv.h being included indirectly, thus depending
on exact include within other header files. This can easily break if
something in other headers slightly changes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapped CloseScreen function doesn't do anything actually useful,
so no need to keep it around any longer. It used to do a free() on the
private data (which had been wrong in the first place) but this had
been removed and so the whole function became useless, it had been
forgotten to be swept away.
Fixes: 469d5bf8b7
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field hasn't been actually used, so no need to keep it any longer.
Fixes: 60f14d60f6
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol isn't set anywhere, and git history didn't show anything
were it ever had been set, thus no need to keep this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call KdCloseScreen() from
KdXVCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call fbCloseScreen() from
KdCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->ResizeWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->CopyWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both engines, GDI as well as DirectDraw, using the same screen init finish function,
so no need to keep indirection via per-engine callback pointer.
The winFinishScreenInitFB() can also be made static now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The private struct is pretty small and it needs to be allocated anyways,
so save an extra allocation by directly embedding it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external.
(BTW, those defines are only used within xf86-video-fbdev, so they maybe
could be moved over there.)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external consumers, only within the same source file,
so can become static.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No external users, so no need to keep them exported.
(note that xf86-video-intel has it's own copies of them)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aliases haven't been used (outside fb core itself), since XAA removal
back 17 years ago, no no need to carry them in public interface any longer.
See: 703a9645f3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hasn't been used since 15 years so, probably should was forgotten to clean up.
See: bbbf795e6b
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hasn't been used since XAA removal, back 17 years ago. Probably just had been
forgotten to clean up.
See: 703a9645f3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, so can be dropped. Doesn't seem to be ever used
since added over two decades ago.
See: 9508a382f8
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, so can be dropped. They always have been commented-out
since added over two decades ago.
See: 9508a382f8
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those haven't been used for over a decade now, so no need to keep
it around any longer.
See: a198373685
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header has now become obsolete. There're also no external consumers
(drivers, etc) left, so it now finally can be dropped entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external module (eg drivers), so no need to keep it
exported. Also documenting it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol isn't exported, thus not accessible to modules.
No need to keep it in public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor drivers, so no need to keep
it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Unlikely to practically happen, but still safer to just check for sure.
A simple zero-value test doesn't cost us much (on modern CPUs perhaps
not even a full clock cycle).
| ../composite/compalloc.c: In function ‘compRedirectWindow’:
| ../composite/compalloc.c:167:35: warning: dereference of NULL ‘pClient’ [CWE-476] [-Wanalyzer-null-dereference]
| 167 | ccw->id = FakeClientID(pClient->index);
| | ~~~~~~~^~~~~~~
| ../composite/compalloc.c: In function ‘compUnredirectWindow’:
| ../composite/compalloc.c:331:75: warning: dereference of NULL ‘pClient’ [CWE-476] [-Wanalyzer-null-dereference]
| 331 | if (ccw->update == update && dixClientIdForXID(ccw->id) == pClient->index) {
| | ~~~~~~~^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since GetPictureScreenIfSet() explicitly can return NULL, better be
prepared for that to happen (instead of hard crash)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even if those situations shouldn't practically happen, it's better to have
some sanity checks just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it shouldn't practically happen, better adding a trivial check,
just in case. The check is really cheap and possibly optimized-out.
| ../render/filter.c: In function ‘SetPicturePictFilter’:
| ../render/filter.c:388:36: warning: dereference of possibly-NULL ‘new_params’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 388 | pPicture->filter_params[i] = params[i];
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it practically should never happen, but just in case, and
for silencing the analyzer, add an extra check here (which doesn't
cost us much).
| ../render/picture.c: In function ‘cpAlphaMap’:
| ../render/picture.c:1002:30: warning: dereference of NULL ‘screen’ [CWE-476] [-Wanalyzer-null-dereference]
| 1002 | id = res->info[screen->myNum].id;
| | ~~~~~~^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it's probably never happening, but still better to protect from it,
just in case. The extra cost of it hard to measure on today's machines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Reduce the analyzer spam a bit by adding some extra asserts.
Since it's test code, we can't have enough of them anyways ;-)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the situation probably never happens, but better being extra
cautious, just in case.
| ../record/set.c: In function ‘IntervalListCreateSet’:
| ../record/set.c:364:5: warning: use of NULL ‘stackIntervals’ where non-null expected [CWE-476] [-Wanalyzer-null-argument]
| 364 | memcpy(&prls[1], stackIntervals, nIntervals * sizeof(RecordSetInterval));
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a little bit more logging to the startup process, eg. telling
when outputs or inputs have been initialized. Serving as a little aid for
debugging driver problems.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it might never be actually hit, it's better to have an
(really cheap) extra check, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it probably won't be hit ever, it's still better to be
really sure instead of some remote chance for hard segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As safety precaution, clear the pointers to extion records that just
have been free()ed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The checking / branchin isn't entirely trivial to understand, and the
analyzer also gets confused. So rewrite it in an simpler way that's
easier to understand both the human reader as well as the analyzer.
(and so get rid of yet another false alarm)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For type-safety turn xfreeData() macro into an inline function.
Also adding some checks against accidentially free()'ing global data.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The analyzer giving a false alarm on potential NULL-pointer deref here.
Even though that case can't happen, it's also not immediately clear
to the human reader.
To make both the analyzer as well human reader happier, reformulating
this function to by using fast-return pattern.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There might be a chance that RegionUninit() is trying to free() some
struct that's actually coming from .data segment.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The analyzer is wrong here, because the free'd closure pointer really points
to some calloc()'d chunk, instead of the PolyText()'s stack frame.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's safer not relying on all ScreenProc's actually filled.
../dix/events.c: In function ‘CheckPhysLimits’:
../dix/events.c:780:14: warning: dereference of NULL ‘pScreen’ [CWE-476] [-Wanalyzer-null-dereference]
780 | (*pScreen->SetCursorPosition)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The pointer to the window properties is currently inside the WindowOptional
structure, which may or may not exist at any given time. Thus, before accessing
those fields, at least need to check whether it exists, potentially need to
create it first.
Since a pointer is small (in relation to WindowRec) and windows having properties
is a pretty common, we can make our life much simpler here by moving the pointer
directly into WindowRec, so we don't need extra WindowOptionalRec allocation.
This also fixes an analyzer warning on potential NULL dereference issue:
| ../dix/property.c: In function ‘dixChangeWindowProperty’:
|../dix/property.c:343:37: warning: dereference of NULL ‘*pWin.optional’ [CWE-476] [-Wanalyzer-null-dereference]
| 343 | pProp->next = pWin->optional->userProps;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's a (theoretical) chance that origGC might be NULL, so better
be cautious and check for this - doesn't cost us much, probably just
another JZ instruction.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Be more cautious on possible NULL pointers or not yet registered
devPrivates. Better a gracefully fail instead of hard segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it *should* never be actually hit, it's still safer
to check for NULL instead of letting us crash with segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it's unlikely ever getting it, still safer to have some
extra checks / asserts than unexpected segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Safer (and easier to understand) if we look at the result pointer
instead of the counter for testing whether device wasn't found.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Better try to handle memory allocation gracefully than just hard
crashing by segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though chances are really low it's ever getting hit, it's still safer
to have some sanity checks (which don't cost us much) than risking segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's (remote) chance that the (internal) module name could become
NULL (eg. allocation failure). Even though chances to hit it are very
low, it's still better to have a check here (that doesn't cost us much),
just in case. Assert fail is still better than segfault, since we're
at least getting some hint what might have happened.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding paranoid extra checks against allocation failure and NULL pointers.
Even though might not be actually hit in practise, it's still better to
be cautious, just in case. And reducing analyzer noise this way.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The analyzer warnings (possible NULL dereference) are probably just
false alarms. But for safety adding assert()'s, which don't cost us
anything in non-debug builds.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
| ../glx/glxcmds.c: In function ‘xorgGlxMakeCurrent’:
| ../glx/glxcmds.c:621:24: warning: use of uninitialized value ‘status’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
| 621 | return status;
| | ^~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If this ever happens, we clearly have a bug, so print out proper warning,
instead of silently crashing the Xserver.
| ../glx/glxcmds.c: In function ‘validGlxFBConfigForWindow’:
| ../glx/glxcmds.c:127:16: warning: dereference of NULL ‘pVisual’ [CWE-476] [-Wanalyzer-null-dereference]
| 127 | if (pVisual->class != glxConvertToXVisualType(config->visualType) ||
| | ~~~~~~~^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
| ../glx/glxdricommon.c: In function ‘createModeFromConfig’:
| ../glx/glxdricommon.c:142:23: warning: dereference of possibly-NULL ‘config’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 142 | config->driConfig = driConfig;
Consumers can already handle returning NULL, so this seems the best compromise.
It will look like we don't have any modes at all. Certainly not nice, but at
least better than completely crashing the Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This warning is probably a false alarm, but it's trivial to fix.
| ../glx/createcontext.c: In function ‘__glXDisp_CreateContextAttribsARB’:
| ../glx/createcontext.c:172:24: warning: dereference of NULL ‘0’ [CWE-476] [-Wanalyzer-null-dereference]
| 172 | switch (attribs[i * 2]) {
| | ~~~~~~~^~~~~~~
The situation is too complex for the analyzer to handle:
(but also not immediately clear for the human reader)
* `attribs` is only NULL when req->numAttribs is 0
* in that case, the for loop is no-op, so `attribs` won't ever be deref'ed.
We can make it easier for both analyzer as well as human reader by just putting
the whole loop into an `if (req->numAttribs)` and assigning it inside there.
There shouldn't be any (practically measurable) extra cost.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though risk of being actually hit is minimal, better having some extra
safety checks instead of segfaulting, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
| ../Xext/panoramiXprocs.c: In function ‘PanoramiXCopyArea’:
| ../Xext/panoramiXprocs.c:1152:13: warning: use of uninitialized value ‘pGC’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
| 1152 | if (pGC && pGC->graphicsExposures) {
| | ^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though these probably never happen, it's still better having some
(really cheap) extra checks, just in case.
| ../Xext/xtest.c: In function ‘ProcXTestFakeInput’:
| ../Xext/xtest.c:385:17: warning: dereference of NULL ‘dev’ [CWE-476] [-Wanalyzer-null-dereference]
| 385 | if (!dev->key)
| | ~~~^~~~~
| ../Xext/xtest.c:442:12: warning: dereference of NULL ‘dev’ [CWE-476] [-Wanalyzer-null-dereference]
| 442 | if (dev->sendEventsProc)
| | ~~~^~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Try not to rely on deep black magic of calloc(), instead skip the whole
part of nrects is zero.
| ../Xext/shape.c: In function ‘ProcShapeGetRectangles’:
| ../Xext/shape.c:995:24: warning: dereference of possibly-NULL ‘rects’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 995 | rects[i].x = box->x1;
| | ~~~~~~~~~~~^~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../Xext/xres.c: In function ‘DestroyFragments’:
> ../Xext/xres.c:124:9: warning: ‘free’ of ‘it’ which points to memory on the stack [CWE-590] [-Wanalyzer-free-of-non-heap]
> 124 | free(it);
> | ^~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ‘RRCrtcNotify() and RRCrtcSet() functions are exported, so there's chance
that a buggy driver could call them with NULL parameter, leading to segfault.
Those are hard to trace, so it's better having a BUG_* check here.
| ../randr/rrcrtc.c: In function ‘RRCrtcNotify’:
| ../randr/rrcrtc.c:187:5: warning: use of NULL ‘outputs’ where non-null expected [CWE-476] [-Wanalyzer-null-argument]
| 187 | memcpy(crtc->outputs, outputs, numOutputs * sizeof(RROutputPtr));
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ../randr/rrcrtc.c: In function ‘RRCrtcSet’:
| ../randr/rrcrtc.c:742:20: warning: dereference of NULL ‘outputs’ [CWE-476] [-Wanalyzer-null-dereference]
| 742 | if (outputs[o]) {
| | ~~~~~~~^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If there's no data to send, the whole reply payload can be skipped entirely.
This can also ease the whole code flow, and we don't need to rely on the
individual copy loops never trying to dereference a NULL pointer.
(what the analyzer can't proof). Also scoping several some variables that
are only used when there actually is data to send.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If there's no data to send, the whole reply payload can be skipped entirely.
This can also ease the whole code flow, and we don't need to rely on the
individual copy loops never trying to dereference a NULL pointer.
(what the analyzer can't proof). Also scoping several some variables that
are only used when there actually is data to send.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Moving payload buffer assembly right into the same branch where the buffer is
allocated, so making the whole code flow easier to understand. Also moving the
byteswap there (when the fields should still be in CPU cache), instead of having
some callback doing it much later, so even more simplication.
As a nice by-product, that's also reducing some analyzer noise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code can be much simpler by just using CopySwap32Write().
And we also don't need the callback in WriteSwappedDataToClient(),
just call the corresponding write function directly.
This also makes some analyzer warnings go away.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it a bit easier to understand how exactly the name string is copied into
the reply payload: just do the little memcpy() right where the target position
is decided any the rest of the payload is filled.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplifying the code flow allocating/checking/copying some buffers in
RRConfigureOutputProperty() and RRConfigureProviderProperty() so it's
easier to understand for both the human reader as well as the analyzer.
Depending on whether we have elements to process, a temporary buffer needs
to be allocated, checked for successful allocation and copy over data. The
way it's currently done is technically correct, but unnecessarily complex to
understand: instead of just branching on whether there are elements and doing
all the buffer-related things only then, the branching is done just somewhere
in the middle, only on checking for allocation failure, and relying on both
calloc() and memcpy() not doing weird things when size is zero.
It's easy to simplify by putting it all behind one if statement and so make
things easier for both human reader as well as the analyzer (so it's not
spilling out false alarms here anymore) and also drops unnecessary calls
in the zero-size case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
1. We've got some ancient code here that's trying to open stderr (fd 2) itself,
in case it cannot write there for strange reason. POSIX defines the three
standard streams (and associated fd's) to be available on program startup
(when main() is reached). One needs a sledgehammer for breaking a system
so much that this doesn't work anymore - even calling a program directly
from /etc/inittab does provide them.
2. The current implementation is not POSIX conformant - it should use freopen(),
and it leaks FILE structure.
3. stderr is set to buffered mode, quite the opposite of POSIX - it states
stderr shall NOT be buffered. Simple and obvious reason: not risking vital
error information getting lost.
4. Placing The logfile in /usr/adm - an ancient, pre-FHS, directory that rarely
exists on modern systems. That's even hardcoded, instead of derived from
build-time given installation pathes.
Conculusio: obsolete and broken, thus removing it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only rarely used and can be easily achieved by generic means,
eg. via ulimit or supervisor settings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
calloc() can always fail, so we need to prepared for this,
instead of just blindly segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If this happens, we really have a bug, so better spit out a warning
instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Usually shouldn't happen trying to accessing pixmap's glamor private
data w/o having it initialized first. But just in case there's some
subtle bug, adding extra checks, which don't cost us much.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GetPictureScreenIfSet() is designed that NULL can be returned.
Even though it should not happen in this particular case,
better be prepared for that, instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It could potentially be called with NULL pointer, but can't handle it,
so when that happens, it's a bug. Adding a BUG_RETURN_VAL() call here,
so it's giving us a hint where to look at.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the cases might be hypothetical, it's still better having some
tiny extra checks (that might be even optimized-out) and reduce the analyzer
noise a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In the rare case that NULL kbd is passed and also no components provided,
the corresponding error message code crashes on NULL pointer dereference.
| ../xkb/ddxLoad.c: In function ‘XkbDDXLoadKeymapByNames’:
| ../xkb/ddxLoad.c:393:25: warning: dereference of NULL ‘keybd’ [CWE-476] [-Wanalyzer-null-dereference]
| 393 | keybd->name ? keybd->name : "(unnamed keyboard)");
| | ~~~~~^~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though shouldn't be practically hit, better have some asserts,
giving us an idea of the point of cause, instead of segfaulting,
just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Try to gracefully handle OOM situation, at not hard crashing.
| ../Xi/xibarriers.c: In function ‘add_master_func’:
| ../Xi/xibarriers.c:729:19: warning: dereference of NULL ‘pbd’ [CWE-476] [-Wanalyzer-null-dereference]
| 729 | pbd->deviceid = *deviceid;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect against `inputMasks` could be NULL.
| ../Xi/exevents.c: In function ‘DeviceEventSuppressForWindow’:
| ../Xi/exevents.c:3246:32: warning: dereference of NULL ‘inputMasks’ [CWE-476] [-Wanalyzer-null-dereference]
| 3246 | FreeResource(inputMasks->inputClients->resource, X11_RESTYPE_NONE);
| | ~~~~~~~~~~^~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not supposed to be called by drivers, just internal to the randr extsnsion,
so shouldn't have been exported in the first place.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not supposed to be called by any driver, just internal to the extension,
so shouldn't have been exported in the first place.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aren't used by any drivers and never should so, thus no need to
keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aren't used by any drivers and never should so, thus no need to
keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aren't used by any drivers and never should so, thus no need to
keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aren't used by any drivers and never should so, thus no need to
keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aren't used by any drivers and never should so, thus no need to
keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not called by anybody and been just a dummy for quite a while,
so no need to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, and subject to upcoming changes, so no need
to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A slight change in include order can cause Xlib to be included and defining
"GC" type, which is conflicting with Xserver's own type by same name.
As long as MR !1393 hasn't merged yet, we need to do an ugly workaround
using some preprocessor black magic.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It doesn't serve any practical purpose anymore and also isn't included
by any external driver, thus also no need to keep it in SDK.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protecting against NULL pointers and allocation failures.
Printing out a bug warning in those cases.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
FOR_NSCREENS() is just alias for FOR_NSCREENS_BACKWARD(). In many cases
it really matters that we're going backwards and the last iteration visited
the screen #0, and that one is panoramix-wrapped.
Thus directly calling FOR_NSCREENS_BACKWARD() here and dropping the alias.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's now only a wrapper calling xf86PostKeyEvent(), and no external driver
using it anymore, so we can drop it entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This never seemed to be actually enabled, just ifdef'ed out, so no
need to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any exteral drivers (and really should not be used by them),
so can be replaced by more fitting error messages.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
It's also so simple (and rarely called) that easily can be inlined.
Also unexport HWEventQueueType and HWEventQueuePtr, since they're
not used by any drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Just an internal resource destructor, not used by any external
drivers, so no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not needed by any drivers, so no need to keep it exported
* correct return type is `enum EventDeliveryState`
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it exported.
Also using XRetCode and marking paremters where NULL isn't allowed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not used by any drivers, so no need to keep it exported
* fix parameter types to matching the protocol types
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not used by any drivers, so no need to keep it exported
* fix parameter types to matching the protocol types
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it exported.
Also renamed to dixClientSignal(), since there's a conflicting prototype
in fontsproto.h.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The include has become empty now. Not used by any external drivers,
so it can be dropped now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, and not supposed to be used by them,
so no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, and not supposed to be used by them,
so no need to keep it in public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Callers are only interested in whether event was actually sent
(retval==1) or not, so Bool is sufficient and easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Callers are only interesed in whether event was actually sent
(retval==1) or not, so Bool is suffient and easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always called with just a single event, so no need for the count
parameter. Also renaming it in order to better fit it's new semantics.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, and only supposed to be DIX internal,
so shouldn't be exported at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not used by any external drivers, so no need to keep it exported
* choose better fitting name: InputDevGetSpriteCursor()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Request handlers aren't supposed to be called by external drivers directly,
so no need to keep them in the public SDK API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This type is should be used instead of plain int for all functions
returning and X error code (that's possibly sent to the client),
in order to make return value semantics clear to the humen reader.
(for the compiler, it still will be just an int)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a macro for specifying nonnull attributes, for easier future
transition to new C23 attributes or supporting strange compilers that
don't understand this attribute.
The purpose of using those attributes is aiding compiler warnings and
potential optimizations.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
2025-06-03 11:37:28 +02:00
213 changed files with 19678 additions and 1962 deletions
Please fill out the sections below to help everyone identify and fix the bug. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:dropdown
id:affected-version
attributes:
label:Select the version
options:
- 25.0.0.X
- Git master branch
- other or don't know
default:1
validations:
required:true
- type:textarea
id:description
attributes:
label:Describe your issue
placeholder:When I did X then Y happened.
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce
placeholder:|
1. Start ...
2. Do this
3. Do that
validations:
required:true
- type:textarea
id:expected
attributes:
label:What did you expect?
placeholder:I expected this to happen.
- type:textarea
id:environment
attributes:
label:Additional Information
description:Additional information you want to provide such as logs, system info, environment, screenshots, etc.
placeholder:|
Add any other context about the bug here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xserver/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for reporting this issue! We will get back to you as soon as possible.
Please fill out the sections below to properly describe the new software feature you are suggesting. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:"Describe the feature"
placeholder:A thing in X that allows to do Y.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be implemented because"
placeholder:Doing Y is needed for Z.
validations:
required:true
- type:textarea
id:alternative
attributes:
label:"What are the alternatives?"
placeholder:We could do A or B instead.
- type:textarea
id:context
attributes:
label:Additional context
description:Additional information you want to provide such as references to related issues or protocols, the implications on existing use cases, etc.
placeholder:|
Add any other context about the feature request here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xserver/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for your suggestion! Let's see together if it can be implemented.
Please fill out the sections below to properly describe the code cleanup you are suggesting. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:"Describe the cleanup"
placeholder:C in X needs to be changed into D.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be done because"
placeholder:Having D is needed for E.
validations:
required:true
- type:textarea
id:alternative
attributes:
label:"What are the alternatives?"
placeholder:We could do A or B instead.
- type:textarea
id:context
attributes:
label:Additional context
description:Additional information you want to provide such as implications on existing code, how to ensure API/ABI stability, which tests are needed or to be run, related issues, etc.
placeholder:|
Add any other context about the cleanup here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xserver/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for looking at the source code! Let's see together how it can be improved.
description:Make your mark for better documentation
labels:[documentation, needs-triage]
#type: docchange
body:
- type:markdown
attributes:
value:|
Please fill out the sections below to help others understand our software. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:Describe the update
placeholder:These things need to be better documented.
validations:
required:true
- type:textarea
id:environment
attributes:
label:Additional Information
description:Additional information you want to provide such as tickets related to changes in the software, affected files, screenshots, etc.
placeholder:|
Add any other context about the update here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xserver/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for requesting this update! We will get back to you as soon as possible.
description:Create a task for project organization
labels:[needs-triage, organization]
#type: task
body:
- type:markdown
attributes:
value:|
Please fill out the sections below to get organizational things done. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:Describe the task
placeholder:These things need to be done.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be done because"
placeholder:Doing Y is needed for Z.
- type:textarea
id:environment
attributes:
label:Additional Information
description:Additional information you want to provide such as the context for bigger tasks, the implicatons on existing workflows, related issues, etc.
placeholder:|
Add any other context about the task here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xserver/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for adding this task! We will get back to you as soon as possible.
Enrico Weigelt, metux IT consult
Thomas Debesse
catfromplan9
Felipe Contreras