[BrentNewland]

I just tried to set this up in our store today. We need to run 20 monitors and 4 televisions off of our computer (since the VGA splitter box for the televisions doesn't support component>vga adapters, and we can't get any blu-ray players with vga ports). I figured it would be no problem, just get ultramon and XBMC. Ultramon would run the screensaver on the 20 monitors and XBMC would run on the TV's. The monitors run at 1440x900, the TV's at 1280x768.

No go. No amount of fiddling would get XBMC to fit the 1280x768. Even modifying the windowed mode shortcut to jump to the other monitor and maximize didn't work, it was still set at 1440x900.

Perhaps a simple setup script included with XBMC that lets you choose which display it should operate on would work? It would have looked really nice having XBMC on all our TV's, but it'll just have to wait.


For anyone interested, I ended up having MPlayer Classic open up a folder of 720p videos and play them all forever in random order. I then somehow made the screensaver run on the monitors at the same time (which I still don't understand).

[marirs]

perhaps this patch could be added in, until work on the multidisplay branch is finished?

[rmauchel]

Why not just check with the team working on Boxee, which is based on XBMC?

They've already addressed this issue in, if I'm not mistaken, commonly available lower level code that would (hopefully) only require updating XBMC's UI.

See below for further details:

http://www.boxee.tv/download/relnotes?ver=0.9.14
http://forum.boxee.tv/showthread.php?t=9...tor&page=3
http://forum.boxee.tv/showthread.php?t=4...tor&page=2

[CapnBry]

I think they just use a modified version of my patch (which will no longer apply due to how XBMC probes nowdays, but is trivial to fixup). Really multimonitor support should be better integrated, which was the goal of the multidisplay branch that never got beyond creating the branch.

If the project managers decide they want to use the code from #5110 as an intermediate solution, I'd be willing to bring it up to date.

[WiSo]

Please do so as I don't think we'll re-factor the resolution system soon as no one wants to touch it

[CapnBry]

Dammit Wiso, did you just trick me into fixing something? You clever bastard!

[WiSo]

strike
You give me a finger - I take the whole hand

[rausch101]

I was struggling trying to get XBMC to launch on a second monitor through a remote control (Harmony) input over the weekend for someone that hated UltraMon and didn't want to use it (although I have nothing against it). For anyone who is interested, here's what I did:

I used EventGhost to take the IR input to absolute move the mouse to the top left of the primary screen (0,0), since absolute mouse movement can only take place on the primary display. I then relative moved the mouse to the XBMC shortcut icon that I had placed on the second screen and simulated a double-click. Since the shortcut to XBMC is located on the second monitor, XBMC is then launched in the second monitor (either fullscreen or windowed). It's about as crude as it gets, but it works well as long as the icon doesn't move.

[AlexW]

Any news yet? I'm looking forward to be able to start xbmc on my secondary monitor in 'real fullscreen'. When I use UltraMon xbmc has black bars (about 20pixel thick) at the top and left side. Moving the screen in Video Calibration doesn't work... the black bars are still there.

[CapnBry]

Wiso, I've posted a new patch to the ticket but I'd like to point out a few things:

1) Every time someone touches this code, it gets uglier.

2) Adding this code may change some win32 users' resolution the next time they start up. This is because XBMC stores only the index of the selected resolution and this may reorder some items in the list

3) The amount of resolutions offered in Settings -> Appearance -> Screen is now in the realm of "staggering". My 2 monitor system has 143 resolutions. That's just awful.

4) Resolutions which are not on the default monitor are listed is (DISPLAY x). Note that DISPLAY 0 is not necessarily the primary display.

5) For backward compatibility, when changing resolution to "Primary Display, Resolution XxY", XBMC resizes the window on the current display instead of shifting it to the primary. If shifting back to Primary makes more sense, change CSurface::ResizeSurface to not do GetWindowRect(hwnd, &rBounds), just always use the code above it.

6) Don't think I'm going to get involved in this discussion again, I'm not working on the multimonitor branch!

EDIT: for BOLDing

[WiSo]

1) I know and therefore I don't touch it anymore
2) Ok, I would be fine with it. Once I've started to look into getting rid of the index numbers and work with resolutions strings but it involved too much changes which I don't wanna do.
3) Yeah it was already awful. Maybe we can rearrange stuff to get on option box for the resolutions and one for the refresh rate? as said you're already deeper into this topic than I'm
6) Thats a pitty. Dunno if the multi monitor branch is still worked on. But I understand the decision.

Thanks for the help anyway. "Unfortunately" I've started a new job in a new town this week and have only partly time for doing XBMC things. Not sure if I can spent time on it soon, sorry :/

[jmarshall]

We chatted about this at devcon. The system that I think we'd like to see is:

1. n+1 resolution options available, where n is the number of screens, and the +1 is for windowed.
2. Display at the native resolution of the screen.
3. Windowed mode is resizable in the normal manner.
4. If anyone wants anything else, make a custom setting that they configure themselves in advancedsettings.xml.

@CapnBry: Is the above plausible (excluding all the current cruft in the code ofcourse)?

Cheers,
Jonathan

[davilla]

I nuked multidisplay because it was so far out of date. Maybe I should branch again so we can attempt this again.

[CapnBry]

@CapnBry: Is the above plausible (excluding all the current cruft in the code ofcourse)?

You know, that's actually incredibly simplified but I think it covers what most people want and for the rest we'll have to figure out what goes into advancedsettings.xml. Plus it gets rid of overscan settings on windowed resolutions which drove me batty.

I have 2 "what about?"s Actually, after I wrote them out I'm just going to keep my mouth shut because they'd fit into the advancedsettings concept and I don't want to turn this into a discussion thread.

The main issue would be synchronizing all platforms simultaneously to this new system, especially XBOX which would ... probably still use the old system?

EDIT: But you asked about the feasibility of implementing it as you described and I went off on a tangent. On Win32, the implementation is trivial once the cross-platform bits are complete.

[jmarshall]

Yup - we love the simple, and I really think (especially with most TV devices actually having a fixed native resolution) that it is everything most people need.

XBox is kinda a different beast, but as you suggest, it's irrelevant for this discussion - it's code would stay as-is.

IMO start with a blank slate, don't reuse the existing resolution stuff at all, and reimplement it from scratch

Cheers,
Jonathan