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>
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>
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>
Enrico Weigelt, metux IT consult