unity-system-compositor crashes with: Output LVDS-1 has no associated CRTC to set a framebuffer on

Is this still hapenning with latest version of unity-system-compositor and Mir?

If so, can you try if lp:~afrantzis/mir/lp-1217877-possible-fix makes a difference?

I have created a package you can try for convenience:
$ wget http://people.ubuntu.com/~afrantzis/libmirplatform_0.0.10+13.10.20130904-0ubuntu2_amd64.deb
$ sudo dpkg -i libmirplatform_0.0.10+13.10.20130904-0ubuntu2_amd64.deb

To go back to the original version do:

$ sudo apt-get install libmirplatform=0.0.10+13.10.20130904-0ubuntu1

Ensure you set up lightdm to use Mir, and restart lightdm (see http://unity.ubuntu.com/mir/using_mir_on_pc.html)

Alexandros Frantzis: It seems that the crash not happening anymore.

> Alexandros Frantzis: It seems that the crash not happening anymore.

Hi manfreed, thanks for checking. Did you try with the version that is in the archive, or with the package with the proposed fix?

If you tried with the package with the proposed fix, could you also please try with the archive version to confirm that the fix actually helped?

Alexandros Frantzis:
I made a mistake, mir wasn't running before. With or without your package mir wont start, instead I get an X session. However based on the log I got I have new info

The log in /var/log/lightdm/unity-system-compositor.log:

ERROR: /storage/work/mir.bzr/lp-1217877-possible-fix/src/server/graphics/gbm/real_kms_output.cpp(189): Throw in function virtual bool mir::graphics::gbm::RealKMSOutput::set_crtc(uint32_t)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Output LVDS-1 has no associated CRTC to set a framebuffer on

 That last line is suspicious for me.

It seems that my laptop can't handle three displays at once. Usually I plug in two ext monitors, and use them without the internal one. But if I try to enable the internal while the other two is enabled I get a very weird error (screenshot is attached, the window was too big, and started to jump around half-freezing my computer, so I couldn't copy the contents properly).

Could the cause of this bug be that mir tries to start with both three displays? I am pretty sure that at least once mir run successfully, because it caused trouble, so I had to disable it then. Maybe at that time I started my computer without external monitors? I'm going to see if mir would run without ext. displays pluggged in.

So, the following happens:

a) Started without external monitors: Everything ok, mir runs

b) Started with only one monitor:
 - If I start with a monitor plugged in the hdmi port everything ok, mir runs.
 - If I use the VGA port I can only see a mouse cursor (on both displays), also I can't move it. Switching to vt1 and back produces a dialog stating that I'm running in failsafe mode.

Same happens when I start without ext displays and I try to plug them in later. If I use the HDMI port the display gets detected properly. But if I plug a monitor in the VGA port the failsafe mode starts. Mir doesn't seem to remember my configuration, it tries to turn on the internal display on (backlight turns on) even if it is disabled when I plug in the second external monitor.

c) Starting with two ext monitors: Everything seems to be ok, but no mir.

Fix committed into lp:~mir-team/mir/development-branch at revision None, scheduled for release in mir, milestone Unknown

This bug was fixed in the package mir - 0.1.0+14.04.20131028-0ubuntu1

---------------
mir (0.1.0+14.04.20131028-0ubuntu1) trusty; urgency=low

  [ Daniel van Vugt ]
  * Bump version 0.1.0
  * Add method for testing if Rectangle::contains(Rectangle), which is
    the basis of any occlusion detection. (LP: #1227739)
  * Add support for traversing the Scene from front surface to back.
    This is required for occlusion detection at least (coming soon). .
    (LP: #1227739)
  * Optimization: Turn off blending for surfaces that are not blendable.
    On some systems this can have a noticeable performance benefit.
  * Avoid rendering surfaces that are fully hidden by other surfaces.
    This is particularly important for mobile device performance. (LP:
    #1227739) . (LP: #1227739)
  * Remove orphaned tags, which appear to have come from the Compiz
    project (!?) Add tags for the most recent releases up to 0.0.16. No
    files changed, only tags.
  * Fix significant performance issues LP: #1241369 / LP: #1241371, and
    probably more(!) Added regression test to catch such regressions and
    revert the offending commit r1049. (LP: #1241369, #1241371)

  [ Brandon Schaefer ]
  * When Scroll events come in we don't keep around the android vscroll
    hscroll data. Store it now. (LP: #1233089)

  [ Albert Astals ]
  * Fix mismatched free() / delete / delete [] reported by valgrind

  [ Alexandros Frantzis ]
  * server: Extend server status (formerly pause/resume) listener to
    report "started" events This change is needed by users of
    libmirserver, so they can properly synchronize external interactions
    with the server. (LP: #1239876)
  * graphics,examples: Don't enable more outputs than supported when
    changing the display configuration. (LP: #1217877)
  * client: Allow clients to call API functions after a connection break
    has been detected When a client tries to call an API function after
    a connection break has been detected in a previous API call, the
    client blocks in the new call. This happens because in
    MirSocketRpcChannel::notify_disconnected() the pending RPC calls are
    not forced to complete, since the channel has already been marked as
    'disconnected' by the failure in the previous call. Note that if the
    break is first detected while calling an API function, then that
    call doesn't block, since this is the first time we call
    MirSocketRpcChannel::notify_disconnected() and the pending RPC calls
    are forced to complete. This commit solves this problem by always
    forcing requests to complete when a communication failure occurs,
    even if a disconnection has already been handled. This is preferred
    over the alternative of manually calling the completion callback in
    a try-catch block when calling an RPC method because of: 1.
    Correctness: In case the communication problem first occurs in that
    call, the callback will be called twice, once by
    notify_disconnected() and once manually. 2. Consistency: The
    callback is called from one place regardless of whether the
    communication problem is first detected during that call or not.
    (LP: #1201436)
  * graphics: Improve si...