Open window can't set to a specified rect size on macOS With Matrox Dualhead2Go

Hardware
,
1

We are running on macOS.
We use a device called dualhead2go from Matrox to connect our video port to 2 external monitors. It creates a stretched desktop across two displays.

BlockquoteThe Matrox DualHead2Go Digital SE external multi-display adapter adds up to two monitors to your laptop or desktop computer. It connects to the video output of your system and uses the system’s existing GPU to provide high-quality, uncompressed graphics and video across all monitors. Ideal for business and professional users looking to increase their productivity with a dual display setup, this little black box lets you run different applications on each monitor or view one application across two monitors.

The problem we encounter is that when we use screen(‘openwindow’), it doesn’t open the right size. We want the screen to be stretched across two monitors, so that we can use stereomode 4 for the left/right eye viewing, but instead it always shows everything on the first monitor then duplicate it onto the second.

An illustration here is when calling Screen(‘Rect’), the system reports a size of 3840x1080, which is exactly the size of our stretched screen provided by the dualhead device. However after opening the window, it shows the window size is cut in half, meaning all the images are displayed onto the first screen, and duplicate to the second. This happens no matter what rect size I use in the open window command.

Image (5)
Image (5)1920×2560 645 KB

Is there any setting in the screen command that can help us stick to our original screen size?

2

Mario, who will know most about this, is away. In the meantime the question is: whether this used to work on macOS before? While I prefer to use macOS for my day to day development, given that Apple abandoned OpenGL years ago and never seems to have fixed reported bugs, there is a good chance this is platform specific.

The one command you can investigate is the PanelFitter – PsychImaging(‘AddTask’, ‘General’, ‘UsePanelFitter’, size, strategy [, srcRect, dstRect][, angle]); Psychtoolbox-3 - Screen(‘PanelFitter’)

Another very long-shot is trying to set RetinaMode on or off, though this should affect both width and height but if there is a bug in the pipeline somewhere… PsychImaging(‘AddTask’, ‘General’, ‘UseRetinaResolution’);

PTB works best on Linux, and it is where any issues are most easily fixed, so I can only suggest you try the same code on a Linux system.

Another option would be to test with a regular DP splitter box, as some of these can offer an extended display mode?

3

Hi,

A guess given what you say and my experience with Matrox.

“… it always shows everything on the first monitor then duplicate it onto the second”

Sounds like an issue with how you have set up the display mappings in the Matrox software.

I have used a Matrox “TripleHead2Go” setup with the larger screen over multiple monitors then cloned to a VR headset. All worked fine eventually, but the Matrox software I found to be extremely hard to understand and follow in terms of setting up the correct mappings. Sometimes the same settings in the Matrox resulted in completely different behaviour on different occasions (for unknown reasons).

All of my issues with getting our setup working were Matrox related, not PTB. So my intuition is that is possibly the case here given we faced lots of weird issues very similar to what you describe in our setup.

We also found that the Matrox would spontaneously corrupt the mappings related files, so deleting those and starting again might be worthwhile as an attempt to fix it. It helps us on occasion.

Disclaimer: this is all with Windows and a few years back now… I would avoid macOS with this unless needed.

However, given my experience with Matrox it would be at least worth a further play with that software. It caused us huge headaches.

I do not think it is OpenGL related, or that would be my guess. The little Matrox box is independent of the computer and not as far as I know reliant on OpenGL etc. Rather my understanding is the hardware in the box does the magic. Not OpenGL. OpenGL effectively acting upon what Matrox/the computer says r.e. monitors.

Anyhow, that’s a guess given the information. The puzzle is the different output of the two PTB commands. Unfortunately I do not have time to ponder that. Or indeed the setup mentioned to test. But, do play with the Matrox, it caused us lots of headaches like this when we used it.

There may indeed be some magical “upgrade to Linux” response, but I do not use Linux so could not speak to that. When we got our Windows + Matrox working (at be it coercing the Matrox software) it worked great for many years.

Peter

4

Without posting a proper paid support authentication token (help PsychPaidSupportAndServices) and paying for all the needed work, I won’t help with resolving this on macOS.

But as background: It very likely has nothing to do with OpenGL. PTB’s since around late year 2019 use a whole new collection of hacks to work around the severe brokenness of macOS graphics and display on most (all?) graphics cards since at least macOS 10.12, possibly as early as macOS 10.7 for some graphics card models. This makes PTB the likely only software with non-broken visual timing on most Intel based Macs in most common situations, iff configured properly by the user. You’d have to go back to our release announcements from late 2019 for details.

As crucial part of the hacks, iff a fullscreen window is opened, PTB will sometimes switch the video output resolution to something else than what you selected, ignoring what you’ve specified, using heuristics based on hundreds of work hours of reverse engineering and testing to find a video mode that works timing-wise. Probably the Matrox box firmware, or display software, or macOS response to an unusual EDID reported by the Matrox does something weird/unusual, which throws the heuristics off, causing it to choose the “wrong” video mode of 1920x1080, which in turn causes the Matrox to switch to clone/mirror mode instead of widescreen monitor mode. PTB used to work perfectly fine with such Matrox Dualhead2go devices on all OS’es, but last time I had access to such a device for testing was over 10 years ago…

Ian is right in that use of PTB’s unique panelfitter is a better way nowadays to present stimuli at non-native display resolutions, given that many digital displays have timing problems on their own in non-native display modes, but this won’t help in your case. Peter is right that switching to Linux would very likely avoid the failure scenario, assuming your specific model of Intel Mac is compatible enough with Linux for your purpose.

5

Thanks for you input. I went back to change our PTB to version 3.0.14 before 2019 update it solves the problem. My version is apparently too new.

6

Nope, it’s not too new. By downgrading you “fixed” your dual-display problem, but broke visual timing, as indicated by your recent new post.

7

As Mathworks sponsored this, Psychtoolbox 3.0.19.4 contains a potential workaround for this specific type of macOS brokeness, which may or may not help to use such a Matrox Dualhead2Go setup while retaining proper visual timing and timestamping. This is untested due to lack of hardware, and unsupported in case it doesn’t work, but here it goes:

  1. UpdatePsychtoolbox to the latest PTB 3.0.19.4.

  2. Set your DualHead2Go display to the resolution you want, ie. 3840x1080 in your case.

  3. Add the statement Screen('Preference', 'ConserveVRAM', 2); before the Screen or PsychImaging ‘OpenWindow’ call. See help ConserveVRAMSettings, the section about kPsychDontSwitchToOptimalVidMode for explanation of this setting.

  4. Do not specify a window size in ‘OpenWindow’, the default size selected by omitting the parameter or setting it to [] is what allows proper operation.

  5. Twist your fingers and hope for the best, ie. that the new workaround works.

Obviously you need the PsychtoolboxKernelDriver for macOS properly installed (help PsychtoolboxKernelDriver) for Psychtoolbox to be able to test if this gives you proper display and proper visual stimulation timing/timestamping. Otherwise PTB can’t check carefully and you might still fool yourself into producing data trash instead of proper data collection, just as would happen with any other vision science toolkit than Psychtoolbox.

All this only applies to Intel based Macs, as timing is broken on any Apple Silicon Mac under macOS with any toolkit in existence atm. as far as I know.

Let us know if this actually fixed the problem properly.