Allowing users to choose the output backend of weston
taoky opened this issue · comments
Currently, x11docker will start weston with x11 backend when DISPLAY
is set ($Hostdisplay
is not null):
Lines 4030 to 4034 in 93a2793
However, this will also start weston in x11 when in a wayland session with xwayland support. And unfortunately, I got this bug (I submitted just now) of weston x11 backend, which makes the experience uncomfortable.
Although weston.ini(5) supports settings backends:
CORE SECTION
The core section is used to select the startup compositor modules and general options.
shell=desktop-shell.so
specifies a shell to load (string). This can be used to load your own implemented shell or one with
Weston as default. Available shells in the /usr/lib/weston directory are:
desktop-shell.so
xwayland=true
ask Weston to load the XWayland module (boolean).
modules=cms-colord.so,screen-share.so
specifies the modules to load (string). Available modules in the /usr/lib/weston directory are:
cms-colord.so
screen-share.so
backend=headless-backend.so
overrides defaults backend. Available backend modules in the /usr/lib/libweston-11 directory are:
drm-backend.so
headless-backend.so
rdp-backend.so
wayland-backend.so
x11-backend.so
It seems that the backend set in command line takes higher priority than weston.ini:
Lines 4137 to 4141 in 93a2793
Currently my workaround is to modify [ -n "$Hostdisplay" ] && Westonoutput="X"
to [ -n "$Hostdisplay" ] && Westonoutput="WL"
, and set size manually in weston.ini (otherwise the window is too large when default option is wayland backend). I think that it can be fixed by:
- If users don't provide their own weston.ini, keep current behavior.
- Otherwise, check if
backend
is set inside weston.ini. If so, don't add--backend
to$Compositorcommand
.
And, unsetting DISPLAY
when running x11docker also workarounds this, but breaks the clipboard sharing functionality.