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 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>
Fix various pieces of debug output, mainly under --enable-debug, which use a
"%08x" printf format for a pointer type. Use "%p" format for 64-bit portability.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
We need to include xwin-config.h into winmsgwindow.c, so that _XSERVER64 is
defined, so that the layout of ScreenRec type is correct, so that it's privates
can be accessed correctly, so that the WM_GIVEUP message can be sent to the
screen window.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Currently, WM_ENDSESSION just calls GiveUp() to set the DE_TERMINATE flag. But
for the X server to exit cleanly, we also need the X server dispatch loop to be
unblocked so it can notice that DE_TERMINATE has been set and exit, removing
it's lock file and any unix domain socket.
It appears that the system will terminate the process when the last UI thread in
that process returns from processing WM_ENDSESSION for the last top-level
window.
Since WM_ENDSESSION appears to sent by the system via SendMessage()
(synchronously) and the wndproc is called to process it in the message thread
for that window (the X server thread), we can't easily terminate the X server
dispatch loop from inside the WM_ENDSESSION message processing.
So, create a messaging window, a hidden, top-level window, with a separate
thread to catch this message, and process it by calling GiveUp() and then
blocking on a mutex until the X server dispatch loop exits.
Also, notice when this is a shutdown cancel WM_ENDSESSION message and take no
action.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
