multi-screen: ability to wait for configured ouput on display reset events

[flaterichd]

The new screen selection ability is great, however I encountered several issues with my hardware.

I have media center PC connected to Onkyo 706 Reciever -> Pioneer Plasma TV.

The media center has two Nvidia cards. The first one is older onboard video (GeForce 9400 mGPU) connected to a small LCD display on the case (1024x768). I also have a separate NVidia PCIe card (GT 610), which is connected to receiver and TV.

My X is configured as separate screens. Previously I used export DISPLAY trick to load XBMC on the second X screen, which is my receiver and TV.

Now it is possible from inside XBMC, but with following issues:

• If I switch off the TV and receiver, XBMC automatically switches back to the small LCD display and saves settings.
• If I switch off TV, or switch on TV the receiver seems to switch HDMI port internally, which causes display reset event and once again XBMC reconfigures and saves small LCD screen as default.
• If both TV and receiver are on, and XBMC is off and receiver is set on a different input (for example PS3), when XBMC switches on and CEC adapter asks receiver to switch to XBMC input, in about 25% of cases this causes a device reset event, and XBMC switches to LCD screen.

I managed to solve the saving of different display by using advancedsettings.xml override. However this only partly solves the problem, as XBMC still switches to LCD until restart.

I attempted to solve this by adding two additional advancedsettings.xml options.

monitorwaitsec - number of seconds to wait for output configured, before trying to switch to a default screen. If set to 0 - will wait indefinitely.
monitorwaitexit - if timeout above passed and configured output was not found, exit XBMC instead of trying to find default screen. This is useful when you have XBMC restarter script in a loop.

I haven't really developed in C++ or for XBMC, so I am not sure how good this fix is. I tried all different combinations and it seems to work, solving all my problems above. Let me know if you want to pull this, or may be you want me to change something?

[flaterichd]

Section from my advancedsettings.xml

<videoscreen>
    <monitor>HDMI-0</monitor>
    <monitorwaitsec>0</monitorwaitsec>
    <monitorwaitexit>false</monitorwaitexit>
    <resolution>16</resolution>
    <screen>1</screen>
    <screenmode>DESKTOP</screenmode>
    <vsync>2</vsync>
</videoscreen>

[FernetMenta]

nice, I haven't tested this after the refactoring of settings. How about not saving the fallback monitor to settings? Then it should switch automatically back to configured monitor on next xrandr event. Requires some changes in WinSystemX11 to use fallback when reading current monitor from settings.

[flaterichd]

Sounds like it could also work. But when I analysed the logs, it seems that only one display reset event is triggered in some cases. I think that was in case when my receiver was switched to a different input. It takes it about 500ms to switch in some cases, this caused display reset event, but only once. With you approach it would switch to LCD screen, and then it would only switch back to TV after XBMC restart (in my case).

But I am willing to test, if you will create a branch (I am not sure how to implement the settings thing right now).

[flaterichd]

other issue, moved here: #120

[flaterichd]

BTW I can't really use latest master (the one I did merge request) in production, as half of the settings are missing. I guess its due to the XML settings refactorings in commits.

But I can test any branch if you want, re multi-screen issues.

I am using currently your April version in production with vnsi4 and its very stable! :)

[FernetMenta]

as half of the settings are missing

did you notice the different levels? in order to see all settings you have to switch to advanced or expert (the blade on the left)

[flaterichd]

Oh cool, didn't notice it! Will do tonight after work! :) Thanks

[flaterichd]

just quick heads up, tested latest master (I guess its the one after refactoring of settings), and it works in the same way as previously (without my patch).

Thinking about it, I am not sure if you idea would work though. When I set monitor and screen in advancedsettings.xml, it behaves in the same way as not writing the screen setting, doesn't it? And this did not solve my problem, as it did not switch back to select output, once it goes back up.

I double checked and the issue where my receiver is set to a different output, only generates 1 display reset event, so basically even if you don't write the setting, it will still switch to LCD and will not switch back to HDMI-0. On the other hand side if you have at least 500ms delay before checking for "out" here https://github.com/FernetMenta/xbmc/blob/master/xbmc/windowing/X11/WinSystemX11.cpp#L259, then it works.

