mirror of
https://github.com/labwc/labwc.git
synced 2025-10-29 05:40:24 -04:00
server.c: add wlr_output_enable() to cope with wlroots 0.9.0
This commit is contained in:
parent
83c3492c87
commit
08225f6234
2 changed files with 19 additions and 43 deletions
46
README.md
46
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
|
||||
|
||||
|
|
|
|||
16
server.c
16
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 */
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue