Now that all individual swapping request handlers have been merged into the
actual ones, there's no need for a separate dispatcher anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(The existing setting of led_mask is probably wrong, but has been set
like this since X11R5 and going back as far as the first version in
the X Consortium source control archives.)
Reported in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1817:
xwayland-24.1.6/redhat-linux-build/../Xi/getfctl.c:108:9:
warning[-Wanalyzer-use-of-uninitialized-value]:
use of uninitialized value ‘*k2.led_values’
108|-> swapl(&k2->led_values);
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2075>
The wOtherInputMasks(win) macro will return NULL if
win->optional is NULL.
Reported in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1817:
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1390:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1404:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:2293:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3244:22:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3338:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2075>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
iterating over screen list via lambda-esque macros calls like this
DIX_FOR_EACH_SCREEN({
do_something
});
withing the body, the iterator variables `walkScreenIdx` and `walkScreen`
are defined and can be directly used (read-only). the code inside the body
is running in a separate scope.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
CoreEnterLeaveEvent calls FixUpEventFromWindow with a pointer to a stack-allocated xEvent structure, which may get later casted into an xXIDeviceEvent*, with writes done by FixUpXI2DeviceEventFromWindow at an offset larger than sizeof(xEvent). This code-path is protected by xi2_get_type() but the following warning is generated by building with -O3 and LTO:
In function 'FixUpXI2DeviceEventFromWindow',
inlined from 'FixUpEventFromWindow' at ../dix/events.c:2716:13,
inlined from 'CoreEnterLeaveEvent' at ../dix/events.c:4679:5:
../dix/events.c:2628:48: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2628 | ((xXIEnterEvent *) event)->same_screen =
| ^
../dix/events.c: In function 'CoreEnterLeaveEvent':
../dix/events.c:4652:12: note: at offset 48 into destination object 'event' of size 32
4652 | xEvent event = {
| ^
This PR suppresses this warning, by tracking the level of the event (ie., core event, XI or XI2) and ensuring that fix-up is performed only on XI2 events.
Signed-off-by: alex14fr <alex14fr@gmail.com>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, no no need to keep it in public SDK.
Since it's not used by drivers, it's effectively not an ABI change,
so can be done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move functions/macros dealing with request parsing or reply assembly/write
out of the big dix_priv.h into their own headers. This new header will also
get more of those function/macros soon (yet still in the pipeline).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This hook was never used, so no need to keep around something that's
really not used anywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Follow-up on renaming dixGetFirstScreenPtr() to dixGetMasterScreen():
also rename the target variables for correct technical terminology.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In Xinerama/Panoramix configuration there's one screen that's having special
meaning - it's used for simulating as the frontend for all client operations:
the clients (should) only talk to that screen, while panoramix subsystem is
proxying those operations to all the other screens (with certain changed
applied, eg. coordinate transformations).
Historically, this screen happens to be the first one in the system (some of
it's proc's are hooked up in order to achieve desired behaviour). That's why it
used to be accessed via screenInfo.screens[0] - that already had been encapsulated
into a tiny helper `dixGetFirstScreen()`.
a) the correct terminus technicus for a situation where one device (or SW entity)
entirely controlling others is a master-slave-relationship: the controlling
device/entity is `master`, the controlled ones are `slave` (to that specific
master).
b) the term "first screen" is inacurate and misleading here: what the caller's are
actually interest in isn't the first entry in the screen array, but the screen
that's controlling the others. With upcoming refactoring of the Xinerama/Panoramix
subsystem, this might well be a different array index than 0.
c) the term `default` also wouldn't match: `default` implies there's a real practical
choice, and such value applies when no explicit choice has been made. But in this
case, it practically doesn't make sense (except perhaps for debugging purpose)
for a client to use any different screen.
Therefore fixing the function name to the correct technical terminology.
(for sake of patch readability, renaming corresponding variables is left to
subsequent patches).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of having huge number of micro-headers, consolidate all the
request handler prototypes in one file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of everybody directly accessing the (internal) screenInfo struct,
let those consumers only interested in first screen use a little helper.
Also caching the value if it's needed several times.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
