Faulty stimulus presentation after lowering the screen resolution

Hardware
,
1

Hello,

I have a dual display setup, and I show a stimulus on one of these displays. I need to use a Bits# to send a trigger to another device and because of the limitations that Bits# has for the pixel clock frequencies it supports, I have to lower the resolution and refresh rate of the monitor I use for stimulus presentation. I use the Screen(‘ConfigureDisplay’, ‘Scanout’,…) command to lower the resolution of the monitor. It successfully does so, but when I present a stimulus with a length equal to the length of the screen, a horizontal line appears that segments the stimulus and causes some artifacts in the stimulus presentation:
stimulus.

My guess is that the line appears due to lowering the resolution, because when I lower the resolution even without the Bits# I get the flickering. Am I correct and is there any way I can fix this with the same resolution?

My setup: My graphics card is an AMD Radeon RX 5700 XT. I run Psychtoolbox-3 on MATLAB2020b and on my OS is Ubuntu 20.04.1.
The monitor I use for my stimulus is an LG-27GN750 with a native resolution of 19201080 @ 240Hz, and I change it to 1024768@120Hz.
My stimulus is On for 4 frames (refresh rate 120Hz), and off for 0.3 secs. I’ve attached the figures of the measured duration for the stimulus-on and stimulus-off (blank) periods and it seems that there’s no timing issue.
Blank

Stimulus
Stimulus735×478 91.5 KB

2

Hi Sara,

Strange problem (that means i have no idea). But why do you run the
screen at a lower resolution? All that’ll happen (depending on scaling
settings on the monitor) is that it will upscale the received signal
again, yielding a worse quality (e.g. blurry) display.

3

I assume you use a dual-X-Screen setup created via XOrgConfCreator() + XOrgConfSelector, because you’ll need a separate X-Screen for visual stimulation with good timing if you use the other monitor for the GUI. I assume you already tried and confirmed the same thing happens with a pure single-display setup? And PTB doesn’t give any errors or warnings?

The plotted timestamps look perfect, suggesting the video signal leaves the graphics card with the correct timing.

PerceptualVBLSyncTest is a good quick visual way to check for symptoms. Showing a video of that gives usually a good idea.

Assuming the above setup and no warnings from PTB, my guess from your results and the look video clip is that this is almost certainly caused by the monitor itself, not running at its native resolution and refresh rate. The panel-scaler in the monitor will usually rescale to native resolution, but also perform some (more or less successful) resampling of the video signal in time to one of its actually supported refresh rates, which can end up in the artifacts your video shows.

In that case these artifacts would be unavoidable at non-native resolution/refresh rate. Maybe choosing full native resolution and a refresh rate of 60 Hz might improve things, given that that at least avoids the spatial resampling step and 60 Hz is a common refresh rate for DVI-D input, so maybe the monitor can deal with 1920x1080p @ 60 Hz better. Worth a try. Would be compatible with your stimulus timing i think.

Normally PTB has a builtin panelfitter (cfe. PanelFitterDemo) for exactly the use case of rescaling or rotating stimuli without having to use the often problematic panel-fitter of the monitor. But that doesn’t help you if you need to limit the video bandwidth due to the Bits# bottleneck.

I think a Datapixx3 from VPixx would be a much better choice for the kind of graphics hardware and monitor you have, given that it allows the use of high-bandwith DisplayPort 1.4 for input and output, and thereby likely also the use of the full feature-set of our monitor.

Or some other trigger solution, maybe, depending on your timing requirements. The CRS Bits T-Lock trigger mechanism is not the greatest design in the first place for reliability.

-mario

4

Thank you for your reply. The reason I use a lower resolution is that I want to have high refresh rate, and use the Bits# at the same time. But Bits# has a limit on the pixel clock frequency it supports, so I have to lower the resolution.
Fortunately, the problem got solved!

5

