Bug 63812

Created attachment 78343 [details]
weston.ini

On the flip-side, if LVDS+HDMI or LVDS+VGA displays are both "on" then Weston-DRM works as expected... that is, a desktop is visible/rendered on both displays.

I've believe i've isolated this problem to:

commit e5a1225bc436f86b5241152bb332014d64f5b446
Author: Jonas Ådahl <jadahl@gmail.com>
Date:   Fri Apr 5 23:07:11 2013 +0200

    Make backends always specify output repaint time
    
    Most backends relies on gettimeofday(2) for output repaint timestamps
    but this is not a requirement. Before this patch repaints coming from
    idle_repaint() always used gettimeofday(2) for timestamps. For backends
    not using that time source this could cause large jumps between
    timestamps.
    
    To fix this, timestamps needs to always come from the backend. This
    means that the backend needs to always be responsible of starting the
    repaint loop in case that the repaint cannot start immediately.
    
    The drm backend implementation is from the patch by Ander Conselvan de
    Oliveira found here:
    http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
    
    Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

Reverting this change lets you use the weston.ini as you expect.

Reverting this patch fixes it for me.

(In reply to comment #3)
> I've believe i've isolated this problem to:
> 
> commit e5a1225bc436f86b5241152bb332014d64f5b446
> Author: Jonas Ådahl <jadahl@gmail.com>
> Date:   Fri Apr 5 23:07:11 2013 +0200
> 
>     Make backends always specify output repaint time
>     
>     Most backends relies on gettimeofday(2) for output repaint timestamps
>     but this is not a requirement. Before this patch repaints coming from
>     idle_repaint() always used gettimeofday(2) for timestamps. For backends
>     not using that time source this could cause large jumps between
>     timestamps.
>     
>     To fix this, timestamps needs to always come from the backend. This
>     means that the backend needs to always be responsible of starting the
>     repaint loop in case that the repaint cannot start immediately.
>     
>     The drm backend implementation is from the patch by Ander Conselvan de
>     Oliveira found here:
>    
> http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
>     
>     Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
> 
> Reverting this change lets you use the weston.ini as you expect.

This happens on VMware as well and I confirm that reverting e5a1225bc436f86b5241152bb332014d64f5b446 makes everything working.

commit 95eb3a2eb470bd341ab078c7e48a28ffebc6dde1
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue May 7 14:16:59 2013 +0300

    compositor-drm: Don't page flip before a mode is set
    
    The function drm_output_start_repaint_loop() unconditionally issues a
    page flip, even if the crtc for that output has not been enabled yet.
    That causes the page flip to fail, and drm_output_repaint() is never
    called.
    
    Solve this by bypassing the initial page flip if the output needs a
    mode set.
    
    This has the caveat of affecting latency predictability for that first
    frame and when a "driver" mode fullscreen surface causes a mode set.
    However, on both cases the mode set would take an unpredictable amount
    of time anyway.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=63812
    https://bugs.freedesktop.org/show_bug.cgi?id=64183