When a screen is in the process of being removed, it is still valid, but
no longer in the global list of screens (globalconf.screens). In this
time frame, trying to swap screens could cause a NULL pointer
dereference.
Fix this by throwing a Lua error in this case instead.
Fixes: https://github.com/awesomeWM/awesome/issues/2110
Signed-off-by: Uli Schlachter <psychon@znc.in>
The screen object can be indexed by strings to find a screen via some
RANDR output name. However, if a string is used which does not
correspond to a known output, the code just falls through to a function
which will complain "string provided, userdata expected".
This commit provides a slightly more useful error message instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function tried to move the client to its new screen based on
shifting around its current geometry. However, it assumed that the
client was actually visible on its current screen, which is not always
the case.
Fix this by just forcing the client into its new screen if our moving
approach does not work.
This also reverts commit d5e365804c which
is no longer necessary. This commit only hid the issue (partly).
Fixes: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here made sure that clients were not moved outside of the root
window. However, that's not enough, because clients can still end up
inside the root window, but outside of anything that is visible in some
output. Thus, just remove this.
Related-to: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
Aborting the process is sometimes a bit harsh for a failed assertion.
This adds a non-fatal assert() macro called "check()" and uses it in
some places where we might be able to survive the error.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without RandR telling us what the primary screen is, we just pick the
first one. However, the code here did not emit the right signal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We have many places where we are sending an XCB request and expect an
answer where the protocol guarantees that no error can occur and we are
sure to get an answer. However, for example if the X11 server crashes,
these places can still fail. This commit tries to handle failures at all
these places.
I went through the code and tried to add missing error checking (well,
NULL-pointer-checking) to all affected places.
In most cases these errors are just silently ignored. The exception is
in screen querying during startup. If, for example, querying RandR info
fails, we will fall back to Xinerama or zaphod mode. This is serious
enough that it warrants a warning. In most cases, we should exit shortly
afterwards anyway, because, as explained above, these requests should
only fail when our connection to the X11 server breaks.
References: https://github.com/awesomeWM/awesome/issues/1205#issuecomment-265869874
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similarly to what we do with the client list, this signal is emitted
whenever the list of screens changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a tparam alias "@screen" for "@tparam screen" (when used to
document e.g. arguments for callbacks), and "@screen_or_idx" when a
function accepts a "screen" or "number".
Why:
* Two different (but related) concepts had the same name
* Users were confused for years on IRC
* The wibar name was already in use in some doc to avoid confusion
Commit 8a6787bd54 added screen.fake_add(). Commit 08845c7a4b made us cache a
screen's workarea in the struct screen_t. This new member needs to be
initialized to the screen's geometry when a new screen is added. Since both
these commits were developed concurrently, the workarea was not initialized in
screen.fake_add().
Fix this by calling in fake_add() the helper function added in 08845c7a4b.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of computing the workarea whenever some Lua code asks for it, it is now
remembered explicitly as a property on a screen. This allows us to only emit
property::workarea if the workarea actually changed.
Fixes: https://github.com/awesomeWM/awesome/issues/756
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a screen is removed, we have to update screen.primary (if it was the
removed screen) and assign a different screen to all clients which were on the
removed screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A client cannot be used any more after it was unmanaged. Similarly, Lua
shouldn't be allowed to e.g. assign a client to a screen that was removed. This
commit adds such a checker which "breaks" all screens which are not in the
global screen list.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a "removed" signal to screens. Together with the "added" signal
that we have since a while, this allows the C code to update the list of
available screens dynamically without needing to restart.
So far, this code received only minimal testing. So far, I don't have a nice
idea on how to easily test this...
Closes: https://github.com/awesomeWM/awesome/issues/672
Signed-off-by: Uli Schlachter <psychon@znc.in>
We once had the problem that with the nvidia blob, the X11 server told us that
"yes, I do support RandR; there is just a single big screen" even though there
were multiple screens and they could be queried for via Xinerama. To work around
this, we started to ignore RandR if it only provided information about a single
screen.
Our long-term goal is to stop restarting on RandR screen changes. Thus, even if
only a single screen is defined during startup, we should still use RandR later
when another screen is added. This means that we cannot just ignore RandR if it
only mentions a single screen.
This commit copies what GTK+ does: If there is an output named "default", then
some compatibility layer is assumed and we ignore RandR.
I have no way to test if this really does the right thing.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of adding all screens directly to globalconf.screens, the individual
"scanner functions" now get a screen_array_t as their argument and add the
screens there. Also, they no longer emit the "added" signal themselves (through
screen_add()), but the caller does now does this instead once all screens are
found.
This commit drops the "deduplication" of screens. This likely means that clone
mode causes duplicate screens. This will have to be re-added later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit c543f59696 introduced the following warnings:
objects/screen.c:307:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
objects/screen.c:307:1: warning: no previous prototype for ‘screen_scan_randr_monitors’ [-Wmissing-prototypes]
Signed-off-by: Uli Schlachter <psychon@znc.in>
XRandR 1.5 adds support for the new monitor objects.
'Monitor' is a rectangular subset of the screen which represents a
coherent collection of pixels presented to the user. Each Monitor is be
associated with a list of outputs (which may be empty).
The patch below matches 1:1 screens in AwesomeWM with XRandR's Monitors.
This way I get one screen across my 4K monitor, which is represented by
two CRTCs.
Background info: http://keithp.com/blogs/MST-monitors/
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Uli Schlachter
Uli Schlachter
Holger Schurig
Emmanuel Lepage Vallee
Daniel Hahler
blueusername
Kirill A. Shutemov
Daniel Hahler