I hadn’t tried using one monitor. After your suggestion I did and the presentation looks perfect now. For easier debugging I wanted to have two displays, but now I’ll switch to one to avoid this problem.
Thank you very much for your help!

6

If it works purely single-monitor then the monitor isn’t the problem wrt. using a different resolution.

As i said, you can have dual-display setups, but you need to use XOrgConfCreator etc. to set it up if you want proper timing. If you just plugged in the two monitors without using this tool to setup a dual-X-Screen setup, then timing interference between the two displays and the desktop compositor is likely.

There’s also always PsychDebugWindowConfiguration for half-transparent debug display when developing/debugging on a single display setup.

-mario

7

I did use the XOrgConfCreator and then XOrgConfSelector to set up the dual screen. Do you have any suggestions about how I can figure out the root of the problem?
Thanks!

8

Hmm. A dual-x-screen created via those scripts should work equally well as a pure single display / single x-screen setup. Unless the problem is on the side of the monitor, which looked very likely from your description - but then the problem should not go away just by using a single-display setup.

After using XOrgConfSelector again + logout/login to switch to the dual-x-screen configuration, can you provide the info i requested in this post and following ones:
https://psychtoolbox.discourse.group/t/vbl-vertical-retrace-syncing-problem/3589/13?u=mariokleiner

Iow. the generated config file, the log output etc. Also the output of PTB in Matlab, e.g., for PerceptualVBLSyncTest. You are using the standard Ubuntu desktop GUI of Ubuntu 20.04.1-LTS, right? And no error or warning messages from PTB?

-mario

9

Thanks for your reply. Yes, I’m using the standard Ubuntu desktop 20.04.1-LTS. Following you may find the info:

ResolutionTest

SCREEN 0: CURRENT COMBINED RESOLUTION:
width: 1920
height: 1080
pixelSize: 24
hz: 120

SCREEN 0 - Output 0: CURRENT RESOLUTION:
width: 1920
height: 1080
pixelSize: 24
hz: 120
xStart: 0
yStart: 0
name: ‘DisplayPort-1’
outputHandle: 80
displayWidthMM: 597
displayHeightMM: 336

SCREEN 0: AVAILABLE COMBINED RESOLUTIONS:
1920 x 1080
1680 x 1050
1280 x 1024
1440 x 900
1280 x 800
1152 x 864
1280 x 720
1024 x 768
832 x 624
800 x 600
720 x 576
720 x 480
640 x 480
720 x 400

SCREEN 0: AVAILABLE COMBINED DETAILED RESOLUTIONS:
1920 x 1080 60 Hz 24 bits
1920 x 1080 144 Hz 24 bits
1920 x 1080 120 Hz 24 bits
1920 x 1080 100 Hz 24 bits
1920 x 1080 50 Hz 24 bits
1680 x 1050 60 Hz 24 bits
1280 x 1024 75 Hz 24 bits
1440 x 900 60 Hz 24 bits
1280 x 800 60 Hz 24 bits
1152 x 864 75 Hz 24 bits
1280 x 720 60 Hz 24 bits
1280 x 720 50 Hz 24 bits
1024 x 768 75 Hz 24 bits
1024 x 768 60 Hz 24 bits
832 x 624 75 Hz 24 bits
800 x 600 75 Hz 24 bits
800 x 600 60 Hz 24 bits
720 x 576 50 Hz 24 bits
720 x 480 60 Hz 24 bits
640 x 480 75 Hz 24 bits
640 x 480 60 Hz 24 bits
720 x 400 70 Hz 24 bits

