mirror of
https://github.com/X11Libre/xserver.git
synced 2026-03-24 01:34:11 +00:00
b0ffa7b286
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>