weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2024-02-06T10:29:12Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/638Pattern weston_head_from_resource(output_resource)->output is not safe2024-02-06T10:29:12ZPekka Paalanenppaalanen@gmail.comPattern weston_head_from_resource(output_resource)->output is not safeThere are many instances of `weston_head_from_resource(output_resource)->output` in the code base, literally. This construct is not safe, because the `weston_head` can be `NULL`.
If a client is sending a request with a `wl_output` argum...There are many instances of `weston_head_from_resource(output_resource)->output` in the code base, literally. This construct is not safe, because the `weston_head` can be `NULL`.
If a client is sending a request with a `wl_output` argument at the same time as the compositor is disabling the corresponding `weston_output`, the user data of `wl_resource` for the `wl_output`s is set to `NULL`.
These would need to be fixed. Found by code inspection.https://gitlab.freedesktop.org/wayland/weston/-/issues/633Rename compositor/ directory2024-01-26T09:59:44ZPekka Paalanenppaalanen@gmail.comRename compositor/ directory`compositor` is a bit misleading name. Should we rename that to... `frontend`? Or something?`compositor` is a bit misleading name. Should we rename that to... `frontend`? Or something?14.0.0https://gitlab.freedesktop.org/wayland/weston/-/issues/660modesetting is done on first run with mode=current2022-11-21T11:56:56Zmanuel alfayatemodesetting is done on first run with mode=currentHi,
Some betas ago, Weston started to do modesetting (ie: blanking the screen to do a full modeset) even with `mode=current` in `weston.ini`.
That's because there's this general misconception that setting `max_bpc` does not need a full...Hi,
Some betas ago, Weston started to do modesetting (ie: blanking the screen to do a full modeset) even with `mode=current` in `weston.ini`.
That's because there's this general misconception that setting `max_bpc` does not need a full modeset, but it does, so setting max_bpc has propagated from WLRoots to Weston (or is it the opposite?) and is now being done unconditionally in Weston, too.
As a temporal fix for my own builds, removing this call prevents modesetting (screen blanking on Weston's first launch after a reboot):
https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/backend-drm/kms.c#L994
TAKE INTO ACCOUNT that, once set, max_bpc on a connector is kept between Wayland compositor runs, so a reboot is needed to see the unnecessary screen blanking and again to see it solved.
In a nutshell: `max_bpc` should NOT be set if `mode=current`, because `mode=current` assumes no modesetting will be done and setting `max_bpc` requires a full modeset.
Just in case: tested on VC4 and AMDGPU, and both DRM kernel drivers require a full modeset for setting `max_bpc`, so this is not happening on some exotic kernel driver.
Thankshttps://gitlab.freedesktop.org/wayland/weston/-/issues/205Nested backends should not use the default Wayland socket?2022-11-02T09:54:56ZPekka Paalanenppaalanen@gmail.comNested backends should not use the default Wayland socket?For background, see: https://gitlab.gnome.org/GNOME/gtk/issues/1741
When Weston runs nested, be that on X11 or Wayland, it is by definition not the main display server. Therefore it should pick a Wayland socket name other than `wayland-...For background, see: https://gitlab.gnome.org/GNOME/gtk/issues/1741
When Weston runs nested, be that on X11 or Wayland, it is by definition not the main display server. Therefore it should pick a Wayland socket name other than `wayland-0` which is the default socket libwayland-client will connect to when `WAYLAND_DISPLAY` environment variable is not set.
Only the user's default/main compositor should use the default socket.
This will prevent toolkits from mistakenly connecting to the nested Weston by default.
I guess it would be nice to do the same when running with the headless backend, just in case someone runs it outside of the test suite.
What about RDP?
Do we need a new Weston option for "use default socket for listening", whose default value depends on the backend? Hmm, maybe not, there is already `-S` command line option, and the choice of backend could affect the default socket name.https://gitlab.freedesktop.org/wayland/weston/-/issues/542CONFIG_MULTIUSER=n, plus problems with ignored input devices2022-01-12T18:05:38ZJosef MooreCONFIG_MULTIUSER=n, plus problems with ignored input devicesWeston, sway, tinywl, etc. will not work if the kernel CONFIG_MULTIUSER = n. Unusable in embedded systems.Weston, sway, tinywl, etc. will not work if the kernel CONFIG_MULTIUSER = n. Unusable in embedded systems.https://gitlab.freedesktop.org/wayland/weston/-/issues/171Autolaunch option for weston2021-07-07T11:11:02ZAnton KindestamAutolaunch option for westonA simple autolaunch feature that would launch one or more commands once weston is ready to accept clients.
My personal use case for this is to run `xrdb -merge ~/.Xresources` on startup of weston, but it could be used for anything from ...A simple autolaunch feature that would launch one or more commands once weston is ready to accept clients.
My personal use case for this is to run `xrdb -merge ~/.Xresources` on startup of weston, but it could be used for anything from launching a weston-terminal on startup to more advanced automatisation.https://gitlab.freedesktop.org/wayland/weston/-/issues/422Architect internal API for special test setup2020-10-27T11:24:04ZPekka Paalanenppaalanen@gmail.comArchitect internal API for special test setupTests may often want to configure bits inside the compositor, to do things that only make sense for very specific tests. For example, use fake clocks in !453 or forbid the use of the renderer screenshooting function in !458 or disable at...Tests may often want to configure bits inside the compositor, to do things that only make sense for very specific tests. For example, use fake clocks in !453 or forbid the use of the renderer screenshooting function in !458 or disable atomic modesetting (a hypothetical future test to ensure legacy KMS keeps working).
We could use environment variables for those, but they make an awkward API.
We already have `wet_testsuite_data_set()` and `wet_testsuite_data_get()` that are roughly at the right level in `compositor/testsuite-util.c`, but their problem is that they depend on a global variable to work. If we are ever going to run tests on e.g. the wayland-backend, which requires running two instances of Weston, any kind of global data is going to be a problem.
Therefore the test settings should be made on an object that is per-compositor-instance, probably on `struct weston_compositor` or something new that can be used by `wet_main()` and forwarded. We could add a new argument to `wet_main()` that is `NULL` when called from `compositor/executable.c` but carries the test setup when called from `tests/weston-test-fixture-compositor.c`.
We can also add stable ABI to libweston to set these special test bits, I don't think that hurts when documented properly. The test bits flow would be: test -> compositor fixture -> `wet_main` -> libweston.
Having proper API (functions) for this stuff also make it clear where to document these tricks, when other projects want to use Weston as a test bed and maybe control things like the clocks.
I'm thinking that all the test bits should probably be in a single new `struct` that has a single path through the whole weston stack from the executable to the backends and plugins. No functions that are specific for a backend, for instance. These test bits probably do not need to be toggleable after compositor start. Making something that is toggleable on the fly or ever introducing direct function calls between a compositor and a client is something for another time.