SCREEN 0 - OUTPUT 0: AVAILABLE PER OUTPUT DETAILED RESOLUTIONS:
1920 x 1080 60 Hz 32 bits
1920 x 1080 144 Hz 32 bits
1920 x 1080 120 Hz 32 bits
1920 x 1080 100 Hz 32 bits
1920 x 1080 50 Hz 32 bits
1920 x 1080 60 Hz 32 bits
1680 x 1050 60 Hz 32 bits
1280 x 1024 75 Hz 32 bits
1440 x 900 60 Hz 32 bits
1280 x 800 60 Hz 32 bits
1152 x 864 75 Hz 32 bits
1280 x 720 60 Hz 32 bits
1280 x 720 50 Hz 32 bits
1280 x 720 60 Hz 32 bits
1024 x 768 75 Hz 32 bits
1024 x 768 60 Hz 32 bits
832 x 624 75 Hz 32 bits
800 x 600 75 Hz 32 bits
800 x 600 60 Hz 32 bits
720 x 576 50 Hz 32 bits
720 x 480 60 Hz 32 bits
720 x 480 60 Hz 32 bits
640 x 480 75 Hz 32 bits
640 x 480 60 Hz 32 bits
640 x 480 60 Hz 32 bits
720 x 400 70 Hz 32 bits

SCREEN 1: CURRENT COMBINED RESOLUTION:
width: 1920
height: 1080
pixelSize: 24
hz: 120

SCREEN 1 - Output 0: CURRENT RESOLUTION:
width: 1024
height: 768
pixelSize: 24
hz: 120
xStart: 0
yStart: 0
name: ‘HDMI-A-0’
outputHandle: 156
displayWidthMM: 531
displayHeightMM: 298

SCREEN 1: AVAILABLE COMBINED RESOLUTIONS:
1920 x 1080
1680 x 1050
1680 x 945
1400 x 1050
1600 x 900
1280 x 1024
1440 x 900
1280 x 960
1366 x 768
1360 x 768
1280 x 800
1280 x 768
1280 x 720
1024 x 768
1024 x 576
800 x 600
848 x 480
640 x 480

SCREEN 1: AVAILABLE COMBINED DETAILED RESOLUTIONS:
1920 x 1080 60 Hz 24 bits
1680 x 1050 60 Hz 24 bits
1680 x 945 60 Hz 24 bits
1400 x 1050 60 Hz 24 bits
1600 x 900 60 Hz 24 bits
1280 x 1024 60 Hz 24 bits
1440 x 900 60 Hz 24 bits
1280 x 960 60 Hz 24 bits
1366 x 768 60 Hz 24 bits
1360 x 768 60 Hz 24 bits
1280 x 800 60 Hz 24 bits
1280 x 768 60 Hz 24 bits
1280 x 720 60 Hz 24 bits
1024 x 768 120 Hz 24 bits
1024 x 768 60 Hz 24 bits
1024 x 576 60 Hz 24 bits
800 x 600 120 Hz 24 bits
800 x 600 60 Hz 24 bits
800 x 600 56 Hz 24 bits
848 x 480 60 Hz 24 bits
640 x 480 120 Hz 24 bits
640 x 480 60 Hz 24 bits

SCREEN 1 - OUTPUT 0: AVAILABLE PER OUTPUT DETAILED RESOLUTIONS:
1920 x 1080 60 Hz 32 bits
1920 x 1080 60 Hz 32 bits
1680 x 1050 60 Hz 32 bits
1680 x 945 60 Hz 32 bits
1400 x 1050 60 Hz 32 bits
1600 x 900 60 Hz 32 bits
1280 x 1024 60 Hz 32 bits
1440 x 900 60 Hz 32 bits
1280 x 960 60 Hz 32 bits
1366 x 768 60 Hz 32 bits
1360 x 768 60 Hz 32 bits
1280 x 800 60 Hz 32 bits
1280 x 768 60 Hz 32 bits
1280 x 720 60 Hz 32 bits
1024 x 768 120 Hz 32 bits
1024 x 768 60 Hz 32 bits
1024 x 576 60 Hz 32 bits
800 x 600 120 Hz 32 bits
800 x 600 60 Hz 32 bits
800 x 600 56 Hz 32 bits
848 x 480 60 Hz 32 bits
640 x 480 120 Hz 32 bits
640 x 480 60 Hz 32 bits

