| Summary: | Loading a Weston shell from the command line is ambiguous | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | U. Artie Eoff <ullysses.a.eoff> |
| Component: | weston | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | VERIFIED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
weston output when multiple shells load
Weston INI |
||
Created attachment 70709 [details]
Weston INI
The man page says:
--modules=module1.so,module2.so
Load the comma-separated list of modules. Only used by the test suite. The file is searched for in
/home/rob/local/wayland/lib64/weston, or you can pass an absolute path.
Is it still the case that it is only used by the test suite? In which case I think it's acceptable to make --modules override all behaviour from module entries in the weston.ini file / default behaviour.
I posted a patch to the list that makes --modules override the weston.ini entry and I documented this in the manual page. From the communication on the list the --modules option is all about providing a supplementary list of modules to load. In order to change the shell you need to specify that shell in the weston.ini |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 70708 [details] weston output when multiple shells load When [core]/modules is not defined in "weston.ini" or when it's explicitly set to desktop-shell.so, trying to load tablet-shell.so via the "--modules" command line argument does not work as expected (and vice-versa). In this situation, both desktop-shell.so and tablet-shell.so get loaded. The only way to "exclusively" load tablet-shell.so is to specify it in weston.ini (see attachment) under [core] via "modules=tablet-shell.so" option. Loading a Weston "shell" from the command line is, thus, ambiguous. It is unclear which wayland shell interface is active in Weston when two shells are loaded. Does it make sense to allow multiple shell interface implementations to coexist at Weston runtime? ---- cairo (master) 376d39121c0d4eba8f0a22be71f782ce18e50923 dri2proto (master) 4eeacce4c4a300b938b7e3fb78a8e443c491780b drm (master) 171666e4b8127c17c68ea0d44cf4e81ec342f2d0 glproto (master) ec1eec4355ee4a6c5134f2178192f10b6d28a87a kbproto (master) 391a1f6de6315fc0196d407d800597488315cccb libX11 (master) d14b6a250f004fa405179db7020f6953001d17b9 libxkbcommon (master) f1598469434ef6128320d6b0810b8f82f6aca484 macros (master) 0890e4003aacfa7113ab3f4e3ad7c5636f8e922a mesa (master) 13f9012ad3837c98a2c891244e64878fa61f9cd2 pixman (master) 44dd746bb68625b2f6be77c3f80292b45defe9d7 wayland (master) e8fbce73c7d2d546fcb90fe6115306f27c699fff weston (master) b88b68fa42086304f615ee9f67e9c290d059868b