In any case I will use my patch for now, on top of your master tree. I am willing to test your fixes, if you want.

[FernetMenta]

Could you place a debug log here: https://github.com/FernetMenta/xbmc/blob/master/xbmc/windowing/WinEventsX11.cpp#L568 just to make sure that the xrr event is not ignored by the check of serial.

[flaterichd]

It does seem that only one event is generated. Also the behavior changed slightly, I guessing this is because of the iScreen patch you made to ignore screen number for X11.

So previously it switched to LCD screen. Now it switches to LCD screen, and after about 2-3 seconds puts XBMC on back on the plasma screen, with LCD's resolution. So it looks like a small squashed XBMC in top left corner. It kind of looks like it thinks it is still on the LCD. Although this could be related to my video settings being specified in advancedsettings.xml (see at the top of the log).

Log1: receiver and TV are on, XBMC is off. Receiver is set to different input. I switch on XBMC (well actually the PC is resumed from suspend, which also restarts lightdm on resume). This happens in about 25% of cases.
http://pastebin.com/FabgzGDT

Receiver, TV and XBMC are on. I switch off receiver, which basically switches HDMI port to pass through directly to TV. (With the patch in my pull request, it takes about 300-500ms of waiting for the HDMI output to be back). This happens in 100% of cases.
http://pastebin.com/3z3AcJ8h

[flaterichd]

Ok I removed my advanced setting and tried again.

Still behaves in the same way, appears briefly on LCD, the appears squashed on TV. Now if I try to go o settings/system/video, it immediately switches back to LCD and asks me if I want to accept the new resolution.

I have not pressed anything and after about 10 sec timeout, XBMC crashed.

Log:
http://pastebin.com/9K34Eaqx

[FernetMenta]

After the refactoring of settings storing a new value to monitor triggers a yes/no dialog. Can you see it? (if not there's something additional wrong) If the user does not confirm the setting it will be reverted after a couple of seconds. Means I have to change this anyway.

[FernetMenta]

Could you try current master. Now the user selected monitor won't get overwritten with the fallback. It may still not cure the missing xrr event.

[FernetMenta]

I would like to get this fixed without the need of an advanced setting. Most users don't even know the documented settings and would hardly know the ones introduced in my branch.

[FernetMenta]

In case we don't find a solution and the polling loop is the only way to solve this, I have no problem with hardcoding a timeout of one or two seconds.

[flaterichd]

After the refactoring of settings storing a new value to monitor triggers a yes/no dialog. Can you see it? (if not there's something additional wrong) If the user does not confirm the setting it will be reverted after a couple of seconds. Means I have to change this anyway.

Yes I did see it, as I said, after I have not replied, XBMC just crashed.

Could you try current master. Now the user selected monitor won't get overwritten with the fallback. It may still not cure the missing xrr event.

I will do.

I would like to get this fixed without the need of an advanced setting. Most users don't even know the documented settings and would hardly know the ones introduced in my branch.

This sounds reasonable and I agree.

In case we don't find a solution and the polling loop is the only way to solve this, I have no problem with hardcoding a timeout of one or two seconds.

I was thinking of the same thing. Hardcoded timeout of 2-3 seconds would solve 99% of cases, and it will also fallback to a default screen, which is definitely useful behaviour for most users. But lets see if you current master changed anything. The next time I will be able to check is probably tomorrow.

[flaterichd]

Hmmm, why does it say that I want to merge 112 commits? I am sure it was only one :)

Updated: I am guessing, it is because you rebase your rep...

[flaterichd]

Ok I have tested the latest master. Works better now. It automatically switches to LCD if I switch of receiver as before and as expected it does not return to TV if I switch it back on. However now, if I restart XBMC it goes back to the TV.

If I am not in settings, it doesn't ask me if I want to save new resolution. If I am in Settings/System/Video, then after switching to LCD it asks me if I want to save current resolution. If I click "Yes" then it saves the settings, as expected. If I click "No" or wait for timeout it still crashes, which I guess needs to be fixed. The log is the same as above, the last line is "CRenderManager::UpdateDisplayLatency - Latency set to 0 msec".

[flaterichd]

So I guess I loop with timeout will still have to be implemented, as my use case still fails.

Furthermore I would set default timeout to 1-2 seconds, but leave ability to specify longer timeout in advacedsettings. Let me explain why.

In my setup when everything is off, I switch on both PC with XBMC and TV using MCE Remote (two power buttons). I cannot predict in which order they will be switched on. Also to save power my TV switches on receiver using one of those master/slave power extensions.

Basically it it takes about 5 sec for TV to switch on, and then another few seconds for receiver to be power. The whole process takes about 10 sec, so if you switch on XBMC and other equipment at the same time, when everything boots up, XBMC will be on the LCD screen. This is the reason I made the patch in the first place :), as otherwise you have to be very careful of the order in which you switch on the equipment and WAF is near 0 :)