xrandr --screen 0

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DisplayPort-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
1920x1080 60.00 + 144.00 119.98* 99.93 50.00 59.94
1680x1050 60.00
1280x1024 75.02
1440x900 60.00
1280x800 60.00
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 75.03 60.00
832x624 74.55
800x600 75.00 60.32
720x576 50.00
720x480 60.00 59.94
640x480 75.00 60.00 59.94
720x400 70.08

xrandr --screen 1

Screen 1: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
HDMI-A-0 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
1920x1080 60.00 + 60.00
1680x1050 59.88
1680x945 60.02
1400x1050 59.95
1600x900 60.00
1280x1024 60.02
1440x900 59.90
1280x960 60.00
1366x768 59.79
1360x768 60.02
1280x800 59.91
1280x768 59.99
1280x720 60.00
1024x768 119.99* 60.00
1024x576 59.97
800x600 119.97 60.32 56.25
848x480 60.00
640x480 119.99 59.94

type /etc/X11/xorg.conf.d/90-ptbxorg.conf

Auto generated xorg.conf - Created by Psychtoolbox XOrgConfCreator.

Section “ServerLayout”
Identifier “PTB-Hydra”
Screen 0 “Screen0” 0 0
Screen 1 “Screen1” RightOf “Screen0”
EndSection

Section “Monitor”
Identifier “DisplayPort-1”
EndSection

Section “Monitor”
Identifier “HDMI-A-0”
EndSection

Section “Device”
Identifier “Card0”
Driver “amdgpu”
Option “ZaphodHeads” “DisplayPort-1”
Option “Monitor-DisplayPort-1” “DisplayPort-1”
Screen 0
EndSection

Section “Device”
Identifier “Card1”
Driver “amdgpu”
Option “ZaphodHeads” “HDMI-A-0”
Option “Monitor-HDMI-A-0” “HDMI-A-0”
Screen 1
EndSection

Section “Screen”
Identifier “Screen0”
Device “Card0”
Monitor “DisplayPort-1”
EndSection

Section “Screen”
Identifier “Screen1”
Device “Card1”
Monitor “HDMI-A-0”
EndSection

Output of PerceptualVBLSyncTest

PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.17 - Build date: Oct 31 2020).
PTB-INFO: OS support status: Linux 5.8.0-36-generic Supported.
PTB-INFO: Type ‘PsychtoolboxVersion’ for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file ‘License.txt’ in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: For information about paid priority support, community membership and commercial services, please type
PTB-INFO: ‘PsychPaidSupportAndServices’.

PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] GPU with DCE-10.0 display engine [6 heads].

PTB-WARNING: Querying rasterbeam-position doesn’t work on your setup! (Returns a constant value 0)
PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected displays to graphics card
PTB-WARNING: outputs wrong. See ‘help DisplayOutputMappings’ for tips on how to resolve this problem.
PTB-WARNING: However, this probably doesn’t really matter on your setup for most purposes, as i can use OpenML
PTB-WARNING: timestamping instead, which is even more precise. Only few applications need beampos queries in this case.

