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
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
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.