Mir

Code review comment for lp:~cemil-azizoglu/mir/use-options-to-probe

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

There are possibly better solutions...

Example 1: mplayer/mencoder with its countless built-in drivers and codecs each with their own options, makes it more obvious when a codec-specific option is specific. e.g...
    mencoder -ovc lavc -lavcopts ...
This states clearly that I want to use video codec "lavc" and it has specific options of its own.

Example 2: In Mesa, graphics drivers have custom options of their own which you pass according to naming convention of environment variables: http://mesa3d.org/envvars.html

In both of these examples it's much clearer that an option is platform or driver specific. Similarly, I think we should make driver-specific options more explicit. Like...
    <some_mir_server> --driver android --android-opts ...
or
    <some_mir_server> --driver mesa-kms --mesa-kms-opts vt=1

Most importantly that means there is only _one_ option you need to look at to force the choice of graphics driver (--driver). Or if that's not provided then auto-detect. As an added bonus, my proposal also means that each driver does not need to be coupled to the ugly options interface, but instead just gets an option string of its own interpretation. It would also be a bonus if we went back onto the path of supporting graphics drivers written in C without requiring C++ from everyone (which limits driver compatibility).

But now I've proposed that what we have already needs to be changed too... More pragmatically I think there should only be one single server option to force the choice of graphics driver. It should not be implied by context. Once that is in place, it would syntactically not be possible to have the ambiguous:
    env DISPLAY=:0 <some_mir_server> --vt 1
because it would be replaced by:
    env DISPLAY=:0 <some_mir_server> --driver kms --kms-opts vt=1
which unambiguously selects KMS over X11.

review: Needs Fixing

« Back to merge proposal