[FernetMenta]

The problem with advanced settings is that nobody knows about. Even if we had this setting, the majority of users would not benefit from. Another idea: we could poll xrr resolutions for a change (every 1 or 2 secs) when not running on desired output and don't play video. That may cure the issue for AMD systems where we don't even get the event when pulling out the HDMI plug.

Currently I don't have connected my 2dn monitor which is an old and heavy CRT.

[flaterichd]

The problem with advanced settings is that nobody knows about.

Thats why I offered the default of 1-2 seconds. Or do you mean if someone will need a longer timeout?

Another idea: we could poll xrr resolutions for a change (every 1 or 2 secs) when not running on desired output and don't play video.

This is how I though it should be implemented initially (always switch back to preferred output, if it reappears), but I didn't know much (and still don't) about XBMC's and X11 inner workings to implement that.

However thinking about it, we would still have to have some kind of 1 sec pause before checking for out, otherwise it would just just between screens. For example, when you switch off receiver it would switch to LCD for 1, then back to TV 2 seconds later.

[flaterichd]

Thinking about your idea, it does sound like the best approach.

If monitor is disconnected, we wait for 1 second and check if it reconnected.
If it is not, we switch to default screen, but do not save settings, unless user is in video settings (still need to fix crash btw).
A polling mechanism is launched if the current monitor is not the one in settings, if output found, we switch back to it automatically.

No need for advanced settings at all then.

[FernetMenta]

yes, let's go for this. We can even wait for 2 or 3 seconds before taking the fallback monitor. I have no receiver so would be great if you could figure out a timeout appropriate for most cases.

[FernetMenta]

the crash was fixed in mainline today.
I have implemented the polling and adopted your changes: ced3a56a9dcd7b090d5777845476035dd14df2ba

[flaterichd]

Ok I will test this right now and post back.

Re timeouts, if we are talking simply about switching receiver on off and keeping TV on, it takes at most 500ms.

My worst case is around 10 seconds, but this is very specific to my setup. Once my TV boots up, the master/slave extension lead detects high current and switches slave power plugin, which gives power to my receiver, and then TV also sends CEC signal to power the receiver. So this takes a very long time, and I presume it is specific to my case, so I can live with XBMC switching to LCD and back.

3 seconds sounds more that enough. I will test this out, if the lag is not noticeable in simple cases, lets just leave it at that.

[flaterichd]

This patch is absolutely perfect! 👯

It solves all of my use cases. The timeout seems to be just perfect as well. Seems instant (my TV takes about the same time to switch resolution etc).

The crash was also resolved, as you said.

I think we can close this one.

[FernetMenta]

Thank you very much for working with me on this. I think this is really an improvement. Looking forward to hearing again from you.
I just fixed a potential segfault when switching outputs -> you should update.

Could you also have a look at the new setting I did on request of #100

[flaterichd]

#100 sounds interesting, I will check it out. I saw an option to blank display, tried it and it didn't work. This seems to be something different.

Thanks for fixing this. You will definitely hear more from me, since your branch is in production on all 3 media pcs here :) I still cannot believe how stable this is for an alpha! :)