The wlr-output-management protocol requires that either all of the
changes from an apply request be applied successfully, in which case a
"succeeded" event is sent, or all of the changes are reverted and a
"failed" event is sent. As written, this could partially commit
changes, then fail.
Test the changes first (even for an "apply" event), then commit or
rollback as appropriate.
Additionally, variables xcursor and xcursor_mgr are only used
when xwayland is defined, so I make the variables declaration
contingent on whether xwayland is being used
I am embarrassed to have let this slip through someone's merge. Anybody
who genuinely needs to `sudo make` will know it; everyone else should
use a proper package manager and build system.
Replaces the outputOrder patch.
This avoids recalculating positions and allows to arrange monitors in
any order, not just from left to right.
The order in which monitors are defined in config.h still matters but
it's just the order in the list, not the actual position.
This is the order of *_destroy calls which resulted in the fewest
errors/leaks detected by Valgrind. Most of the errors come from the
gbm_allocator code - will have to figure out which destroy call is still
missing.
Similar to Linux kernel approach, encapsulate some of the uglier
conditional compilation into inline functions in header files.
The goal is to make dwl.c more attractive to people who embrace the
suckless philosophy - simple, short, hackable, and easy to understand.
We want dwm users to feel comfortable here, not scare them off. Plus,
if we do this right, the main dwl.c code should require only minimal
changes once XWayland is no longer a necessary evil.
According to `cloc`, this also brings dwl.c down below 2000 lines of
non-blank, non-comment code.
When a new client is spawned, fullscreen isn't disabled for all clients
in that monitor any more.
Instead, all fullscreen clients are kept fullscreen, while other clients
spawn in the background.
When fullscreen is disabled, all clients are rearranged.
This is made to make dwl more flexible allowing multiple fullscreen
clients at the same time, have floating clients on top of a fullscreen
one and let stuff happen without quitting fullscreen, like many other
WMs and DEs.
Disable fullscreen on all visible clients in that monitor also before
enabling it on another client.
quitallfullscreen() is reintroduced becouse is now more useful
set c->isfullscreen later to avoid making quitallfullscreen() disable
fullscreen on the current client
...in internal calls to restore pointer focus. Necessary for the
unclutter patch, and there's no harm in avoiding this call even in
mainline; might prevents issues in same edge cases.
- A maximum SLOC can't be reasonably determined before implementing the
missing protocols, so not any time soon
- dwl definitely isn't a simple as dwm since it must implement lots of
Wayland protocols and not just manage windows. The status bar
integration, layer shell popups, damage tracking and IME are gonna
require hundreds more lines each.
- "Buffering of input when spawning a client so you don't have to wait
for the window (use `wl_client_get_credentials` to get the PID) - would
this require passing through something like dmenu? Extension protocol?"
This sounds exoteric, if anything this should be patch.
- Can dwl really be started from within an X session? When I do it from
dwm it crashes.
- A window's texture is scaled for its "home" monitor only (noticeable
when window sits across a monitor boundary)
Gonna open a ticket for this rather than keep it in the README.
Don't let internal calls to motionnotify(0) meant to update the pointer
focus from maplayersurfacenotify and destroylayersurfacenotify also
shift the keyboard focus to the surface under the cursor with
sloppyfocus.
wtf is the point of this crap? It makes the code harder to follow,
increases the line count and made me fail compilation a million times.
We shouldn't blindy follow everything about suckless's style.
Scaling a wlr_box without rounding can sometimes make the borders not
connected and nice. I noticed this when setting scale in monrules to 1.2
So I've went and copied what Sway did in desktop/output.c but without
having a second function and now using a random rounding macro I found
on the internet so as to not use round from math.h.
Distribute it as a patch like in dwm since graphical applications
usually provide their own keybinding; I guess it's only for terminals.
Note that even though these commits don't let you open multiple windows
in fullscreen and cycle between them like in dwm, with just
fullscreennotify spawning new windows or changing tag would still exit
fullscreen automatically, but you would have to toggle fullscreen twice
when switching back to the fullscreen window to enter fullscreen again,
so this is better since it avoids that.
quitfullscreen() was replicating the functionalities of setfullscreen(c,
0)
Reusing setfullscreen() in quitfullscreen() leads to a 3 line function,
which is useless since quitfullscreen() is used once anyway
This fixes the bug that happens when changing workspace (or any time
arrange() is called) where there are fullscreen windows, which are still
fullscreen but leave the space for layer surfaces like waybar (which
should be hidden when going fullscreen)
Also as soon one fullscreen window is found hte function returns to
improve efficiency
Store position and size of windows before going fullscreen. This is more
efficient than arrange() and also works with floating windows
All the clients keep their original position because arrange() isn't
used after quitting fullscreen
Because maprequest immediately calls wl_list_insert(&fstack, &c->flink),
in the following call to setmon(), the selclient() which is passed to
focusclient() as the old client is actually the newly mapped client, and
the real old one is never deactivated. You can see this by, for example,
opening Chromium's devtools, then spawning a terminal. The background of
the focused line in the devtools doesn't change from light blue to grey.
We can't just remove wl_list_insert(&fstack, &c->flink) from maprequest,
because calling wl_list_remove in focusclient() with a client that has
not been added to the list causes a segmentation fault.
Therefore we fix the focusclient call by not passing it the old client
every time, but instead using the wlroots function that gets the focused
surface and deactivate that, like in TinyWL.
This also avoids getting the selected client and passing it to
focusclient() on every call unnecessarily, and will allow removing
shouldfocusclients in a future commit by checking if old is a layer
surface instead.
It makes wl-clipboard work properly in neovim, without having to create
a transparent surface that steals focus and causes flickering. It's also
required for clipman.
The code in this else completely freezes my system when I run the
swayidle command to replicate xset dpms force off. No idea if it works
on multiple monitors, but for now avoid running when there's 1 monitor.
Also remove the comment with the function name in sway.
Since wlr_output_enable doesn't have any effect before finishing all the
procedure, a little hack allows to make use of focusmon(), which must
know the latest in about which output is currently disabled
Also improve performance in focusmon() and cleaner code in
outputmgrapplyortest()
With the recent changes in output-management, the extra argument in
closemon() would be needed only when unplugging the monitor, so it isn't
worth it anymore. Also now is more efficient.
m->link.next leads to errors if the monitor to disable doesn't have a
"next" (right) monitor and is currently focused. dirtmon() does more
checks.
In some previous commits m->link.next is told to be left monitor, which
is wrong
Also focusclient() explicitly checks for disabled monitors (this fixes
in case of more than one disabled monitor)
Focus the top client on newmon, which we know for sure that it isn't
going to be unplugged or disabled and actually set that as the focused
monitor to move the focus. This is necessary to prevent crash when
disabling monitors with the output-management patch.
This allows to fix output-management: move clients to the monitor on the
left of the disabled one, instead of the leftmost (which might happen to
be the disabled one)
Also using wl_list_foreach() and then brake after the first iteration is
ugly and inefficient
When using wlr-randr every monitor's configuration is reevaluated, so it
must check which monitors are actually being disabled. The only way to
correctly do that is to compare the names.
When a monitor is disabled with wlr_randr, all clients on that monitor
aren't lost but they are moved to the leftmost monitor with the same
method that handles monitor hot unplug
There is no need to repeat this. This needs to be reculalculated in my
output-management implementation too, and since I'm already calling
updatemons, this patch avoids having to repeat the assignment again.
quitfullscreen() was replicating the functionalities of setfullscreen(c,
0)
Reusing setfullscreen() in quitfullscreen() leads to a 3 line function,
which is useless since quitfullscreen() is used once anyway
This fixes the bug that happens when changing workspace (or any time
arrange() is called) where there are fullscreen windows, which are still
fullscreen but leave the space for layer surfaces like waybar (which
should be hidden when going fullscreen)
Also as soon one fullscreen window is found hte function returns to
improve efficiency
Floating widndows with "x < removed monitor's width" aren't resized
(they used to disappear in negative coordinates).
Actually delete monitors when they are unplugged, recalculate sgeom and
give a new monitor to clients that were on the removed one with setmon()
arrangefloat() funcion has been exploded to save iterations in
cleanupmon().
Also if a monitor that supports auto suspension is turned off, dwl will
count it as unplugged (it will become unreachable and all clients will
be moved to the leftmost monitor). However, if at least one monitor
isn't plugged in, dwl will still crash the same as before.
Unlike sway, when the output configuration is changed and restored,
(unplug + plug the same monitor for example) previous application
positions aren't kept. This is due to the fact that on sway every
workspace is unique among all monitors.
Compensate the coordinate changes when adding a new monitor.
Every test so far confirms that monitors are always added to the left,
on top of the list, so every floating window's x coordinate has to be
incremented by the width of the new monitor.
When a monitor is created or removed, the geometries of the old ones
must be updated. This is also more efficient than before since we
calculate the monitor geometries only when creating and destroying
monitors. arrangelayers() is needed to recalculate m->w. arrange() is so
clients don't move to the left monitor when plugging or unplugging
monitors (clients keep the same coordinates but the field below them
changes).
The bug was caused by usable_area's x and y not being set in
arrangelayers. For example if on a 2nd HD monitor, x should be 1920
while the first one ends at 1919. So I don't see why m->m should be
recalculated after creating the monitor.
If you don't recalculate the monitor's geometry before arranging,
clients get arranged in the first monitor. I don't understand why this
fixes the bug since tile() uses m->w rather than m->m, nor why it needs
to be recalculated after creating the monitor but sway does it too.
Although not necessary to fix the bug I also made arrangelayer() do like
sway again and recalculate usable_area instead of reusing m->m, since
m->m seems to be incorrect until it gets recalculated shortly after in
arrange(), so I suspect that leaving usable_area = m->m will cause
issues under certain circumstances.
Someone with a multi-monitor setup or better knowledge of Wayland may be
able to figure out the cause of the bug. For now, this makes layer shell
work.
When a layer surface is destroyed focus should be returned to the last
client. Luckily if there are multiple overlays the previous overlay
still gets focused.
Store position and size of windows before going fullscreen. This is more
efficient than arrange() and also works with floating windows
All the clients keep their original position because arrange() isn't
used after quitting fullscreen
rename Layer to LayerSurface; layer should refer to overlay, top, bottom
or background
LayerSurface variables are always called layersurface
wlr_layer_surface_v1 variables are always called wlr_layer_surface
dwl is a compact, hackable compositor for Wayland based on [wlroots](https://github.com/swaywm/wlroots). It is intended to fill the same space in the Wayland world that dwm does in X11, primarily in terms of philosophy, and secondarily in terms of functionality. Like dwm, dwl is:
Join us on our [Discord server](https://discord.gg/jJxZnrGPWN)!
dwl is a compact, hackable compositor for Wayland based on [wlroots](https://github.com/swaywm/wlroots). It is intended to fill the same space in the Wayland world that dwm does in X11, primarily in terms of philosophy, and secondarily in terms of functionality. Like dwm, dwl is:
- Easy to understand, hack on, and extend with patches
- Easy to understand, hack on, and extend with patches
- One C source file (or a very small number) configurable via `config.h`
- One C source file (or a very small number) configurable via `config.h`
- Limited to a maximum number of SLOC (to be determined)
- Limited to 2000 SLOC to promote hackability
- Tied to as few external dependencies as possible
- Tied to as few external dependencies as possible
dwl is not meant to provide every feature under the sun. Instead, like dwm, it sticks to features which are necessary, simple, and straightforward to implement given the base on which it is built. Implemented default features are:
dwl is not meant to provide every feature under the sun. Instead, like dwm, it sticks to features which are necessary, simple, and straightforward to implement given the base on which it is built. Since wlroots provides a number of features that are more complicated to accomplish with Xlib and select extensions, dwl can be in some ways more featureful than dwm *while remaining just as simple.* Intended default features are:
- Any features provided by dwm/Xlib: simple window borders, tags, keybindings, client rules, mouse move/resize. The built-in status bar is an exception to avoid taking a dependency on FreeType or Pango and increasing the SLOC
- Any features provided by dwm/Xlib: simple window borders, tags, keybindings, client rules, mouse move/resize (see below for why the built-in status bar is a possible exception)
- Configurable multi-monitor layout support, including position and rotation
- Configurable multi-monitor layout support, including position and rotation
- Configurable HiDPI/multi-DPI support
- Configurable HiDPI/multi-DPI support
- Wayland protocols needed for daily life in the tiling world: at a minimum, xdg-shell and layer-shell (for bars/menus). Protocols trivially provided by wlroots may also be added.
-Various Wayland protocols
- XWayland support as provided by wlroots
- XWayland support as provided by wlroots
- Zero flickering - Wayland users naturally expect that "every frame is perfect"
- Zero flickering - Wayland users naturally expect that "every frame is perfect"
- Basic yes/no damage tracking to avoid needless redraws (if it can be done simply and has an impact on power consumption)
Features under consideration (possibly as patches) are:
Other features under consideration are:
- Protocols made trivial by wlroots
- Communication from the compositor to status bars. A straightforward possibility would be to use stdout or a provided file descriptor.
-Additional Wayland compositor protocols which are trivially provided by wlroots or can be conditionally included via `config.h` settings (e.g. screen capture)
-Implement the input-inhibitor protocol to support screen lockers
-External bar support instead of a built-in status bar, to avoid taking a dependency on FreeType or Pango
-Implement the idle-inhibit protocol which lets applications such as mpv disable idle monitoring
-Buffering of input when spawning a client so you don't have to wait for the window (use `wl_client_get_credentials` to get the PID) - would this require passing through something like dmenu? Extension protocol?
-Layer shell popups (used by Waybar)
-More in-depth damage region tracking
-Basic yes/no damage tracking to avoid needless redraws
- More in-depth damage region tracking ([which may improve power usage](https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/))
- Implement the text-input and input-method protocols to support IME once ibus implements input-method v2 (see https://github.com/ibus/ibus/pull/2256 and https://github.com/djpohly/dwl/pull/12)
- Implement urgent/attention/focus-request once it's part of the xdg-shell protocol (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/9)
Feature *non-goals* include:
Feature *non-goals* include:
- Client-side decoration (any more than is necessary to tell the clients not to)
- Client-side decoration (any more than is necessary to tell the clients not to)
- Client-initiated window management, such as move, resize, and close, which can be done through the compositor
- Client-initiated window management, such as move, resize, and close, which can be done through the compositor
## Building dwl
## Building dwl
dwl has only two dependencies: wlroots (git version currently required) and wayland-protocols. Simply install these and run `make`.
dwl has only two dependencies: wlroots 0.12 and wayland-protocols. Simply install these and run `make`. If you wish to build against a Git version of wlroots, check out the [wlroots-next branch](https://github.com/djpohly/dwl/tree/wlroots-next).
To enable XWayland, you should also install xorg-xwayland and uncomment its flag in `config.mk`.
## Configuration
## Configuration
All configuration is done by editing `config.h` and recompiling, in the same manner as dwm. There is no way to separately restart the window manager in Wayland without restarting the entire display server, so any changes will take effect the next time dwl is executed.
All configuration is done by editing `config.h` and recompiling, in the same manner as dwm. There is no way to separately restart the window manager in Wayland without restarting the entire display server, so any changes will take effect the next time dwl is executed.
As in the dwm community, we encourage users to share patches they have created. Check out the [patches page on our wiki](https://github.com/djpohly/dwl/wiki/Patches)!
## Running dwl
## Running dwl
dwl can be run as-is, with no arguments. In an existing Wayland or X11 session, this will open a window to act as a virtual display. When run from a TTY, the Wayland server will take over the entire virtual terminal. Clients started by dwl will have `WAYLAND_DISPLAY` set in their environment, and other clients can be started from outside the session by setting this variable accordingly.
dwl can be run as-is, with no arguments. In an existing Wayland or X11 session, this will open a window to act as a virtual display. When run from a TTY, the Wayland server will take over the entire virtual terminal. Clients started by dwl will have `WAYLAND_DISPLAY` set in their environment, and other clients can be started from outside the session by setting this variable accordingly.
You can also specify a startup program using the `-s` option. The argument to this option will be run at startup as a shell command (using `sh -c`) and can serve a similar function to `.xinitrc`: starting a service manager or other startup applications. Unlike `.xinitrc`, the display server will not shut down when this process terminates. Instead, as dwl is shutting down, it will send this process a SIGTERM and wait for it to terminate (if it hasn't already). This makes it ideal not only for initialization but also for execing into a user-level service manager like s6 or `systemd --user`.
You can also specify a startup program using the `-s` option. The argument to this option will be run at startup as a shell command (using `sh -c`) and can serve a similar function to `.xinitrc`: starting a service manager or other startup applications. Unlike `.xinitrc`, the display server will not shut down when this process terminates. Instead, as dwl is shutting down, it will send this process a SIGTERM and wait for it to terminate (if it hasn't already). This makes it ideal not only for initialization but also for execing into a user-level service manager like s6 or `systemd --user`.
More/less verbose output can be requested with flags as well:
*`-q`: quiet (log level WLR_SILENT)
*`-v`: verbose (log level WLR_INFO)
*`-d`: debug (log level WLR_DEBUG)
Note: Wayland requires a valid `XDG_RUNTIME_DIR`, which is usually set up by a session manager such as `elogind` or `systemd-logind`. If your system doesn't do this automatically, you will need to configure it prior to launching `dwl`, e.g.:
Note: Wayland requires a valid `XDG_RUNTIME_DIR`, which is usually set up by a session manager such as `elogind` or `systemd-logind`. If your system doesn't do this automatically, you will need to configure it prior to launching `dwl`, e.g.:
export XDG_RUNTIME_DIR=/tmp/xdg-runtime-$(id -u)
export XDG_RUNTIME_DIR=/tmp/xdg-runtime-$(id -u)
mkdir -p $XDG_RUNTIME_DIR
mkdir -p $XDG_RUNTIME_DIR
## Replacements for X applications
## Known limitations and issues
You can find a [list of Wayland applications on the sway wiki](https://github.com/swaywm/sway/wiki/i3-Migration-Guide).
dwl is a work in progress, and it has not yet reached its feature goals in a number of ways:
## IRC channel
- A window's texture is scaled for its "home" monitor only (noticeable when window sits across a monitor boundary)
- XWayland support is new and could use testing
- Urgent/attention/focus-request ([not yet supported](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/9) by xdg-shell protocol)
- Statusbar support (built-in or external)
- layer-shell
- Damage tracking
- Fullscreen/fixed windows (or whatever the Wayland analogues are)
dwl's IRC channel is #dwl on irc.freenode.net.
## Acknowledgements
## Acknowledgements
dwl began by extending the TinyWL example provided (CC0) by the sway/wlroots developers. This was made possible in many cases by looking at how sway accomplished something, then trying to do the same in as suckless a way as possible. Speaking of which, many thanks to suckless.org and the dwm developers and community for the inspiration.
dwl began by extending the TinyWL example provided (CC0) by the sway/wlroots developers. This was made possible in many cases by looking at how sway accomplished something, then trying to do the same in as suckless a way as possible.
Many thanks to suckless.org and the dwm developers and community for the inspiration, and to the various contributors to the project, including:
- Alexander Courtis for the XWayland implementation
- Guido Cella for the layer-shell protocol implementation, patch maintenance, and for helping to keep the project running
- Stivvo for output management and fullscreen support, and patch maintenance
When a configure event is received, if a client commits the
surface in response to the configure event, then the client
must make an ack_configure request sometime before the commit
request, passing along the serial of the configure event.
If the client receives multiple configure events before it
can respond to one, it only has to ack the last configure event.
A client is not required to commit immediately after sending
an ack_configure request - it may even ack_configure several times
before its next surface commit.
A client may send multiple ack_configure requests before committing, but
only the last request sent before a commit indicates which configure
event the client really is responding to.
</description>
<argname="serial"type="uint"summary="the serial from the configure event"/>
</request>
<requestname="destroy"type="destructor">
<descriptionsummary="destroy the layer_surface">
This request destroys the layer surface.
</description>
</request>
<eventname="configure">
<descriptionsummary="suggest a surface change">
The configure event asks the client to resize its surface.
Clients should arrange their surface for the new states, and then send
an ack_configure request with the serial sent in this configure event at
some point before committing the new surface.
The client is free to dismiss all but the last configure event it
received.
The width and height arguments specify the size of the window in
surface-local coordinates.
The size is a hint, in the sense that the client is free to ignore it if
it doesn't resize, pick a smaller size (to satisfy aspect ratio or
resize in steps of NxM pixels). If the client picks a smaller size and
is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the
surface will be centered on this axis.
If the width or height arguments are zero, it means the client should
decide its own window dimension.
</description>
<argname="serial"type="uint"/>
<argname="width"type="uint"/>
<argname="height"type="uint"/>
</event>
<eventname="closed">
<descriptionsummary="surface should be closed">
The closed event is sent by the compositor when the surface will no
longer be shown. The output may have been destroyed or the user may
have asked for it to be removed. Further changes to the surface will be
ignored. The client should destroy the resource after receiving this
event, and create a new surface if they so choose.
</description>
</event>
<enumname="error">
<entryname="invalid_surface_state"value="0"summary="provided surface state is invalid"/>
<entryname="invalid_size"value="1"summary="size is invalid"/>
<entryname="invalid_anchor"value="2"summary="anchor bitfield is invalid"/>
<entryname="invalid_keyboard_interactivity"value="3"summary="keyboard interactivity is invalid"/>
</enum>
<enumname="anchor"bitfield="true">
<entryname="top"value="1"summary="the top edge of the anchor rectangle"/>
<entryname="bottom"value="2"summary="the bottom edge of the anchor rectangle"/>
<entryname="left"value="4"summary="the left edge of the anchor rectangle"/>
<entryname="right"value="8"summary="the right edge of the anchor rectangle"/>
</enum>
<!-- Version 2 additions -->
<requestname="set_layer"since="2">
<descriptionsummary="change the layer of the surface">
Change the layer that the surface is rendered on.
Layer is double-buffered, see wl_surface.commit.
</description>
<argname="layer"type="uint"enum="zwlr_layer_shell_v1.layer"summary="layer to move this surface to"/>
</request>
</interface>
</protocol>
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Devin J. Pohly