mirrors/labwc
1
0
Fork 0
mirror of https://github.com/labwc/labwc.git synced 2025-11-01 22:58:47 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

server.c: add wlr_output_enable() to cope with wlroots 0.9.0

Browse source
This commit is contained in:
Johan Malm 2020-05-10 20:10:36 +01:00
parent 83c3492c87
commit 08225f6234
2 changed files with 19 additions and 43 deletions
Download patch file Download diff file Expand all files Collapse all files

46
README.md
View file

@ -1,12 +1,20 @@
# labwc # labwc
labwc is a wayland compositor based on wlroots Aiming to become a light-weight openbox alternative for Wayland
## Dependencies ## Dependencies
- wlroots - wlroots
- wayland-protocols - wayland-protocols
## Background
I am looking for a Wayland compositor that feels like openbox, but haven't come across one yet. Playing around with some code-bases seems an obvious way to evaluate and explore options. I saw [sway](https://swaywm.org/), [cage](https://www.hjdskes.nl/blog/cage-01/) and [wio](https://wio-project.org/), and definitely like the feel of wlroots.
Before trying wlroots, I messed around with [QtWayland](https://github.com/qt/qtwayland), [grefsen](https://github.com/ec1oud/grefsen), [Mir](https://mir-server.io) / [egmde](https://github.com/AlanGriffiths/egmde). Lubuntu have [declared](https://lubuntu.me/lubuntu-development-newsletter-9/) that they will be switching to Wayland by default for 20.10 and that they are going to do this by porting Openbox to use the Mir display server and [Drew DeVault’s](https://drewdevault.com/) QtLayerShell, etc.
Influenced by: [sway](https://github.com/swaywm/sway), [rootston](), [openbox](https://github.com/danakj/openbox), [i3](https://github.com/i3/i3), [dwm](https://dwm.suckless.org)
## Keyboard shortcuts ## Keyboard shortcuts
``` ```
@ -16,39 +24,3 @@ Alt+F3 Launch dmenu
Alt+F12 Print all views (helpful if run from X11) Alt+F12 Print all views (helpful if run from X11)
``` ```
## Running labwc
labwc can be run from a tty or in an existing Wayland/X11 session.
## Why?
I saw [sway](https://swaywm.org/), [cage](https://www.hjdskes.nl/blog/cage-01/) and [wio](https://wio-project.org/), and felt the itch to have a go at hacking on a wlroots compositor myself.
I am also quietly looking for a Wayland alternative to openbox and playing around with some code-bases seems an obvious way to evaluate and explore options.
<b>QtWayland and Mir</b>
Before trying wlroots, I messed around with [QtWayland](https://github.com/qt/qtwayland) / [grefsen](https://github.com/ec1oud/grefsen) and [Mir](https://mir-server.io) / [egmde](https://github.com/AlanGriffiths/egmde). These are pretty cool and still worth exploring further.
Lubuntu have [declared](https://lubuntu.me/lubuntu-development-newsletter-9/) that they will be switching to Wayland by default for 20.10 and that they are going to do this by porting Openbox to use the Mir display server and [Drew DeVault’s](https://drewdevault.com/) QtLayerShell, etc. One to keep an eye on.
<b>kwin and mutter</b>
I don't think that the KDE and GNOME compositors will be right. Although they offer a brilliant experience, they are pretty heavy and quite integrated with their respective stacks. I think I'm right in saying that they're not standalone window managers.
[mutter](https://gitlab.gnome.org/GNOME/mutter) - 411k lines-of-code (LOC)
[kwin](https://github.com/KDE/kwin) - 191k LOC
In terms of size comparison of these two giants, it's worth reflecting on the size of a few friends:
[sway](https://github.com/swaywm/sway) - 37k LOC
[rootston]() - 7k LOC
[openbox](https://github.com/danakj/openbox) - 53k LOC
[i3](https://github.com/i3/i3) - 20k LOC (but does include i3bar, etc)
[dwm](https://dwm.suckless.org) - 2k LOC

16
server.c
View file

@ -389,16 +389,20 @@ void server_new_output(struct wl_listener *listener, void *data)
struct server *server = wl_container_of(listener, server, new_output); struct server *server = wl_container_of(listener, server, new_output);
struct wlr_output *wlr_output = data; struct wlr_output *wlr_output = data;
/* Some backends don't have modes. DRM+KMS does, and we need to set a /*
* Some backends don't have modes. DRM+KMS does, and we need to set a
* mode before we can use the output. The mode is a tuple of (width, * mode before we can use the output. The mode is a tuple of (width,
* height, refresh rate), and each monitor supports only a specific set * height, refresh rate), and each monitor supports only a specific set
* of modes. We just pick the first, a more sophisticated compositor * of modes. We just pick the monitor's preferred mode.
* would let the user configure it or pick the mode the display * TODO: support user configuration
* advertises as preferred. */ */
if (!wl_list_empty(&wlr_output->modes)) { if (!wl_list_empty(&wlr_output->modes)) {
struct wlr_output_mode *mode = struct wlr_output_mode *mode = wlr_output_preferred_mode(wlr_output);
wl_container_of(wlr_output->modes.prev, mode, link);
wlr_output_set_mode(wlr_output, mode); wlr_output_set_mode(wlr_output, mode);
wlr_output_enable(wlr_output, true);
if (!wlr_output_commit(wlr_output)) {
return;
}
} }
/* Allocates and configures our state for this output */ /* Allocates and configures our state for this output */