[Drag0nFly]

[If there are any others on here successfully using a dual-display on Intel hw with a recent distro, i.e, a desktop on one output + XBMC on the other–please give a shout out, as I've been trying to get this working for the better part of a week on numerous different installations and intellinux/01.org driver version combinations]

First off: I am not 100% certain that this is actually related to a fault in XBMC. So far, it appears to be related to the recent ABI changes in Xorg or a change in Intel's drivers. Especially since this works _perfectly_ on 13.04, using exactly the same (and current) XBMC versions I've tested (both mainline and FernetMenta's branches.)

In any case, I am trying to get to the bottom of exactly which component is causing this. So far, I've ruled out libva/libva-intel-driver, and also, most likely, libdrm.

Testing older versions of the driver components have proven to be a real *PITA*, as they are closely linked wrt. functionality. I had initially suspected the 'xserver-xorg-video-intel' (intel_drv.so) or xorg itself as being the culprit, but I haven't been able to verify this, as running an older Xorg with current drivers is impossible due to the recent ABI changes. For the record, the last known good version of xserver-xorg-video-intel (xf86-video-intel on Arch) is 2.21.9.

I am really struggling to figure out what is causing this, and specifically, where (and to whom) any bug report can be filed.

DE-specific issues have been ruled out completely. The error exists on all environments I've tried:

- IceWM
- Cinnamon (which works perfectly on 13.04)
- Fluxbox
- XFCE4
- Unity
- Mate
- Gnome
- etc.

When changing video output ports, it lists the second output, changes to it (presumably successfully as far as XBMC is concerned), and displays the output on the same port as what was initially used. When selecting 'blank other displays', it blanks the primary display(!), but still does not change the display to the port selected.

I've 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.

[fritsch]

Looks like a regression in 12 days old(!) xorg 1.16 - if upstream change breaks behaviour a bug needs to be filed upstream.

[Drag0nFly]

Definitely a regression, yes. However, I first observed the issue on Ubuntu 13.10 (Xorg 1.13.3), so any introduced breakage has to have been included prior to the 1.16 release.

[fritsch]

mmh - did you test on non intel hardware? Mordor turned its eye onto Intel lately ...

[Drag0nFly]

No, "only" four different Intel systems. Problem is that most of the machines I now have on-hand do not have a PCI-e slot to pop in an Nvidia card. I *am* pretty sure that this only affects Intel, though. Otherwise it would (should) have been more widely reported.

However, if you saw how well XBMC was running on my tiny i3-3225 you'd want this fixed asap as well (Sauron interference or not...)

[wsnipex]

heh, must have been a major PITA to test all this, kudos for that.

[FernetMenta]

I haven't tried this in a while but I remember issues on Intel. iirc full screen was only possible on the left output which has coordinates 0,0.

[Drag0nFly]

@wsnipex: pretty much, yes. But hopefully we'll get to shed some light on it.

@FernetMenta: hmmm.. interesting. _Especially_ since I've always tested XBMC on the "right" display. (where is that head-slap smiley?)
Will swap these around when I get to test this again tomorrow and see if that makes a difference. It would be quite interesting, if not criminal, if that actually fixed it. ;D (ugh)

[black_eagle]

Doubt its any help, but dual head working fine here with stock Ubuntu 14.04/nVidia 9800GT.

Code:

nVidia driver Version : 331.38
Server Version Number:11.0
Server Vendor Version:1.15.1 (11501000)

PPA - ppa:aap/xbmc-release-fernetmenta

https://launchpad.net/~aap/+archive/ubun...ernetmenta

Actually, swapping leads proves triple head works fine - two outputs from the 9800GT & one from the onboard (also nVidia).

XBMC normally runs on the 'left' but the onboard is to the 'right' of the desktop. All displays work correctly.

XBMC version is 13.1-BETA1 Git:Unknown

FWIW

[Drag0nFly]

@black_eagle: thanks for verifying-at least we know for sure that nVidia is unaffected (although I had strong suspicions about this). I'll do some further tests tomorrow regarding the screen/output orientation issue on the Intel box to see whether it makes a difference.

[Drag0nFly]

I was able to launch XBMC on the secondary (or is that primary? ) display now when moving it to the left. However, XBMC still thought it was running on the VGA port, whereas it actually was on the DisplayPort.

The solution wasn't stable, though. As the moment you tried to actually use the prim^H^H^H^H secondary display XBMC either gets minimized or both screens freeze. When switching off the monitor running XBMC it gets cleared again. This appears to be related to the GPU hangs which has recently been seen in Intel's drivers. (This is on Haswell, btw., with kernel 3.15.6)

[Fri Aug 1 10:24:07 2014] [drm] no progress on blitter ring
[Fri Aug 1 10:24:07 2014] [drm] GPU HANG: ecode -1:0x00000000, reason: Ring hung, action: reset
[Fri Aug 1 10:24:09 2014] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[Fri Aug 1 10:24:11 2014] [drm] GPU HANG: ecode -1:0x00000000, reason: Kicking stuck wait on blitter ring, action: continue
[Fri Aug 1 10:24:15 2014] [drm] GPU HANG: ecode -1:0x00000000, reason: Kicking stuck wait on blitter ring, action: continue
[Fri Aug 1 10:24:19 2014] [drm] GPU HANG: ecode -1:0x00000000, reason: Kicking stuck wait on blitter ring, action: continue
[Fri Aug 1 10:24:23 2014] [drm] GPU HANG: ecode -1:0x00000000, reason: Kicking stuck wait on blitter ring, action: continue

I've already reported this issue on freedesktop.org-> Intel/DRM, as I see it in the kernel log for my Ivy Bridge. Although I haven't (yet) noticed it as having an impact when viewing on XBMC. It appears to have been introduced in >3.15.

However, regarding the screen orientation issue: I assume this was not reported to Intel when it was noticed? Obviously, even if XBMC had worked properly on the primary display, the functionality of the second (desktop screen) gets reduced, as most apps do not like to be started on the secondary screen. There's also the menu bar, etc., which is tied to the primary unless of course you do some intricate changes to your DE(s).

I can report this if we are sure which component(s) is/are involved; if there is an old bug report that would be of interest as well.
The config on my 'good' Ivy Bridge system is as follows:

- 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

Again, I did get to test the older libva version on the test box, and it appears to be able to be ruled out. Most likely it is the intel_drv.so (xserver-xorg-video-intel) or the Xserver itself.

[FernetMenta]

Can you try my master with this fix: https://github.com/FernetMenta/xbmc/comm...6b27c3aa05
It uses XMoveWindow after mapping to force XBMC to the desired position.

[Drag0nFly]

Thanks for the update.
Compiling it now for testing. Btw, nice that some are still calling it 'XBMC' despite the Apr^H^H^H Aug 01 joke.

[Drag0nFly]

Hmm.. this fails during the linking stage with the following error originating from WinSystemX11GL–

LD xbmc.bin
xbmc/windowing/X11/windowing_X11.a(WinSystemX11GL.o): In function `CWinSystemX11GL:resentRenderImpl(std::vector<CDirtyRegion, std::allocator<CDirtyRegion> > const&)':
/home/xbmc/fernetmenta/xbmc/xbmc/windowing/X11/WinSystemX11GL.cpp:45: undefined reference to `CWinSystemX11::CheckDisplayEvents()'
collect2: error: ld returned 1 exit status
Makefile:531: recipe for target 'xbmc.bin' failed
make: *** [xbmc.bin] Error 1

[FernetMenta]

I have removed this code some weeks ago: https://github.com/FernetMenta/xbmc/comm...248b75d7c9

Did you reset to my current master?