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>
Before this, awesome_refresh() could be called multiple times per mainloop and
one had to make sure to add awesome_refresh() calls in the right places.
Now, the prepare handler is invoked just before libev puts the process to sleep
(e.g. by calling select()) and awesome_refresh() does its thing.
All redundant calls to awesome_refresh() are removed, but the one in
selection.c has to stay because this function blocks in xcb_wait_for_event()
without using libev.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Chris Newton
Uli Schlachter
Julien Danjou
Brian Gianforcaro
Arnaud Fontaine