Bug 57636 - Loading a Weston shell from the command line is ambiguous
Summary: Loading a Weston shell from the command line is ambiguous
Status: VERIFIED NOTABUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-27 23:11 UTC by U. Artie Eoff
Modified: 2013-08-29 20:13 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
weston output when multiple shells load (3.58 KB, text/plain)
2012-11-27 23:11 UTC, U. Artie Eoff
Details
Weston INI (1.23 KB, text/plain)
2012-11-27 23:12 UTC, U. Artie Eoff
Details

Description U. Artie Eoff 2012-11-27 23:11:23 UTC
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
Comment 1 U. Artie Eoff 2012-11-27 23:12:36 UTC
Created attachment 70709 [details]
Weston INI
Comment 2 Rob Bradford 2013-07-09 09:47:57 UTC
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.
Comment 3 Rob Bradford 2013-07-09 11:15:01 UTC
I posted a patch to the list that makes --modules override the weston.ini entry and I documented this in the manual page.
Comment 4 Rob Bradford 2013-07-23 14:59:58 UTC
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.