[regression] unity-system-compositor can't start (Unknown command line options: --vt 1) via lightdm on Android

[Daniel van Vugt]

From Cemil:
Sync'ed up 0.6 with devel@r1831 since we were in TRAINCON-0. Everything built successfully.

Using image #179 with 0.6, mir itself works (i.e. mir-demos & nested), but USC has the following error :

root@ubuntu-phablet:~# cat /var/log/lightdm/unity-system-compositor.log
Unknown command line options: --vt 1

The "vt" option is passed in by the wrapper in lightdm, but not sure why usc is rejecting it. Without 0.6, usc works fine with the same set of args.

It'd be nice if the AUS, or EUR can take a look on Mon. Follow the instructions (updated due to platform versioning) below to install and test :

http://pastebin.ubuntu.com/7993688/

[Daniel van Vugt (vanvugt)]

Not in progress any more. Blocked by USC bug 1355021.

[Chris Halse Rogers (raof)]

I can't reproduce this; on my image, LightDM does *not* pass the (incorrect) --vt 1 option.

http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1826 is the change which introduced the “fail if passed unsupported options” behaviour, but I think this should be fixed by not passing unsupported options in the first place - that's the generally expected behaviour.

[Daniel van Vugt (vanvugt)]

I've just tested all the latest code compiled together:
  lp:unity-system-compositor/devel-mir-next
  lp:mir/devel

And there is no bug. unity-system-compositor correctly honours the --vt parameter for me.

If there was a bug at all, it's not present in our development branches.

[Daniel van Vugt (vanvugt)]

Oh, wait. We have probably hidden the option on android. Need to re-test.

[Daniel van Vugt (vanvugt)]

OK, verified this is correct Mir behaviour on android because the "--vt" option does not exist on that platform:
Unknown command line options: --vt 1

If lightdm is passing the option then that's a lightdm bug.

[Alan Griffiths (alan-griffiths)]

Yes, the option doesn't exist on the "Android drivers" Mir platform.

If USC wants to support options that don't exist there's a mechanism to do so - pass a handler for it to DefaultConfiguration.

But I concur with Chris, the correct fix is not to pass invalid options.

[Daniel van Vugt (vanvugt)]

The offending lightdm code is here:
http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/unity-system-compositor.c#L431

The logic is present on android builds too, so it looks like a bad lightdm config is triggering it.

[Daniel van Vugt (vanvugt)]

Actually I'm undecided about this now. The --vt option clearly used to work on android and we've made it explicitly trigger an error only recently in changes to Mir (0.6/0.7). Not sure if I prefer that or if we should be accepting and ignoring harmless unused options in libmirserver.

[Alan Griffiths (alan-griffiths)]

Workaround pushed to lp:unity-system-compositor/devel-mir-next -c 156.

[Cemil Azizoglu (cemil-azizoglu)]

Noting here after discussion on IRC that this should really be fixed in lightdm. Ignoring this option in u-s-c is a stop-gap until lightdm is fixed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-system-compositor - 0.0.4+14.10.20140811-0ubuntu1

---------------
unity-system-compositor (0.0.4+14.10.20140811-0ubuntu1) utopic; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Cemil Azizoglu ]
  * Bump ABI for Mir 0.6.0 release. Ignore unknown command line
    arguments. Use the libraries suggested by mirserver package config.
    (LP: #1355005)

  [ Alan Griffiths ]
  * Bump ABI for Mir 0.6.0 release. Ignore unknown command line
    arguments. Use the libraries suggested by mirserver package config.
    (LP: #1355005)

  [ Kevin Gunn ]
  * Bump ABI for Mir 0.6.0 release. Ignore unknown command line
    arguments. Use the libraries suggested by mirserver package config.
    (LP: #1355005)
 -- Ubuntu daily release <email address hidden> Mon, 11 Aug 2014 21:09:54 +0000

[Robert Ancell (robert-ancell)]

Is the discussion http://irclogs.ubuntu.com/2014/08/11/%23ubuntu-mir.html ?

If u-s-c doesn't always accept the --vt option then then it's going to fail on kernels that have VT support (which from the above log seems to be this particular case?). If VT support is available then LightDM assigns VTs to each server / system compositor so they don't conflict. In the phone case we only have one system compositor but theoretically you could also start an X server so LightDM has to assign VTs if they exist.

There seem to options to solve this properly:
1. u-s-c always supports --vt and only applies it for backends that require it.
2. u-s-c backends that use VTs reads the XDG_VTNR environment variable.

I would recommend option 2 since VTs are going to be a legacy feature in the future anyway and other systems seem to be using XDG_VTNR over command line options.

[kevin gunn (kgunn72)]

workaround has been merged. I suppose this is still considered an open topic.
removing the rtm tag