If an output is disabled during a restart, for example because a binding
such as
bindsym $mod+Shift+r exec "xrandr --auto", restart
is used, it can happen that we first write the layout to disk and only
then receive the RandR change events. This leads to a situation where
the restored tree will contain these outputs, but the restarted i3
process will not receive the RandR events, thus the internal output in i3
is marked disabled.
This patch finds these cases after a restart and force-disables the
affected outputs.
fixes#2326
pledges for i3:
"stdio rpath unix" for talking to the i3 socket usually in /tmp
"proc exec" for executing programs
"wpath cpath" are needed for the restart-in-place functionality
To make this work, @semarie pointed out that it is sufficient to ensure
that we get physical_mem_bytes only once, namely in init_logging().
pledges for i3-msg:
"stdio rpath unix" are needed for talking to the i3-socket
pledges for i3-nagbar
"rpath getpw" to find the home directory
"wpath cpath" to write the script
"proc exec" to execute the script
With this patch, we use 32-bit visuals per default whenever it is
available. Otherwise, we fall back to the actual root window's
depth, which will typically be 24-bit.
Before this patch, we already used 32-bit depth for containers with
a window that uses 32-bit. However, this means that we didn't use
32-bit for split parent containers on which decoration is drawn.
For 32-bit windows using transparency, this caused a graphical glitch
because the decoration pixmap behind it would show through. This
behavior is fixed with this change.
relates to #1278
This patch migrates all decoration rendering of i3 to cairo. Using the
compile switch CAIRO_SUPPORT, rendering can be switched back to the
previous XCB behavior, just like with the previous migration to cairo
in i3bar.
This patch also fixes a bug in draw_util.c where copying one surface
to another would use incorrect coordinates if the source coordinates
are not 0, 0.
Furthermore, this patch implicitly fixes some minor issues in the
decoration rendering which would be ignored previously due to the fact
that errors would only show up in the event queue, but not cause the
rendering code path to crash. One example is zero-height pixmaps which
are not allowed. Using cairo, these would cause i3 to instantly segfault,
so this patch avoids this.
Lastly, this patch annotates other issues found but not fixed in this patch
using TODO comments, e.g., the zero-height check not working correctly
and the comment that it should probably work the same way for zero-width
pixmaps.
relates to #1278
As there is no need to keep autostart commands in memory, we can safely
remove them as soon as they have been executed. As we previously didn't
clear them at all during config reloads, this also fixes a memory leak.
Note that neither autostarts nor autostarts_always is executed during
config reloads, so removing them from memory is fine as an i3 restart
will cause them to be parsed again.
fixes#2044
fixes#1835
This commit improves the translation of keysyms to keycodes by loading
keymaps using libxkbcommon-x11 and using libxkbcommon for figuring out
the keymap, depending on each keybinding’s modifiers. This way, the
upper layers of complex layouts are now usable with i3’s bindsym
directive, such as de_neo’s layer 3 and higher.
Furthermore, the commit generalizes the handling of different XKB
groups. We formerly had support only for two separate groups, the
default group 1, and group 2. While Mode_switch is only one way to
switch to group 2, we called the binding option Mode_switch. With this
commit, the new names Group1, Group2 (an alias for Mode_switch), Group3
and Group4 are introduced for configuring bindings. This is only useful
for advanced keyboard layouts, such as people loading two keyboard
layouts and switching between them (us, ru seems to be a popular
combination).
When grabbing keys, one can only specify the modifier mask, but not an
XKB state mask (or value), so we still dynamically unbind and re-bind
keys whenever the XKB group changes.
The commit was manually tested using the following i3 config:
bindsym Group4+n nop heya from group 4
bindsym Group3+n nop heya from group 3
bindsym Group2+n nop heya from group 2
bindsym n nop heya
bindsym shift+N nop explicit shift binding
bindsym shift+r nop implicit shift binding
bindcode Group2+38 nop fallback overwritten in group 2 only
bindcode 38 nop fallback
…with the following layout:
setxkbmap -layout "us,ua,ru,de" -variant ",winkeys,,neo" \
-option "grp:shift_caps_toggle,grp_led:scroll" \
-model pc104 -rules evdev
By default (xkb group 1, us layout), pressing “n” will result in the
“heya” message appearing. Pressing “a” will result in the “fallback”
message appearing. “j” is not triggered.
By pressing Shift+CapsLock you switch to the next group (xkb group 2, ua
layout). Pressing “a” will result in the “fallback overwritten in group
2 only” message, pressing “n” will still result in “heya”. “j” is not
triggered.
In the next group (xkb group 3, ru layout), pressing “a” will result in
the “fallback” message again, pressing “n” will result in “heya”,
“j” is not triggered.
In the last group (xkb group 4, de_neo layout), pressing “a” will still
result in “fallback”, pressing “n” will result in “heya”, pressing “j”
will result in “heya from group 4”.
Pressing shift+n results in “explicit shift binding”, pressing shift+r
results in “implicit shift binding”. This ensures that keysym
translation falls back to looking at non-shift keys (“r” can be used
instead of ”R”) and that the order of keybindings doesn’t play a role
(“bindsym n” does not override “bindsym shift+n”, even though it’s
specified earlier in the config).
The fallback behavior ensures use-cases such as ticket #1775 are still
covered.
Only binding keys when the X server is in the corresponding XKB group
ensures use-cases such as ticket #585 are still covered.
Outputs may disappear momentarily and come back later.
To prevent i3 from exit when no output is available momentarily, add a timeout delay_exit_on_zero_displays.
Not quite sure why there are so many differences. Perhaps we’ve gotten
out of the habit of running clang-format after every change.
I guess it’d be best to have a travis hook that runs clang-format for us
and reports any problems on pull requests.
We're going to call parse_configuration() very early if -C is given on
the command line. Instead of the previous "only_check_config", which has
been a global variable, we now simply pass use_nagbar as false if we're
just validating.
This causes the whole parsing to run without X and of course without
starting nagbar and displaying the errors to standard out/error instead.
The return code of parse_configuration() is now a boolean which
represents whether an error occured during parsing and the programs exit
code is returned accordingly.
Although the config parser still has a lot of side-effects, we now can
parse without the need to have an XCB connection. A nicer implementation
would be to just set the new font and load it just after we're done
parsing, but to ensure we don't break functionality we just load a dummy
FONT_TYPE_NONE if XCB isn't available. The main reason for going this
route is that it's a bit difficult to test fonts in a distribution
agnostic way without bundling fonts with i3 (or Xdummy to be more
exact).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Maintain the _NET_DESKTOP_NAMES property on the root window.
http://standards.freedesktop.org/wm-spec/latest/ar01s03.html#idm140251368131760
> _NET_DESKTOP_NAMES
>
> _NET_DESKTOP_NAMES, UTF8_STRING[]
>
> The names of all virtual desktops. This is a list of NULL-terminated
> strings in UTF-8 encoding [UTF8]. This property MAY be changed by a
> Pager or the Window Manager at any time.
This removes our last dependency on Xlib! :)
(Okay, an Xlib dependency still comes in through other libraries that we
link against, but it’s not us. Our code is simpler by this change and
uses one less connection to X11.)
_NET_NUMBER_OF_DESKTOPS:
> This property SHOULD be set and updated by the Window Manager to
> indicate the number of virtual desktops.
We interpret this property as the number of noninternal workspaces.
This should be the last commit that formats a big bunch of files. From
here on, whenever I merge patches, I’ll run clang-format like described
in the title.
This has multiple effects:
1) The i3 codebase is now consistently formatted. clang-format uncovered
plenty of places where inconsistent code made it into our code base.
2) When writing code, you don’t need to think or worry about our coding
style. Write it in yours, then run clang-format-3.5
3) When submitting patches, we don’t need to argue about coding style.
The basic idea is that we don’t want to care about _how_ we write the
code, but _what_ it does :). The coding style that we use is defined in
the .clang-format config file and is based on the google style, but
adapted in such a way that the number of modifications to the i3 code
base is minimal.
Calls ewmh_update_current_desktop on startup to set the
_NET_CURRENT_DESKTOP property. Without this change the property only
gets set after the workspaces have been manipulated. Also exclude
hidden workspaces (i.e. those starting with "__" from the workspace
index.
Adds tests for startup and workspace switching.
This is done by installing a new check watcher that replaces the main
X11 event handler and calling ev_run with EVRUN_ONCE until the dragging
loop left state DRAGGING.
With this commit, other handlers, most notably the redraw handler for
placeholder windows, get a chance to run when dragging (placeholder!)
windows around.
Since the macro PATH_MAX is not defined on every system (GNU/Hurd being
one of those who do not define it), we remove all references to this
macro. Instead, we use a buffer of arbitraty size and grow it when
needed to contain paths.
The commit title is fairly technical, so I’ll try to explain.
Recently, users of GDM3 (I’m sure) and LightDM (I think) have reported
that when switching to a new workspace, the contents of the previous
workspace are still visible. i3bar updates, though, so it is the X11
root window which is not being updated here.
When using GDM3, X11 will be started with -background none, and no
background pixmap or pixel is set. Then, apparently,
gnome-settings-daemon will display a fade animation from whatever is
currently on the window to the destination contents. I think this is to
avoid flickering when logging in, which would occur when just setting a
specific background pixmap or pixel.
So, this commit will, when i3 starts first (not on restarts), copy the
contents of the X11 root window (typicall a grey background, at least on
my machine with GDM3) into a pixmap and set that pixmap as background
pixmap. That way, the content will be preserved and one has a
background, instead of what is perceived as a bug :).
This commit has some chance of breakage, so I’m prepared to revert it
unless we can figure out the issues and roll forward.
This removes code duplication, which will be useful for a subsequent
commit.
Furthermore, we now don’t open X11 connections unnecessarily in some
corner cases.
Ingo Bürk