Between xcb_grab_server() and xcb_ungrab_server(), XCB's output buffer
might fill up. Thus, the GrabServer request might already have been sent
to the server, but the following UngrabServer request could end up in
XCB's output buffer. There, it might sit around for quite a while and
cause problems.
Since we cannot detect when XCB's output buffer fills up, we just always
flush after generating an UngrabServer request.
Very-likely-Fixes: https://github.com/awesomeWM/awesome/issues/2697
Signed-off-by: Uli Schlachter <psychon@znc.in>
GLib has an internal pseudo-RNG that it initialises from /dev/urandom.
This commit adds code that uses this RNG to initialise various random
number generators that can be used by Lua.
This also removes some Lua code that initialises the random number
generator badly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When poll() is interrupted because of a signal, it sets errno to EINTR.
GLib ignores this kind of failure.
However, a_glib_poll() calls a_xcb_check() at its end. This will call
xcb_poll_for_event() which internally might call recv(), which can fail
with EAGAIN if no new events are available. Thus, a_glib_poll() will
return an error and set errno to EAGAIN. This leads to the following
error message being printed by GLib:
GLib-WARNING: poll(2) failed due to: Resource temporarily unavailable.
Fix this by preserving the errno from g_poll() in a_glib_poll().
Signed-off-by: Uli Schlachter <psychon@znc.in>
GLib is very careful not to "fetch" any children that it was not asked
to fetch. Thus, if awesome inherits some children, it does not reap them
and starts collecting zombies.
Thus, this commit makes awesome handle SIGCHLD directly: On SIGCHLD, a
byte is written to a pipe. The main loop reads from this pipe and
collects children via waitpid(-1). Unknown children cause a warning to
be printed. We might want to remove this warning if it turns out to be
annoying.
This commit adds 79 lines and removes 89 lines. Thus, this is a net
reduction in lines of codes. This is because previously, we gave the
list of still-running children that we know about to the next awesome
instance we a --reap command line argument. This was added so that
awesome does not get zombie children. However, this commit fixes this
problem and makes all the code for this 'feature' unnecessary.
Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886393
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, running "env -i ./awesome" resulted in a segfault. This was
because xdgInitHandle() failed and the following
xdgSearchableConfigDirectories() followed a NULL pointer.
After this commit, awesome fails with an error message.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit e54361a374 added code so that we pass the list of
currently running children across restart via an environment variable.
As Colin Walters correctly points out, setenv() is not safe in a
multi-threaded processes.
Thus, instead of using the environment, use the command line to pass
this information along.
https://github.com/awesomeWM/awesome/issues/1812
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, we used a_exec() with started a shell and used it to parse
our glued-together command line. That only asks for escaping trouble
(think: Path to the config file is given on the command line and
contains a space), so use execvp() directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In Unix, so that a process can learn about the exit status of the child
processes that it started, children become zombie processes until the
parents collects their exit information. We use glib both for starting
and for collecting processes. However, when awesome is restarted, the
new instance inherits children, but does not know about them and does
not inherit them.
Fix this by explicitly tracking a list of running child processes and by
serialising them across a restart via an environment variable. The new
awesome instance can then watch for these child processes, but besides
that it ignores them and does not use their exit status in any way.
Thanks to Colin Walters for the hint with serialising the list of processes.
Fixes: https://github.com/awesomeWM/awesome/issues/1193
Signed-off-by: Uli Schlachter <psychon@znc.in>
XCB_CURRENT_TIME really should be avoided as much as possible (see
ICCCM).
However, the screen, mousegrabber and keygrabber code have cases where
they really want up-to-date information / want to activate a grab *now*.
These cases are fine with XCB_CURRENT_TIME since they are not related to
some events.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are lots of places where ICCCM says that using CurrentTime for a
timestamp is wrong. So, instead of having globalconf.timestamp
initialized to CurrentTime, initialize it with a proper timestamp.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves Lua initialisation to the latest possible point, just before
loading the configuration file. This requires to also move screen
initialisation and parts of EWMH initialisation to a later point.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, there was a function which attempted to load different
configuration files in the right order. There was a boolean argument
that decided if we are actually loading it or just checking for syntax
error (for the --check argument of awesome). This lead to some
not-so-nice code since we do not want to fall-back to another config
when checking for syntax errors.
Refactor this so that there is now a function which calls a callback
function with the different paths that should be tried. This function
returns as soon as the callback function returns true.
Since just checking if the config syntax is ok does not depend on any
Lua state, an empty Lua state is now used for this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It makes more sense to append the xdg config dirs to our list of
searchpath in awesome.c than in luaa.c. Plus, it simplifies some of the
following work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the child process in tests/_client.lua breaks and exits (for
example: Remove the call to Gtk.main), we get a broken pipe. When trying
to write to the pipe that connects awesome to the child process, we get
a SIGPIPE signal that causes awesome to exit without any good error
message.
Fix this by ignoring SIGPIPE. We do not want to be killed by it anyway.
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>
Instead of using Xlib for parsing resource files, this now uses the
dedicated xcb-based library that is meant for exactly this task.
Fixes: https://github.com/awesomeWM/awesome/issues/1176
Signed-off-by: Uli Schlachter <psychon@znc.in>
At the beginning of every main loop iteration, we check for new events
from the X11 server. However, it's theoretically possible that during a
main loop iteration new events arrive and are read by libxcb into its
internal buffer. This would mean that the fd connected to the X11 server
is not readable and thus we do not wake up to handle these events.
Handle this by checking for pending events before calling poll(). If a
new events appears, we set the timeout for poll() to zero and will then
handle the new event in the following iteration of the main loop.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Otherwise there is a small, unimportant memory leak. More important is the fact
that later such flags overwrite earlier flags.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This code removes code which could only be hit be running awesome --search '' or
awesome -c ''. In both cases there are many possibilities for weird/invalid
arguments and I don't see why the empty string deserves special treatment.
Note that awesome --search does NOT hit this code, because getopt_long handles
the case of "completely missing" arguments itself.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When you run "awesome --foobar", a warning will be printed (by getopt_long())
and awesome just ignores the invalid argument. That's unusual and weird.
This commit produces an error instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The same effect could be achieved by modifying $LUA_PATH or with symlinks, but
having a special option to do this seems easier.
Note that the man page translations were generated via Google translate. I'm
looking forward to people submitting correct translations...
Inspired-by: https://github.com/awesomeWM/awesome/pull/485
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function needs the event numbers for events from some extensions. These are
assigned dynamically by the server. Right now, this is done by having a bunch of
static variables that are initialized when needed.
Refactor this to have a function event_init() instead that sets variable in
globalconf (where all of our state should be saved). Also, a preprocessor macro
is introduced to handle event dispatch which also looks a bit nicer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit e6037b4738. It causes many
issues with non-trivial solutions that we first need to come up with. As a
middle ground, we will for now only emit signals if something changes after the
config is loaded.
See https://github.com/awesomeWM/awesome/issues/799.
Instead of querying the wallpaper every time that root.wallpaper() is called, we
just remember it in globalconf.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This gives us the worst of both worlds: We still restart on RandR screen changes
and the information about screens isn't available during startup. However, it's
a step in the right direction, because all Lua code will now have to handle
kind-of-dynamic screen changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The Lua stack is a finite resource and everything that pushes something there
should also clean up. This is not a problem for functions that are called by
Lua, because their "stack frame" is freed when they return. However, in global
context, Lua does not and cannot automatically clean up for us. Thus, it makes
sense to print a warning in this case.
(Additionally, this cleans up the stack if something is left)
Signed-off-by: Uli Schlachter <psychon@znc.in>
These fields were only ever written to since commit 19137a55c3.
This commit removes the fields and the code that sets them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
_NET_WM_ICON contains a list of icons and until now, the first one was
picked without regard to it's size. This adds a global option to set
the preferred icon size. When getting the client icon, the best size
match is picked. The size can be set via
awesome.set_preferred_icon_size() and the default is 0, which will pick
the smallest non-zero size icon available.
Signed-off-by: Lukáš Hrázký <lukkash@email.cz>
The only exception is the window for _NET_SUPPORTING_WM_CHECK. That window
already had a _NET_WM_NAME property before and doesn't get a WM_NAME property in
this commit. I just decided for myself that it doesn't need one. :-)
Right after startup with the default config we now have the following situation:
$ xwininfo -root -tree
xwininfo: Window id: 0x2d7 (the root window) (has no name)
Root window id: 0x2d7 (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200011 "Awesome drawin": ("awesome" "awesome") 1500x20+0+0 +0+0
0x200010 "Awesome drawin": ("awesome" "awesome") 1x1+0+0 +0+0
0x20000d "Awesome drawin": ("awesome" "awesome") 100x30+0+0 +0+0
0x20000a "Awesome no input window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200009 "Awesome systray window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200008 "awesome": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200007 "Awesome WM_Sn selection owner window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
One of those drawin is the awful.wibox. Another drawin is created by awful.menu.
I guess that the third one is created by awful.tooltip, but I'm not sure. Wow,
so many windows...
Closes https://github.com/awesomeWM/awesome/pull/556.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds it to the output of "awesome -h" and translates the version in the man
page to italian. Thanks, eri_trabiccolo for the translation!
Signed-off-by: Uli Schlachter <psychon@znc.in>
Whenever client.focus == nil, we set the input focus to the root window to
express "nothing has the input focus". However, thanks to the way X11 input
works, this means that whatever is under the mouse cursor gets keyboard input
events. This can easily be reproduced with urxvt and some small addition to the
config to unfocus things.
This commit changes things. Instead of focusing the root window, we create a
special "no focus" window that gets focused if we want nothing to have the
focus.
Closes https://github.com/awesomeWM/awesome/pull/470.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not only useful for soft restarts, but also when TERMinating
awesome during development/testing.
The drawback appears to be that it would leak a property on the root
window in case it is really meant to be quit.
Closes https://github.com/awesomeWM/awesome/pull/374.
This saves the order of clients in a property called AWESOME_CLIENT_ORDER on the
root window during shutdown. During startup, after managing all existing
windows, we force the client list into the order described by this property
(overwriting any changes that Lua possibly did).
This code should safely handle cases where the property doesn't contain all
existing clients or contains a client which doesn't exist anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
