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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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 destructor hook instead.
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>
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>
Enrico Weigelt, metux IT consult