Bug 63812 - queueing pageflip failed: Device or resource busy
Summary: queueing pageflip failed: Device or resource busy
Status: VERIFIED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-22 18:25 UTC by U. Artie Eoff
Modified: 2013-05-16 02:00 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
weston drm run time output (4.85 KB, text/plain)
2013-04-22 18:25 UTC, U. Artie Eoff
Details
weston.ini (1.23 KB, text/plain)
2013-04-22 18:26 UTC, U. Artie Eoff
Details

Description U. Artie Eoff 2013-04-22 18:25:00 UTC
Created attachment 78342 [details]
weston drm run time output

On a multi-head LVDS+HDMI or LVDS+VGA setup and configuring LVDS mode to "off" in weston.ini, Weston-DRM generates the error "queueing pageflip failed: Device or resource busy", and doesn't display anything on the connected HDMI/VGA display.

See attached weston.ini and attached Weston run-time output.

System
----------
Hardware: Samsung NP530U4CL Ultrabook w/LVDS display panel
Display HDMI: Samsung SyncMaster P2770
Display VGA: Samsung SyncMaster B2330
OS: Fedora 17 x86_64
Kernel: 3.5.5-2.fc17.x86_64
wayland: (master) 1.1.0-0-ge593832
drm: (master) 2.4.44-0-g9768af2
macros: (master) heads/master-0-gc98b41d
glproto: (master) heads/master-0-g8e3407e
dri2proto: (master) heads/master-0-gead89ad
mesa: (master) heads/master-0-gdbb6908
kbproto: (master) heads/master-0-gf7022f5
libX11: (master) heads/master-0-gf49bb2d
libxkbcommon: (master) heads/master-0-ga392d26
pixman: (master) heads/master-0-g9d0bb10
cairo: (master) heads/master-0-g498421b
weston: (master) heads/master-0-g2e43720
Comment 1 U. Artie Eoff 2013-04-22 18:26:05 UTC
Created attachment 78343 [details]
weston.ini
Comment 2 U. Artie Eoff 2013-04-22 18:45:22 UTC
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.
Comment 3 Rob Bradford 2013-05-03 17:52:39 UTC
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.
Comment 4 U. Artie Eoff 2013-05-06 14:32:41 UTC
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.
Comment 5 Pier Luigi Fiorini 2013-05-07 06:10:33 UTC
This happens on VMware as well and I confirm that reverting e5a1225bc436f86b5241152bb332014d64f5b446 makes everything working.
Comment 6 Kristian Høgsberg 2013-05-15 02:31:57 UTC
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


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.