We can't free driverNames[i], because it's part of abi,
and other drivers might give us statically-allocated strings.
Fixes: #1848
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Allow the parseLine() function to use tabs alongside spaces to separate
tokens. Without this patch, using tabs in the config file actually
confuses the parser and makes it think that the tab is part of the
option's name.
Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
The previous comment made no sense. Add a proper comment to document the
function instead.
Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
Instead of abusing resource types, use the standard devPrivate
mechanism for assigning auxillary data to windows.
Signed-off-by: squishypinkelephant <squishypinkelephant@gmail.com>
This is needed to get proton working in Xfbdev, but is probably useful in other places too.
Xephyr has some unrelated issues regaring Xinput, so steam doesn't work there.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
osdep.h holds the definition for OsSignal, and it was not included in
xf86bigfont which used it. This lead to build errors on Cygwin.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
Brought back the code removed in that commit so that we can bring back
Cygwin support.
Small changes are done in the process of resolving conflicts against the
current head.
Some checks have not been reverted, because they were not necessary
anymore.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
Nothing in there that we need, include <regionstr.h> instead.
But keeping the file in place, until all external consumer have
been migrated.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Xvmc isn't using SHM for over 20 years now. There's still a code path for it
that could be enabled explicitly by manually setting HAS_XVMCSHM, but no
indication whatsoever that this ever has been done.
Considering that Xvmc in general already is obsolete for very long time now,
we can safely assume this code path is really dead and can be removed.
Fixes: 9a26d6f39e
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that we have untwisted Xinerama side, it's trivial to inline
the few lines for byte-swapping into the actual handlers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only internally within OS layer and screen saver logic,
so no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of internally faking requests, factor out the actual logic
into separate function, which is getting everything it needs as
parameters, so no need to fiddle with request buffer anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of directly accessing the global screenInfo.screens[] array,
let everybody go through a little inline helper. This one also checks
for array bounds - if the screen doesn't exist, return NULL.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In order to reduce complexity of wrapped core request handlers with PanoramiX,
split the ProcCreateWindow() function into two pieces: the upper half is the
usual (non-PanoramiX) handler, while the lower one is what's called by both
the usual handler, as well as the PanoramiX' one.
We're already passing in the request parameters as separate pointers, so
follow-up commits can easily change PanoramiX handler to not tweaking the
request buffer directly anymore. Another one is letting PanoramiXCreateWindow()
be called by ProcCreateWindow explicitly (when enabled), so we don't need to
wrap the core request proc vector anymore. Once that's done, the swapping can
also be moved into ProcCreateWindow().
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>
Only used inside shm.c, not anywhere else, so no need to keep it
in a public header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since it's now doing nothing more than unhooking itself, we really
don't need it anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
