Since commit 531f8b415c, we are using Xlib for our X11 connection. However,
we still use XCB for event processing. This means we actually have to tell Xlib
to leave all events alone.
This might fix FS#1047. Perhaps.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I hope this time i got all right with git format-patch.
Signed-off-by: Tumin Alexander <iamtakingiteasy@eientei.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
My intel driver no longer is broken with ARGB visuals, so let's enable this by
default again. Let's see how long it takes for someone else to hit a broken
driver and complain. :-)
This reverts commit c7da695e10.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If loading of any config file fails, awesome will now remember the error message
and make it available to lua. The default config is modified to open a naughty
popup on errors.
This should help all those people who modify their config and then wonder why
there change is ignored, not noticing awesome's error message on stderr.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Uli Schlachter
Tumin Alexander
Gregor Best
Arnaud Fontaine
Chris Newton
Julien Danjou