Design issue? Assumption in code doesn't seem to be true... (1 Viewer)

[MrINTJ]

MP2 Version

Before you create this bug report:

1. Make sure that your system (Windows, codecs and drivers) is up to date, matching the Requirements and you've filled in your System Specs.
2. Have a look at our MediaPortal Wiki! Maybe the solution is already there.
3. Have a look at our Jira (Bug and Issue Tracker)and the threads in this section, maybe your problem is already known.
4. Search the forums for your problem, it's very likely that someone else already encountered the same problem.

Please always include log files with your Bug Report!
Check out our Wiki: Bug Reports and Log Files

==================================================================

Describe the Problem you encounter as detailed as possible! "It does not work" won't help the team to understand the problem.
Description:

I noticed on github.com that in MediaPortal-2/MediaPortal/Source/UI/Players/RefreshRateChanger/RefreshRateChanger.cs, there seems to be an assumption that the source and target of each path will appear at adjacent indices in _modeInfoArray, e.g. around line 402:

402:        var modeIndex = _displayIndex * 2; // Array always contains "Source" and "Target" per display

This is generally true, but not always. Specifically, when a display is configured to duplicate another display (rather than extend the desktop).

For example, with three GDI displays mapped to three different monitors, you'll get this from QueryDisplayConfig():

PathIdx | SrcModeIdx | TgtModeIdx
---------+------------+------------
0 | 1 | 0
1 | 3 | 2
2 | 5 | 4

...but if you set the second monitor to duplicate the first (primary) display, you get this:

PathIdx | SrcModeIdx | TgtModeIdx
---------+------------+------------
0 | 1 | 0
1 | 1 | 2
2 | 4 | 3

Note that the duplicating display also messes up the [target, source] ordering assumed by the current code.

You should be able to confirm this by testing on a system with multiple monitors (two or more), and using Display settings to configure the second display to Duplicate the first (primary) display. If you then run the RefreshRateChanger code, you should see an issue.

Sorry I don't just submit an MR myself, but I'm not a regular contributor; just happened to spot this while browsing and thought you'd want to know.

-MrINTJ

Describe as detailed as possible the steps that are required to encounter the issue. This info is critical for the team to understand the problem.
Steps to Reproduce:







.

 

[ge2301]

@morpheus_xx @Brownard @henso

 

[Brownard]

This is generally true, but not always. Specifically, when a display is configured to duplicate another display (rather than extend the desktop).

Thanks for the report. I'm not really up to speed on how the results of QueryDisplayConfig should be interpreted, do you have some experience with it? We currently get the index of the screen that MP2 is being displayed on by checking for the index of the screen in System.Windows.Forms.AllScreens, do you know if that will be the same index in the pathArray returned in QueryDisplayConfig? If so, is it then just a case of reading the correct modeInfoIdx from the source and target info contained in the path info at that index?

Edit: looks like the indices in the System.Windows.Forms.AllScreens array and pathArray are not necessarily comparable (and that AllScreens is not necessarily in any particular order in general) so I need to find a way of linking them, possibly with a call to DisplayConfigGetDeviceInfo

 

[Brownard]

@MrINTJ @morpheus_xx I have pushed changes to MP2-877_Improve_refresh_rate_changer_display_selection.
Previously we were assuming the ordering of Forms.AllScreens was equivalent to the ordering of the display info returned in QueryDisplayConfig in addition to the assumptions of the ordering of the mode infos pointed out above. I expect this assumption is generally true but not guaranteed as the results of QueryDisplayConfig can change when the screen configuration changes, whereas the Forms.AllScreens array is created once when first referenced and not updated after that. What I've done instead is use the DeviceName of the current forms screen, then this can be mapped to a device interface name through EnumDisplayDevices, then the path infos returned by QueryDisplayConfig can be matched against this interface name to get the correct mode index.

I don't have multiple monitors to test properly, and I'm no expert on Windows display configuration, so this could do with some review and testing

 

[MrINTJ]

I'm not really up to speed on how the results of QueryDisplayConfig should be interpreted, do you have some experience with it?

I just recently had an epiphany around QueryDisplayConfig w.r.t. how Windows deals with displays. The MS documentation uses the word 'display' to refer to both GDI-devices and the monitors themselves. There is also a zoo of different Id formats that refer to these things (adapters, displays, monitors, etc), and often no apparent way to map between them. QueryDisplayConfig and SetDisplayConfig actually make this much clearer, because they separate the GDI-device "Source" from the monitor "Target" and refer to .

I started to write up a brain dump of what I've learned in addition to the MS docs, but it turned into kind of a huge wall-o-text monster, and you may not really care about 85% of it (I'm not familiar with MediaPortal). Probably better just to suggest that you email me directly with any questions, and I'll answer promptly and as best I can.

I'm a developer at [Removed url]. Our product allows an Oculus Quest or Quest II wearer to work in a virtual environment (e.g. sit on a tropical beach) with multiple screens (physical+virtual) floating in front of them, while actually sitting, say, in a coffee shop or a couch at home with just their laptop. We also have environments for collaboration, group meetings and presentations. I wrote their Windows virtual display and audio drivers, and I've been working on a major upgrade to the virtual screen functionality. I'm trying to wrap that up and get it out a.t.m., which is why I wasn't able to volunteer more direct involvement with this change.