PTB-INFO: OpenGL-Renderer is X.Org :: AMD Radeon RX 5700 XT (NAVI10, DRM 3.38.0, 5.8.0-36-generic, LLVM 10.0.0) :: 4.6 (Compatibility Profile) Mesa 20.1.0
PTB-INFO: VBL startline = 768 , VBL Endline = -1
PTB-INFO: Will try to use OS-Builtin OpenML sync control support for accurate Flip timestamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 8.334103 ms [119.988923 Hz]. (50 valid samples taken, stddev=0.000332 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 8.334236 ms [119.987000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.

INFO: PTB’s Screen(‘Flip’, 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 2 times out of a total of 1197 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the ‘when’ argument of Screen(‘Flip’, window [, when]);
INFO: If you called Screen(‘Flip’, window); without the ‘when’ argument, this count is more of a ‘‘mild’’ indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least
INFO: deserve your closer attention. Cfe. ‘help SyncTrouble’, the FAQ section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

Output of PerceptualVBLSyncTest with single monitor

PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.17 - Build date: Oct 31 2020).
PTB-INFO: OS support status: Linux 5.8.0-38-generic Supported.
PTB-INFO: Type ‘PsychtoolboxVersion’ for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file ‘License.txt’ in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: For information about paid priority support, community membership and commercial services, please type
PTB-INFO: ‘PsychPaidSupportAndServices’.

PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] GPU with DCE-10.0 display engine [6 heads].

PTB-WARNING: Querying rasterbeam-position doesn’t work on your setup! (Returns a constant value 0)
PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected displays to graphics card
PTB-WARNING: outputs wrong. See ‘help DisplayOutputMappings’ for tips on how to resolve this problem.
PTB-WARNING: However, this probably doesn’t really matter on your setup for most purposes, as i can use OpenML
PTB-WARNING: timestamping instead, which is even more precise. Only few applications need beampos queries in this case.

PTB-INFO: OpenGL-Renderer is X.Org :: AMD Radeon RX 5700 XT (NAVI10, DRM 3.38.0, 5.8.0-38-generic, LLVM 10.0.0) :: 4.6 (Compatibility Profile) Mesa 20.1.0
PTB-INFO: VBL startline = 768 , VBL Endline = -1
PTB-INFO: Will try to use OS-Builtin OpenML sync control support for accurate Flip timestamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 8.334613 ms [119.981578 Hz]. (50 valid samples taken, stddev=0.000562 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 8.334236 ms [119.987000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.

INFO: PTB’s Screen(‘Flip’, 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 2 times out of a total of 1200 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the ‘when’ argument of Screen(‘Flip’, window [, when]);
INFO: If you called Screen(‘Flip’, window); without the ‘when’ argument, this count is more of a ‘‘mild’’ indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least
INFO: deserve your closer attention. Cfe. ‘help SyncTrouble’, the FAQ section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

  • In single monitor mode, I get a correct output on the display, but in the dual monitor setup, I can only see a black rectangle on the left side of the monitor and the rest is gray.

For another purpose, I have filmed when screen goes from black to white with a 1000fps camera. I am adding the video here as an additional information:

ezgif.com-rotate

This shows that refreshing the monitor does not start from top left, but a few inches below the top, and then the rest of the top part gets updated at the end! And that is probably I have that line in my stimulus, but I do not know why this happens.

10

If you downloaded PTB via our DownloadPsychtoolbox script, a call to UpdatePsychtoolbox is advised, to get the latest PTB beta, as that one fixes a bug wrt. low-level mmio handling on the model of AMD graphics card that you have. This is likely unrelated to your problem, but removes some false and confusing warning messages that i can see in your Matlab output.

Back to your problem:

All the output looks good. The config file and basic dual-X-Screen config is correct for your setup, should work, except it doesn’t.

The update pattern recorded in your video and the PTB output suggests that PTB does not detect anything wrong timing-wise - timing is excellent, and page-flipping is used for proper stimulus updates. Your video recording suggests that the display driver may for some reason misprogram the hardware about where the start of the screen is, so it flips not at the start of scanout, but a few inches in - This would be an AMD driver bug, a thing very rarely observed in nature when used for visual stimulation on Linux.

What happens if you run PerceptualVBLSyncTest(0) to test the other screen? Do you also see some tear-line where one shouldn’t be?

There’s one confusing thing in your output though: Screen 1 is still reported as size 1920x1080 although the only output monitor HDMI-A-0 connected to that screen was switched to 1024x768@120Hz. That’s unexpected, the ptb window and framebuffer being bigger than the monitor it displays on, so i wonder if there is a glitch somewhere, and if this mismatch, which should still work although it is an exotic configuration, triggers some AMD display driver bug?

How did you switch the resolution to 1024x768@120 Hz? xrandr command, or some Psychtoolbox function?

What happens if you do this in a terminal:

xrandr --screen 1 --size 1024x768 --output HDMI-A-0 --mode 1024x768 --rate 120

This should make it explicit to the server that you want the X-Screen 1 to have the same size as the video output, ie. 1024x768 and make the configuration less “exotic”. Maybe that helps.

Otherwise also post the file ~/.local/share/xorg/Xorg0.log for more debug info, maybe also of the command sudo dmesg > /tmp/kernellog.txt which should create the text file /tmp/kernellog.txt. And the output of xrandr --screen 1 --verbose.

-mario

11

I was using “Screen(‘ConfigureDisplay’, ‘Scanout’, 1, 0, 1024, 768,120)” command to change the resolution. By using the xrandr command that you suggested now it works perfectly.
Thank you so much for your help.

12

Ok, so this is mostly not a Linux AMD bug, but more or less PTB’s fault.

On your single-display per X-Screen setup, you should be able to achieve the same effect as that xrandr command from within your script by using PTB’s SetResolution() function, e.g.,

oldSettings = SetResolution(1, 1024, 768, 120);

This is a wrapper around Screen('Resolution',...), just with some safety checks added.

After reading our own help for these functions i have to admit the help text for Linux is a bit confusing and would likely lead you to use Screen('ConfigureDisplay','Scanout', 1, 0, 1024, 768, 120); as you did. Other operating systems only support SetResolution / Screen('Resolution'). The intentionally higher flexibility of PTB here on Linux comes with more opportunities for doing interesting things, but also for shooting yourself in the foot.

A better help text for SetResolution / Screen('Resolution') would probably have told you to use SetResolution() for typical/basic setup on single display setups or on single-display-per-X-Screen setups like yours, and leave Screen('ConfigureDisplay') for more complex scenarios, e.g., with multiple displays per X-Screen.

Another thought: The likely reason you are limited to the 1024x768 on your Bits# is that you are using a cheap passive HDMI to single-link DVI adapter, which restricts bandwidth to 165 Mhz. With an active DisplayPort to dual-link DVI adapter or HDMI to dual-link DVI adapter, i assume you could double the bandwidth to 330 Mhz if the Bits# can handle this, so maybe you’d be able to run 1920x1080@120Hz. The problem with non-native resolutions - and often also non-native refresh rates - is that the monitor itself has to do image rescaling and/or temporal resampling, and that can cause all kinds of deviation between desired and actual display timing. Iow. although PTB’s timestamps confirm perfect timing at the video output of your graphics card, and a Bits# T-Lock trigger setup via our BitsPlusPlus function (cfe help BitsPlusPlus' - for BitsPlusPlus('DIOCommand')) would give some trigger in sync (well one frame after) reception of the videoframe by Bits#, the actual visual pixel response of your monitor may be quite different and delayed from that, due to the monitors internal rescaling/resampling.

Oh and if you appreciate the help, please consider to ask your lab to buy a “community membership with priority support” (cfe. help PsychPaidSupportAndServices) to contribute back financially a little bit to the upkeep of Psychtoolbox. Without way more labs contributing financially, i will not be able to provide free advice and troubleshooting in the future, not even for simple questions.

-mario

13

Thank you for the help Mario.
The Bits# requires using the single-link DVI, and the limit on bandwidth is unavoidable.

We did buy the priority support and appreciate all your help and support for the PTB.

Sara

1 Like
14

Oh ok. If you checked that, i must have misremembered. I thought the Bits# could handle dual-link DVI. Only single-link DVI would be surprisingly weak, given its not that old of a design?

15

The Display++ does support dual-link HDMI, but I don’t think the Bits# hardware (which is older) does, its bandwidth is 165MHz.