This moves the loading of the rc.lua and managing of pre-existing clients to
after we ungrab the server during startup. To make sure we have no races with
clients which start up parallel to awesome, we do the QueryTree for all the
clients that we have to manage before the ungrab, but start managing the clients
only after the ungrab.
This means that we have already selected our event mask on the root window in
scan() and thus received an UnmapNotify event when we reparent windows into a
frame window. This has the effect that we immediately unmanage the client again,
whoops.
To fix this, we grab the server again and remove our event mask on the root
window again while we reparent.
This should hopefully fix all cases where we deadlock during startup because
pulseaudio wants to talk to the X server, but is being ignored because we have
the server grabbed while at the same time we are waiting for pulseaudio.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This option is no longer valid in modelines, so it has been removed from
all modelines using the following shellscript:
#!/bin/ksh
git ls-tree -r HEAD | cut -f2 | while read f; do
egrep -e '^(//|--) vim: .*encoding=' $f >/dev/null || continue
sed -E -e '/^(\/\/|--) vim:/s/:encoding=utf-8//' $f > /tmp/foo
mv /tmp/foo $f
done
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
xcb-util is now split into several repositories since 0.3.8. This
release also cleaned up the API a lot, thus update the code
accordingly.
Signed-off-by: Arnaud Fontaine <arnau@debian.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
awesome.c contains this comment:
There can be no events yet, so if his function returns something, it must be
an error.
Sadly, this wasn't true. It seems like something managed to generate
MappingNotify events (no idea how).
Fix this by discarding all pending events after our GrabServer, but before we
ask for SubstructureRedirect on the root window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some time ago I added a --no-argb option with the short-hand version -a.
However, the short version didn't actually work. Whoops!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the X connection breaks for whatever reason, awesome wouldn't properly
exit, but go into a busy loop instead. Fix this by dying when our connection to
the X server dies.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Seems like there are enough bugs in the X server that one can't really use a 32
bit visual. Looks of repaint errors. :(
This should somehow be fixed properly before release. For now, this just swaps
the default behavior and the "--no-argb" behavior.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For performance reasons, we only handle the last motion notify we receive.
However, we must make sure that the motion isn't moved after enter or leave
notifies. Else, breakage is ensured!
Signed-off-by: Uli Schlachter <psychon@znc.in>
If awesome is started with that flag, it won't use ARGB visuals. Theoretically,
this shouldn't be necessary, but it seems like this triggers bugs in the X
server. (Or is it just my server that doesn't like me?)
Signed-off-by: Uli Schlachter <psychon@znc.in>
We don't have any window with globalconf.depth yet at this point, so we have to
create one just for setting up our GC.
Signed-off-by: Uli Schlachter <psychon@znc.in>
With this commit, awesome prefers ARGB visuals over the screen's default visual.
This means that all our (visible) windows now can get an alpha channel that a
compositing manager can use for producing transparent windows.
The reason why this is done is to fix a bug. We are reparenting clients into
other windows. If one of these client window uses an ARGB visual, its
transparency would have no effect.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The window that is specified when a GC is created is used for two things. First,
it specifies which protocol screen the GC should be associated with. Second, it
specifies for which color depth the GC is valid.
Due to this second property, we have to use the systray window instead of the
root window. The systray window uses globalconf.default_depth.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes awesome support only a single X11 protocol screen. If you are still
using zaphod mode, you can run multiple instances of awesome on the single
screens, e.g.:
DISPLAY=:1.0 awesome & DISPLAY=:1.1 awesome &
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves the setting of the event mask after scan() so that we won't receive
any events from scan()'s activity (especially no UnmapNotifies which would cause
us to lose clients).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Upstream removed most of the code from libxcb-event and there is no
event-related stuff left in this library. We now no longer use any of the parts
that were removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes awesome prefetch some of the data it needs during startup to avoid
some useless round-trips to the server.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since the last commit, systray windows will automatically be reparented by the
X11 server. This means we no longer have to do this ourselves.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A window is unmapped if it is not mapped (oh noes! ;). If it is mapped, it can
be either mapped or unviewable. If any of its ancestors is unmapped, it's
unviewable, else it's unmapped
Since this code looks at children of the root window, it should never be seeing
clients which are unviewable (can one unmap the root window at all...?). What
this really wants to check for is unmapped, so this patch implements this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Else stuff like this can happen:
Invalid read of size 4:
at 0x300280BB7F: (within /usr/lib/libxcb.so.1.1.0)
by 0x300280BD21: xcb_get_extension_data (in /usr/lib/libxcb.so.1.1.0)
by 0x300280A55A: xcb_send_request (in /usr/lib/libxcb.so.1.1.0)
by 0x300C604A4F: xcb_render_free_picture (in /usr/lib/libxcb-render.so.0.0.0)
by 0x300B24C4BB: (within /usr/lib/libcairo.so.2.10800.8)
by 0x300B22F1B6: cairo_surface_finish (in /usr/lib/libcairo.so.2.10800.8)
by 0x300B22F234: cairo_surface_destroy (in /usr/lib/libcairo.so.2.10800.8)
by 0x300B218124: (within /usr/lib/libcairo.so.2.10800.8)
by 0x300B212750: cairo_destroy (in /usr/lib/libcairo.so.2.10800.8)
by 0x42E4D0: wibox_wipe (draw.h:110)
by 0x42E568: luaA_wibox_gc (wibox.c:46)
by 0x3008E0CB15: (within /usr/lib/liblua5.1.so.0.0.0)
Address 0x4e56ec0 is 20,928 bytes inside a block of size 20,992 free'd
at 0x4A0761F: free (vg_replace_malloc.c:323)
by 0x40F974: awesome_atexit (awesome.c:97)
by 0x410316: main (awesome.c:577)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>