Skip to content

`wet_main()` is too complicated

I hate how complicated wet_main() is currently. Everything has to happen in a very specific order to work right. (I also don't like how complicated the head/output configuration management is, especially for DRM-backend in main.c, but that's separate.)

Could there be a better way to set up a weston_compositor? Like, collecting a list of all backends and plugins and features to be enabled first, and then just creating a weston_compositor with everything, and libweston would make sure internally that the ordering is correct.

Relatedly also, currently plugins have two-step initialization procedure: 1) when the DSO is loaded, it will register a 2) idle callback to initialize more when all plugins have been registered. This is kind of inflexible and fragile. Maybe weston_compositor should have a series of wl_signals for the start-up (and shutdown!) sequence. When a DSO (plugin, backend, xwayland, shell, color manager, ...) is loaded, it would only hook up to the various signals, and do the real work from those. That way we can have more than two steps of init and shutdown, and avoid accidental dependencies on DSO loading order.

The hard part would be to define what steps the init and shutdown sequences have.

With that, the test suite could work around !16 (comment 854736) .

!578 (merged) is what made me think of this again and to write this down.

For the plugin initialization sequence, I even imagined that instead of wl_signals, each DSO could optionally expose multiple entrypoints with predefined names, and the weston_compositor initialization would automatically call the entrypoints of all DSOs in sequence. But I'm not sure if that's better or worse than having DSO have a single entrypoint that subscribed to the various signals instead.

We already have an init sequence problem worked around for !565 (comment 833133) where a test needs to know if the renderer supports a feature and skip otherwise or output configuration will fail. So there must be a place to hook in where the renderer is initialised but the coldplug for existing heads is not done yet. When discussing that, I took a look at what wet_main() actually does:

  • parse command line options
  • create logging context, log file, etc.
  • check environment variables
  • create wl_display
  • set up POSIX signal handlers
  • load config file
  • wait for debugger
  • create weston_compositor
  • more loggers
  • configure weston_compositor
  • load backend
  • flush heads changed (creates outputs)
  • configure weston_compositor more
  • setup Wayland sockets
  • load shell plugin
  • load arbitrary plugins
  • load xwayland plugin
  • NumLock configuration
  • wake and enter main event loop

It's horrible. No-one will want to use libweston as a basis for their own compositor if this is what they need to replicate.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information