[Bug 82619] New: [regression] recent ABI changes in xorg-video-intel (intel_drv.so) breaks dual-head XBMC

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82619

          Priority: medium
            Bug ID: 82619
                CC: intel-gfx-bugs at lists.freedesktop.org
          Assignee: intel-gfx-bugs at lists.freedesktop.org
           Summary: [regression] recent ABI changes in xorg-video-intel
                    (intel_drv.so) breaks dual-head XBMC
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: martin.x.andersen at gmail.com
          Hardware: Other
            Status: NEW
           Version: XOrg CVS
         Component: DRM/Intel
           Product: DRI

[This bug has been confirmed with the XBMC devs, and works on non-Intel
hardware. It appears to have been introduced some time after the 2.21.9 version
of the Intel Xorg driver. Versions after this are locked to using XBMC on 0,0
coordinates (left output) and the functionality is thus severly impaired.]

The scenario: running a dual-head setup with XBMC on the second display causes
it to output on the main screen regardless of which graphics port it is set to
output to.

I've done extensive testing on four different systems to try to get to the
bottom of which component introduced this. I have ruled out Window-managers,
libva, mesa and libdrm. That leaves the Xorg intel driver (intel_drv.so) from
xserver-xorg-video-intel / xf86-video-intel or the X server itself. 

However, since I witnessed the same issue after compiling recent versions of
libdrm2, libva and xserver-xorg-video-intel without upgrading the X server,
Xorg itself does not seem to be at fault.

Current test system #1 (Haswell, i7-4765T):

- xorg-server 1.15.2-1
- lib32-libdrm 2.4.56-1
- libdrm 2.4.56-1
- xf86-video-intel 2.99.912-2
- lib32-mesa 10.2.4-1
- lib32-mesa-demos 8.2.0-1
- mesa 10.2.4-1
- mesa-demos 8.2.0-1

vainfo from the same system:

vainfo: VA-API version: 0.35 (libva 1.3.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 1.3.2
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :    VAEntrypointVLD
      VAProfileMPEG2Simple            :    VAEntrypointEncSlice
      VAProfileMPEG2Main              :    VAEntrypointVLD
      VAProfileMPEG2Main              :    VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:    VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:    VAEntrypointEncSlice
      VAProfileH264Main               :    VAEntrypointVLD
      VAProfileH264Main               :    VAEntrypointEncSlice
      VAProfileH264High               :    VAEntrypointVLD
      VAProfileH264High               :    VAEntrypointEncSlice
      VAProfileVC1Simple              :    VAEntrypointVLD
      VAProfileVC1Main                :    VAEntrypointVLD
      VAProfileVC1Advanced            :    VAEntrypointVLD
      VAProfileNone                   :    VAEntrypointVideoProc
      VAProfileJPEGBaseline           :    VAEntrypointVLD

I've also tested this on Ivy Bridge, Haswell and on Sandy Bridge systems using
various combinations of HDMI, VGA, DVI & DisplayPort outputs. They all behave
the same, regardless of distro (Ubuntu/ArchLinux) and kernel versions.

The 'last known good' config is as follows: (this is from a Ubuntu 13.04 system
running a 3.16.0 kernel)

- i965-va-driver_1.2.1-1
- libdrm2_2.4.46
- libva1_1.2.1-1
- xserver-xorg-core_1.13.3
- xserver-xorg-video-intel_2.21.9

I would be more than happy to provide any extra input, or test patches for this
issue. It should however be easily reproducible on any multi-headed system
using the built-in/on-CPU graphics.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140814/0bdc70e8/attachment.html>