]> git.mdlowis.com Git - proto/labwc.git/commitdiff
server.c: add wlr_output_enable() to cope with wlroots 0.9.0
authorJohan Malm <jgm323@gmail.com>
Sun, 10 May 2020 19:10:36 +0000 (20:10 +0100)
committerJohan Malm <jgm323@gmail.com>
Sun, 10 May 2020 19:10:36 +0000 (20:10 +0100)
README.md
server.c

index b0940f0630417111f25e01b7b39770e319ebecba..1b05b32c82ff5a5b7dfcf6c8c95085629c1bacdb 100644 (file)
--- a/README.md
+++ b/README.md
@@ -1,12 +1,20 @@
 # labwc
 
-labwc is a wayland compositor based on wlroots
+Aiming to become a light-weight openbox alternative for Wayland
 
 ## Dependencies
 
 - wlroots
 - 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
 
 ```
@@ -16,39 +24,3 @@ Alt+F3      Launch dmenu
 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
-
index bccce7bc17675ac9033b9f4119c8286fa04ae2fb..f384d1e5f4e1bd2b6c78a1b0605fbd8e00d105e1 100644 (file)
--- a/server.c
+++ b/server.c
@@ -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 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,
         * height, refresh rate), and each monitor supports only a specific set
-        * of modes. We just pick the first, a more sophisticated compositor
-        * would let the user configure it or pick the mode the display
-        * advertises as preferred. */
+        * of modes. We just pick the monitor's preferred mode.
+        * TODO: support user configuration
+        */
        if (!wl_list_empty(&wlr_output->modes)) {
-               struct wlr_output_mode *mode =
-                       wl_container_of(wlr_output->modes.prev, mode, link);
+               struct wlr_output_mode *mode = wlr_output_preferred_mode(wlr_output);
                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 */