Esoteric Graphics Questions/Findings (another T221 thread)

[jeremywork]

Hello all,

This is kind of an obscure advice-needed/infodump post, though for me this is all just tinkering or proof-of-concept.

I have a cMP 4,1->5,1 with an MVC-flashed 1080Ti as its GPU, as such it's still running 10.13.6 with nVidia's web drivers (this works fine.)
Recently I've been experimenting with IBM T221 displays (9503-DGM & 9503-DGP) ultimately with the goal of getting them running at native resolution/refresh over one modern high bandwidth link, recognized as a single display by macOS. HDMI 2.0 and DP 1.4a on the 1080Ti should each be up to the task.

It seems doable in theory using one of two schemes:
• 2x LFH60 - DVI-DL adapters and 2x active DP -> DVI-DL adapters (Accell B087B-002B in my case) should be possible to use two custom EDIDs with Tiling info, then perhaps a StarTech MST miniDP -> 2x DP would work properly (tiled instead of mirrored) in macOS. Unfortunately the two LFH-60 to DVI-DL adapters I have did not come with the period addon EDID chip modules, so I'll need to create these if I want to pursue this route. For now this is left on the shelf... (Very helpfully, Jack Doerner has already adapted two 48Hz tiled EDIDs for the T221 and left them available here: https://jackdoerner.net/exposition/2017/05/IBM_T221_Linux/ This scheme also allows for a panel overclock of 55Hz+)

• 3x DVI-SL using the undocumented 3x 1280x2400 stripe scheme available on 9503-DG5/DGM/DGP models. This is fundamentally not too different from the factory 2624x2400 DVI-DL + 1216x2400 DVI-SL scheme listed in the manual, but since this does allow three identical signals it becomes possible to bodge in a Matrox TripleHead2Go. This solves the problem of treating the three signals as one display since Matrox boxes already appear this way to the system.

(http://stormdecay.com:1984/displays_ibm_bertha.html#manualmodes)
I've left a ton of Bertha related notes on this page as I tested various Matrox devices, but the TL;DR is the TripleHead2Go Digital SE is better suited to this task than either the Digital Edition or the DP Edition, so all the references to TH2G in this post will refer to the Digital SE (DP input; 3x DVI outputs.)

The TH2G first needs to be set using Matrox PowerDesk to the 3x 1280 x 1024 scheme, then a tool such as SwitchResX can be used to send any custom 3840 x **** resolution which will be properly interpreted by the T221. As long as the horizontal resolution is 3840 and the vertical resolution exceeds 1200 lines the TH2G will be happy and the T221 will use stripe mode instead of tile mode.

(https://forums.macrumors.com/thread...indows-computers-via-dp.2227756/post-29744900)
@Amethyst1 posted here about overclocking the individual DVI link signal to over 172MHz in order to achieve 46.7 Hz /1280 x 2400, but in my testing it seems there is even better news because the T221 supports extremely tight blanking intervals even behind the TH2G. Using horizontal front porch: 48, sync: 32, back: 56; vertical front porch: 1, sync: 2, back: 1 produces a stable image and allows even 165.00MHz to exceed 48Hz at 1280 x 2400. Additionally, my T221s seem to accept signals up to 176.64 MHz at 1280 x 2400 if the H back porch is upped to 62px which theoretically produces a full panel sync within the range of an overclocked panel (direct sync range is 38.24 Hz - 48.76 Hz for stock [as tested]; 49.6 Hz - 63.0 Hz for overclocked according to cirthix.)

Here's where I start running into trouble. SwitchResX indicates the maximum pixel clock of the TripleHead2Go is 358.20 MHz. This doesn't seem unreasonable except that when I plug in a 4K HDMI -> DP adapter which appears with a 600 MHz maximum pixel clock, both the TH2G and T221 cooperate perfectly up to roughly 452.24 MHz (annoyingly close to native - 47.314 Hz at 3840 x 2400 - 48, 32, 56; 1, 2, 1.) FWIW the same TH2G plugged into a 2015 MacBook Pro shows a total pixel clock limit of 365.00 MHz - presumably that's the laptop's limit and not the TH2G's, but frustrating that the 1080Ti with web drivers won't even match this limit.

The HDMI solution is great but very imperfect for a few reasons.
1. There seems to be subtle color banding present which stands out in especially dark gradients. I've followed the guide below but unfortunately noticed no change. It seems the HDMI signal is already being interpreted in RGB 4:4:4 but the DP output of the HDMI adapter is still somewhat crushed compared to direct DP-DP on the TH2G. Fortunately all text is sharp and no fringing is visible on interpolated patterns.
Fixing the External Monitor Color Problem with Your 2018 MacBook Pro (atomicobject.com)

2. The signal desyncs periodically. It tends to work perfectly for minutes to hours on end, but will occasionally send the T221 repeatedly to flashing black screen for up to a minute before becoming stable again. I attribute this only to the HDMI adapter because it also does this when running other 'standard' DP displays - and the TH2G has a sync LED which also flashes on and off while the T221 is attempting to resync. No such instability is noted when using DP-DP signal with the same blanking intervals at 3x1280x2400.

3. The 1080Ti has only one HDMI port and I'd like to run two or three T221s within the native sync range if possible (lol)

Beyond this, I also observe that despite graphical distortion quickly overcoming the image beyond 452.24 MHz, the T221 seems to present a stable unified image well beyond this point. Even true 48 Hz at ~460MHz can be identified as one stable image with uniform distortion on the left edge - as though the HDMI adapter is introducing the garbled image and the TH2G is still perfectly stable across the three links. The T221's OSD reads 48 Hz as this happens. I'm hoping that without the HDMI adapter it may be possible to run the TH2G at true 48 Hz cleanly. It really seems like the TH2G should be able to negotiate a direct DP link with the 1080Ti beyond 358.20 MHz.

I did find and install Floris497's mac-pixel-clock-patch-V2 (both CoreDisplay Patcher v4 and nVidia Web Pascal patcher v1 - thanks @joevt for leaving some helpful breadcrumbs about how to install this successfully on 10.13) and I was able to verify the 165.00 MHz limit in SwitchResX was lifted to 800.00 MHz on the HDMI port when plugged into a standard DVI 1920x1200 display. Unfortunately the DP connections still showed a limit of 358.20 MHz when connected to the TH2G (also the two DH2G Digital SEs I have currently running a second T221 as two logical displays.)

As a last effort I installed Lilu and WhateverGreen (verified active in IORegistryExplorer; I had no other symptoms to resolve) and this seemed to change the DP behavior to display a 600 MHz limit, but SwitchResX still shows 'Not active- invalid?' for all resolutions above 358.20 MHz. Hitting 'activate immediately' briefly shows a maximum pixel clock of 358.20 MHz before a moment later it changes to 600.00 MHz - still only activating the lower pixel clock resolutions.

Is there anything else I should try? Could it be that whatever compression the HDMI adapter is using to create the banding actually fits the 47.314 Hz signal into a total pixel clock lower than 452.24 MHz at the DP signal's end?

I'm still on MP51.0089.B00 because I've never entertained Mojave (nVidia, and my Amfeltec SSD RAID is comprised of SM951 AHCI blades.) I could try updating to 144.0.0.0.0 if it would provide any benefit on High Sierra. I'm also not using OpenCore, but I could also try that if it would help.

I'll be curious to see what other ideas or suggestions y'all have on this. I've come so close, yet still so far...


(right monitor using aforementioned HDMI -> TH2G; left monitor is logically two DH2G 3840 x 1200 displays stacked, e.g. cheating by turning off 'Displays have separate Spaces' and editing two versions of the desktop picture. Dragged windows still like to snap away from the center and some content can't render across the whole desktop. Eventually I'll swap the DH2Gs for the MST tiled idea and try overclocking that panel for 55-60Hz operation. In the meantime the DH2Gs seem to avoid tearing more reliably than the two LFH60-DVI-DL scheme for some reason. Even windowed youtube videos seem smooth this way, but tear noticeably with the two Accell boxes. I imagine in MST tile mode they'll be genlocked to resolve this.)


P.S. unfortunately the eBay item for the HDMI-DP adapter has been removed, but here's a screenshot of the listing in case it's of any use.

 

[Amethyst1]

Hello all,

This is kind of an obscure advice-needed/infodump post, though for me this is all just tinkering or proof-of-concept.

Welcome

Recently I've been experimenting with IBM T221 displays (9503-DGM & 9503-DGP) ultimately with the goal of getting them running at native resolution/refresh over one modern high bandwidth link, recognized as a single display by macOS.

I have a 9503-DG3 and a 9503-DGP. I also had a Viewsonic VP2290b (9503-DG3 clone/rebadge) but it suffered a tragic fate.

[...] left monitor is logically two DH2G 3840 x 1200 displays stacked, e.g. cheating by turning off 'Displays have separate Spaces' and editing two versions of the desktop picture.

This is exactly how I'm running my 9503-DGP. Shown here.

• 2x LFH60 - DVI-DL adapters and 2x active DP -> DVI-DL adapters (Accell B087B-002B in my case) should be possible to use two custom EDIDs with Tiling info, then perhaps a StarTech MST miniDP -> 2x DP would work properly (tiled instead of mirrored) in macOS.

AFAIK @joevt 's attempts of getting an "arbitrary" tiled display (an Acer XV273K) working with an .mtdd overlay, which is how it's done for tiled 5K displays, have been unsuccessful so far. Tiling didn't work for the Dell UP3218K (which includes tiling info in the EDID) either, until an .mtdd overlay was added by Apple themselves in macOS Ventura.

And I couldn't get my 9503-DGP to display anything behind a DisplayPort 1.2 MST hub on Linux. Black screen, LED flashing amber, even when using just a single connection (but I also tried two, three and four connections). I haven't tried the MST hub > DualHead2Go's > 9503-DGP route yet.

Unfortunately the DP connections still showed a limit of 358.20 MHz when connected to the TH2G (also the two DH2G Digital SEs I have currently running a second T221 as two logical displays.)

The DH2G and TH2G are DisplayPort 1.1 devices and use four-lane HBR, which usually limits maximum pixel clock to 360 MHz (when using 8bpc RGB). If you force macOS to switch to 6bpc RGB (which isn’t easy), the limit would theoretically be 480 MHz.

FWIW the same TH2G plugged into a 2015 MacBook Pro shows a total pixel clock limit of 365.00 MHz - presumably that's the laptop's limit and not the TH2G's,

All 2015 MacBook Pros can do HBR2×4, with a pixel clock limit of 540 MHz (Intel Iris 6100 [13"]/Iris Pro 5200 [15"]; confirmed myself) or possibly ≈600 MHz (AMD Radeon [15"]; but I haven't seen ≈600 MHz confirmed, so I assume 540 MHz for now).

Another curious problem that affects the Iris Pro 5200 is that as the width of the timing increases, the maximum height decreases and vice versa. As illustrated here and here, a resolution of 3840×2400 isn't possible on macOS 10.9.5 or 10.15.7 at least.

(https://forums.macrumors.com/thread...indows-computers-via-dp.2227756/post-29744900)
@Amethyst1 posted here about overclocking the individual DVI link signal to over 172MHz in order to achieve 46.7 Hz /1280 x 2400, but in my testing it seems there is even better news because the T221 supports extremely tight blanking intervals even behind the TH2G. Using horizontal front porch: 48, sync: 32, back: 56; vertical front porch: 1, sync: 2, back: 1 produces a stable image and allows even 165.00MHz to exceed 48Hz at 1280 x 2400. Additionally, my T221s seem to accept signals up to 176.64 MHz at 1280 x 2400 if the H back porch is upped to 62px which theoretically produces a full panel sync within the range of an overclocked panel (direct sync range is 38.24 Hz - 48.76 Hz for stock [as tested]; 49.6 Hz - 63.0 Hz for overclocked according to cirthix.)

That's good to know. I wanted to “play it safe” and stuck to CVT-RB timings.

(http://stormdecay.com:1984/displays_ibm_bertha.html#manualmodes)
I've left a ton of Bertha related notes on this page

Wow! Many thanks. Two small additions:

• I've managed to get 334 MHz pixel clock once from a Delock 62603. Not really useful for the T221 but worth knowing.
• You might be able to find the chipset the StarTech DP-to-DVI/HDMI adapter uses by running /System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt while it's connected and examining the text file it generates. How much output this produces depends on the GPU, but on an Intel Iris Pro 6200 or AMD Polaris (Radeon RX 400/500), it identifies DisplayPort sinks, showing e.g. the following for a really ancient (2010?) miniDP-to-DVI adapter using the Parade PS161 chipset (which is limited to 146 MHz pixel clock at least in my case).

[DP 1.1 2 x HBR ]      Status: [2 x HBR  77 0]      caps [features 0x0, p_encoding 0x0]      DVI/HDMI Branch OUI:000-028-248 161AB3 [049-054-049-065-066-051] HW Version: 0    FW Version: 149.24

 

[jeremywork]

AFAIK @joevt 's attempts of getting an arbitrary tiled display (an Acer XV273K) working with an .mtdd overlay, which is how it's done for tiled 5K displays, have been unsuccessful so far.

That’s too bad. I’d imagine there’s not much logical difference between those tiled 5k displays and two Bertha-halves with unique hardware EDIDs behind a DP hub.

And I couldn't get my 9503-DGP to display anything behind a DisplayPort 1.2 MST hub on Linux. Black screen, LED flashing amber, even when using just a single connection (but I also tried two, three and four connections).

All I’ve tried so far is the two Accell adapters behind the StarTech in macOS. They’re both mirrored but the T221 happily displays both sides FWIW.

I haven't tried the MST hub > DualHead2Go's > 9503-DGP route yet.

Is it possible to create an MST display using ‘top’ and ‘bottom’ tiles instead of ‘left’ and ‘right’?

The DH2G and TH2G are DisplayPort 1.1 devices and use four-lane HBR, which usually limits maximum pixel clock to 360 MHz (when using 8bpc RGB). If you force macOS to switch to 6bpc RGB (which isn’t easy), the limit would theoretically be 480 MHz.

Ahh, thanks for this! It then makes sense that the TH2G accepts 452.24 MHz behind the HDMI converter but only with evident gradient banding. The HDMI adapter must use a 6bpc RGB output (even at 3840x1200 the banding is evident.) Even if this is the case I may try to force 6bpc over DisplayPort so I can alleviate the desync problem caused by that HDMI converter. Maybe that’ll allow at least up to 460MHz to be stable and allow for 48Hz, albeit still with some color crushing.

Another curious problem that affects the Iris Pro 5200 is that as the width of the timing increases, the maximum height decreases and vice versa. As illustrated here and here, a resolution of 3840×2400 isn't possible on macOS 10.9.5 or 10.15.7 at least.

This lines up with my experience in 10.14. Mine is a 2015 15” Iris Pro and Bertha only runs 3840 wide up to 2320 high OR 2400 high up to 3712 wide (unless I run two logical links…)

You might be able to find the chipset the StarTech DP-to-DVI/HDMI adapter uses by running /System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt while it's connected and examining the text file it generates.

I’ll give this a try shortly.

—

Thanks for all of these pointers!

 

[Amethyst1]

The HDMI adapter must use a 6bpc RGB output (even at 3840x1200 the banding is evident.)

Maybe it uses chroma subsampling. Using e.g. YCbCr 4:2:0, 4K at 60 Hz is possible even using HDMI 1.4, but the image looks quite bad. You can check if AllRez provides info on the colour format that is going into the adapter. Have you tested it with another display to see if it causes banding there as well?

Even if this is the case I may try to force 6bpc over DisplayPort so I can alleviate the desync problem caused by that HDMI converter.

I think this is easiest on Windows where you can explicitly select it in the NVIDIA settings. No idea about Linux but macOS never deliberately chooses 6bpc and forcing it is a bit involved AFAICS.

Thanks for all of these pointers!

Thanks again for the additional info and tests!

 

[jeremywork]

examining the text file it generates

I've just done this on the MBP with Iris Pro 5200 and it seems to explain a different question I had forgotten about. Since the 3712/2320 limit applies on this model it seems to get stuck in a loop whenever an Apple passive mDP->DVI or HDMI->DVI adapter is used to connect to the T221's primary link. I could flash an EDID mode which only presents 1920 x 1200 but whenever 3840 x 2400 exists as the primary mode in the EDID this loop condition occurs. This also happens when using the StarTech MDP2VGDVHDW but not when using the Delock 62603. If the primary link is attached to the 62603 the secondary link detects and works fine using either the StarTech or the Apple adapter since it's essentially a duplicate of the EDID already loaded on the 62603.

Port: 01 : [DP, 1.1, 4 x HBR]      set [4 x HBR : status: 7777]      caps [features 0x0, p_encoding 0x0]       Sink OUI:0-16-250 eD15ba [101-68-49-53-98-97] HW Version: 0 FW Version:1.0
kAGDCPortCapability is not supported on the current platform
Port: 02 : [DP, 1.1, 4 x HBR]      set [4 x HBR : status: 7777]      caps [features 0x0, p_encoding 0x0]      DVI/HDMI Branch OUI:0-28-248 171GB0 [49-55-49-71-66-48] HW Version: 1 FW Version:17.29
kAGDCPortCapability is not supported on the current platform
Port: 03 : device present  [TMDS]
Port: 04 : empty

Port 01 is the onboard Retina display; 02 is the 62603; 03 is the StarTech. So, it's simply a DP++ style passive and the MBP's TMDS bandwidth limit is at least 176.64 MHz from what I can gather.

Additionally, the following output appears in the Terminal whenever either TMDS adapter is present:

Error: AUX CMD: 0,16 = Error, 2
Error: AUX CMD: 20,3 = Error, 2
Error: AUX CMD: 80,16 = Error, 2
Error: AUX CMD: 100,2 = Error, 2
Error: AUX CMD: 107,1 = Error, 2
Error: AUX CMD: 10a,1 = Error, 2
Error: AUX CMD: 111,1 = Error, 2
Error: AUX CMD: 200,8 = Error, 2
Error: AUX CMD: 42f,1 = Error, 2
Error: AUX CMD: 2200,16 = Error, 2
Error: AUX CMD: 68028,1 = Error, 2
Error: AUX CMD: 6921d,3 = Error, 2
Error: AUX CMD: 69330,2 = Error, 2
Error: AUX CMD: 69493,1 = Error, 2
Error: AUX CMD: 0,16 = Error, 2
Error: AUX CMD: 20,3 = Error, 2
Error: AUX CMD: 80,16 = Error, 2
Error: AUX CMD: 100,2 = Error, 2
Error: AUX CMD: 107,1 = Error, 2
Error: AUX CMD: 10a,1 = Error, 2
Error: AUX CMD: 111,1 = Error, 2
Error: AUX CMD: 200,8 = Error, 2
Error: AUX CMD: 42f,1 = Error, 2
Error: AUX CMD: 2200,16 = Error, 2
Error: AUX CMD: 68028,1 = Error, 2
Error: AUX CMD: 6921d,3 = Error, 2
Error: AUX CMD: 69330,2 = Error, 2
Error: AUX CMD: 69493,1 = Error, 2

None of this appears when running AGDCDiagnose with only one or both 62603s.

Maybe it uses chroma subsampling. Using e.g. YCbCr 4:2:0, 4K at 60 Hz is possible even using HDMI 1.4, but the image looks quite bad.

I thought this at first too, but none of the color fringing I've seen in photos lines up with my output. The image is crystal clear, just with gradient banding not more noticeable than a CRT running 16-bit color.

You can check if AllRez provides info on the colour format that is going into the adapter.

Thanks, I'll try this next...

Have you tested it with another display to see if it causes banding there as well?

I have used the same HDMI converter successfully to run one of the two DH2Gs on the 48Hz scheme. In this case the color banding existed only on the [top or bottom] half of the 4x1920x1200 Bertha. At 48 Hz this was not in danger of exceeding the 8bpc bandwidth limit; I think this HDMI adapter simply produces a 6bpc DP output.

The Mac Pro (at least in 10.12.6) had this issue where if SwitchResX had changed the DH2G mode I would have a hang whenever the computer started up with both DH2Gs plugged in. I resolved either by starting with only one, then removing it, then adding the second, then readding the first. Later I used the HDMI adapter and this alleviated the need. I eventually used PowerDesk to set one of the DH2Gs to 2x1920x1200@50Hz and the other to 2x1920x1200@60Hz which seems to also have solved the problem - or upgrading to 10.13.6... too many variables by then. (SwitchResX can still run both at 48Hz.)

macOS never deliberately chooses 6bpc and forcing it is a bit involved AFAICS

I'll try to wrap my brain around this and see if I can make it work... Clearly the TH2G is capable of operating this way or the HDMI adapter trick wouldn't work.

Thanks again for the additional info and tests!

You're welcome, I'm glad that page can be of use! I should note that while I've noticed no ill effects of running the 48, 32, 56; 1, 2, 1 timings over several hundred hours, I have no qualifications to state that things won't go wrong over the following hundreds or thousands of hours. I had one DGP Bertha arrive functional but with pressure scarring across the center of the panel, so I have a single set of spare internals to resort to if I end up killing something. It seems they're quite resilient to tinkering and will failover to the test patterns mode before just staying black with the blinking LED and fans on. The only symptom I've found with tight timings is sometimes the panel will flash out-of-range when the computer has simply turned off or sent the display to sleep; sync picks up just fine when the signal returns. Still, generally proceed with caution

 

[jeremywork]

• I've managed to get 334 MHz pixel clock once from a Delock 62603. Not really useful for the T221 but worth knowing.

I've added this note to my section with Parade's documentation of the 300MHz limit

I have a 9503-DG3 and a 9503-DGP. I also had a Viewsonic VP2290b (9503-DG3 clone/rebadge) but it suffered a tragic fate.

I found your post about running the DG3 using the reference 6870 here:https://forums.macrumors.com/thread...supported-external-gpus.2175397/post-27557716

Were you able to enable genlock on the 6870 or is this not actually necessary for the DG3 to sync?

At the top of my Bertha page I tried to deliniate the model differences but after discovering the DGM/DGP's 38.25-48.75 Hz sync range isn't mentioned at all in the factory documents, I'm not sure if the "fixed" 41 Hz genlock-required notes about the earlier models should be blindly trusted either.

Dare I ask about the VP2290b... experiment gone wrong?

My two DGMs were basically just tossed in a cardboard box together and miraculously only the plastics shattered in shipping; the panels were unscathed. One was quickly swapped into the [carefully packed] DGP casing I mentioned had panel damage; the other I've slowly been jigsawing back together out of all the plastic bits. One of the two shattered casings will be good enough one day to house the other DGM, but the second is too far gone and the panel it would house is relegated to spare parts anyways.

 

[Amethyst1]

I've added this note to my section with Parade's documentation of the 300MHz limit

Strangely, when I tried one of my 62603s with a Huawei MateView (at 3840×2560), dropouts started after 301 MHz. I'll have to revisit this. I definitely had it doing 334.56 MHz at 4088×2880 without dropouts.

Were you able to enable genlock on the 6870 or is this not actually necessary for the DG3 to sync?

I didn't do anything special. The DG3 had no issues with sync. I don't remember if there was excessive tearing, but this thread has inspired me to dig out my DG3 and do some more testing.

Dare I ask about the VP2290b... experiment gone wrong?

It was... dropped during a move.

My two DGMs were basically just tossed in a cardboard box together and miraculously only the plastics shattered in shipping; the panels were unscathed. One was quickly swapped into the [carefully packed] DGP casing I mentioned had panel panel damage; the other I've slowly been jigsawing back together out of all the plastic bits.

So how many working T221s do you have?

 

[jeremywork]

I didn't do anything special. The DG3 had no issues with sync. I don't remember if there was excessive tearing, but this thread has inspired me to dig out my DG3 and do some more testing.

Very interesting. I'll definitely be curious to know what you find. I suspect it may also have a wider sync range than IBM says it does. Even the factory EDIDs for DG0 legacy modes seem to indicate as much...

12.709 Hz and 12.993 Hz were both used as [presumably] 1/3rd timing modes for a "41Hz fixed" target;
19.927 Hz and 20.099 Hz were both used as 1/2 timing modes;
40.931, 40.934, & 40.948 were each used as "native" speeds.

If anything the retiming target seems closer to 38-40Hz, presuming it works the same way as the 48Hz target does on DGM/DGP.

Eventually I intend to perform an overclock to one of my panels not only to test 31Hz/55Hz+ but also to observe the behavior after flashing EDID mode 029 for "41Hz" mode.

It was... dropped during a move.

Ouch... sorry to hear that

So how many working T221s do you have?

Four in perfect servicability. I could only really justify the quantity due to the cables being so hard to come by and the prices for entire displays with multiple cables being so relatively inexpensive. The first DGP I was lucky to receive with a DVI-DL adapter and a 2xDVI-SL+USB, but naturally I wanted to test with a second of each cable type. The second DGP came with a single 2xDVI-SL+USB, and the third DGP again came with one DVI-DL and a 2xDVI-SL+USB, but the panel arrived damaged. The last two DGMs I admit were overkill, but they were one $100 package before shipping from Japan and came with two more 2xDVI-SL+USB cables between them, so I clicked the button and stopped searching for them ;P In light of the good casing on the damaged panel I'm basically happy with the outcome, and I've been more likely to keep testing when I can do it without taking my desk apart all the time.

Running skeletor-Bertha without the plastic housing has a certain look to it that I admit I don't dislike. It reminds me of an era when the local AASP I worked for ran their showroom G5 with the panel off, accented by cold cathode lighting and black paint on the building walls.

The damaged one is just kinda sad. Everything works perfectly, just a mountain of stuck/dead pixels running horizontally across the center. If I leave it powered on for a few hours most of them start to come back to life, but toward the right edge it's never perfect and the cycle restarts whenever it cools back down. It was easy to choose this one for the internal photographs on my page though, and it'll probably be the testbed when I try the overclock. It all worked out...

 

[joevt]

• 2x LFH60 - DVI-DL adapters and 2x active DP -> DVI-DL adapters (Accell B087B-002B in my case) should be possible to use two custom EDIDs with Tiling info, then perhaps a StarTech MST miniDP -> 2x DP would work properly (tiled instead of mirrored) in macOS. Unfortunately the two LFH-60 to DVI-DL adapters I have did not come with the period addon EDID chip modules, so I'll need to create these if I want to pursue this route. For now this is left on the shelf... (Very helpfully, Jack Doerner has already adapted two 48Hz tiled EDIDs for the T221 and left them available here: https://jackdoerner.net/exposition/2017/05/IBM_T221_Linux/ This scheme also allows for a panel overclock of 55Hz+)

I did begin work on an EDID override method using Lilu/WhateverGreen/AllRez but I haven't tested it yet. It would basically override the EDID at a lower level than the EDID overrides at /System/Library/Displays/Contents/Resources/Overrides can. edid-decode is used to decode EDIDs. I'm not aware of any tools that will easily let you add tile info. If you create the tile block bytes as hex then my EDIDUtil.sh script can be used to insert it into an EDID. If the tile info in the EDID overrides is not sufficient for macOS, then an .mtdd file will need to be created. Actually, it may be that Nvidia GPUs don't support multi-tile displays except for the Dell UP2715K so you may need to switch to AMD if you want to explore this route.
https://www.tonymacx86.com/threads/...ell-ultrasharp-27-monitor.158311/post-1687123
I am not 100% sure about that. I know there's some Dell UP2715K specific code but I don't know if patching that code is required for tile support of other displays:
https://www.tonymacx86.com/threads/...trafine-5k-sierra-10-12-4.219872/post-1640968

(http://stormdecay.com:1984/displays_ibm_bertha.html#manualmodes)
I've left a ton of Bertha related notes on this page as I tested various Matrox devices, but the TL;DR is the TripleHead2Go Digital SE is better suited to this task than either the Digital Edition or the DP Edition, so all the references to TH2G in this post will refer to the Digital SE (DP input; 3x DVI outputs.)

Here's where I start running into trouble. SwitchResX indicates the maximum pixel clock of the TripleHead2Go is 358.20 MHz. This doesn't seem unreasonable except that when I plug in a 4K HDMI -> DP adapter which appears with a 600 MHz maximum pixel clock, both the TH2G and T221 cooperate perfectly up to roughly 452.24 MHz (annoyingly close to native - 47.314 Hz at 3840 x 2400 - 48, 32, 56; 1, 2, 1.) FWIW the same TH2G plugged into a 2015 MacBook Pro shows a total pixel clock limit of 365.00 MHz - presumably that's the laptop's limit and not the TH2G's, but frustrating that the 1080Ti with web drivers won't even match this limit.

The HDMI solution is great but very imperfect for a few reasons.
1. There seems to be subtle color banding present which stands out in especially dark gradients. I've followed the guide below but unfortunately noticed no change. It seems the HDMI signal is already being interpreted in RGB 4:4:4 but the DP output of the HDMI adapter is still somewhat crushed compared to direct DP-DP on the TH2G. Fortunately all text is sharp and no fringing is visible on interpolated patterns.
Fixing the External Monitor Color Problem with Your 2018 MacBook Pro (atomicobject.com)

Both the TH2G DP and TH2G SE have DP input, but you say the SE can do up to 452.24 MHz while the DP can do only up to 360MHz. 360MHz is the limit for HBR x4 8bpc RGB. I don't know what could cause a limit of 452.24 MHz. It means you are slightly short of the 48Hz limit of the display. 452.24 MHz is nearly DVI-SL 165MHz x 3 (495 MHz).
It might be interesting to get the DPCD info using AllRez from the TH2G SE and TH2G DP and compare them.

Maybe the HDMI to DisplayPort adapter is allowing 4:2:2 or 4:2:0? 4:2:2 halves the color resolution horizontally and 4:2:0 halves the color resolution both vertically and horizontally. You probably shouldn't see any banding with "Use gray levels" option in SwitchResX.

2. The signal desyncs periodically. It tends to work perfectly for minutes to hours on end, but will occasionally send the T221 repeatedly to flashing black screen for up to a minute before becoming stable again. I attribute this only to the HDMI adapter because it also does this when running other 'standard' DP displays - and the TH2G has a sync LED which also flashes on and off while the T221 is attempting to resync. No such instability is noted when using DP-DP signal with the same blanking intervals at 3x1280x2400.

3. The 1080Ti has only one HDMI port and I'd like to run two or three T221s within the native sync range if possible (lol)

Beyond this, I also observe that despite graphical distortion quickly overcoming the image beyond 452.24 MHz, the T221 seems to present a stable unified image well beyond this point. Even true 48 Hz at ~460MHz can be identified as one stable image with uniform distortion on the left edge - as though the HDMI adapter is introducing the garbled image and the TH2G is still perfectly stable across the three links. The T221's OSD reads 48 Hz as this happens. I'm hoping that without the HDMI adapter it may be possible to run the TH2G at true 48 Hz cleanly. It really seems like the TH2G should be able to negotiate a direct DP link with the 1080Ti beyond 358.20 MHz.

There exist HDMI 2.1 to DisplayPort adapters now. They have no benefit for HDMI 2.0 outputs except they support width > 4096. Perhaps you can chain a HDMI to DisplayPort adapter to a DisplayPort to HDMI adapter? But if you find that this is only working because of chroma sub sampling, then maybe the TH2G is not the way to go. What about the QH2G?

I did find and install Floris497's mac-pixel-clock-patch-V2 (both CoreDisplay Patcher v4 and nVidia Web Pascal patcher v1 - thanks @joevt for leaving some helpful breadcrumbs about how to install this successfully on 10.13) and I was able to verify the 165.00 MHz limit in SwitchResX was lifted to 800.00 MHz on the HDMI port when plugged into a standard DVI 1920x1200 display. Unfortunately the DP connections still showed a limit of 358.20 MHz when connected to the TH2G (also the two DH2G Digital SEs I have currently running a second T221 as two logical displays.)

As a last effort I installed Lilu and WhateverGreen (verified active in IORegistryExplorer; I had no other symptoms to resolve) and this seemed to change the DP behavior to display a 600 MHz limit, but SwitchResX still shows 'Not active- invalid?' for all resolutions above 358.20 MHz. Hitting 'activate immediately' briefly shows a maximum pixel clock of 358.20 MHz before a moment later it changes to 600.00 MHz - still only activating the lower pixel clock resolutions.

Is there anything else I should try? Could it be that whatever compression the HDMI adapter is using to create the banding actually fits the 47.314 Hz signal into a total pixel clock lower than 452.24 MHz at the DP signal's end?

Once we learn from the DPCD what the limits of the TH2G are, we might be able to figure out what is needed to go beyond that.

I'm still on MP51.0089.B00 because I've never entertained Mojave (nVidia, and my Amfeltec SSD RAID is comprised of SM951 AHCI blades.) I could try updating to 144.0.0.0.0 if it would provide any benefit on High Sierra. I'm also not using OpenCore, but I could also try that if it would help.

OpenCore can load Lilu/WhateverGreen earlier which might be necessary for some patches. I don't think the firmware version matters.

AFAIK @joevt 's attempts of getting an "arbitrary" tiled display (an Acer XV273K) working with an .mtdd overlay, which is how it's done for tiled 5K displays, have been unsuccessful so far. Tiling didn't work for the Dell UP3218K (which includes tiling info in the EDID) either, until an .mtdd overlay was added by Apple themselves in macOS Ventura.

But I've never tried arbitrary tiling with displays limited to HBR or HBR2 and I still have the new EDID override code to test.

• You might be able to find the chipset the StarTech DP-to-DVI/HDMI adapter uses by running /System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt while it's connected and examining the text file it generates. How much output this produces depends on the GPU, but on an Intel Iris Pro 6200 or AMD Polaris (Radeon RX 400/500), it identifies DisplayPort sinks, showing e.g. the following for a really ancient (2010?) miniDP-to-DVI adapter using the Parade PS161 chipset (which is limited to 146 MHz pixel clock at least in my case).

[DP 1.1 2 x HBR ]      Status: [2 x HBR  77 0]      caps [features 0x0, p_encoding 0x0]      DVI/HDMI Branch OUI:000-028-248 161AB3 [049-054-049-065-066-051] HW Version: 0    FW Version: 149.24

AllRez includes iogdiagnose + AGDCDiagnose output and it translates the OUI.

That’s too bad. I’d imagine there’s not much logical difference between those tiled 5k displays and two Bertha-halves with unique hardware EDIDs behind a DP hub.

Tiled 5K60, 4K144, and 8K60 displays are dual link SST. A Bertha behind a DP hub would be more like a tiled 4K60 display which were MST displays. macOS supports tiled 4K60 MST displays but I don't know how I would get that to work for other displays and I don't know if it has code to handle an arbitrary number of tiles (more than two horizontal tiles). The ASUS PQ321 is an example of a tiled 4K MST display. AGDCDiagnose only returns EDID info for one of the tiles. It might be interesting to see if my EDID override code can work for two displays connected to an MST hub to make them appear as an ASUS PQ321.

Is it possible to create an MST display using ‘top’ and ‘bottom’ tiles instead of ‘left’ and ‘right’?

Yes, both the EDID DisplayID tile block and .mtdd override file support varying dimensions of tiles. The .mtdd can specify which tile is responsible for audio, which timings each tiled mode can use, and what EDID should be used to represent the entire display.

Ahh, thanks for this! It then makes sense that the TH2G accepts 452.24 MHz behind the HDMI converter but only with evident gradient banding. The HDMI adapter must use a 6bpc RGB output (even at 3840x1200 the banding is evident.) Even if this is the case I may try to force 6bpc over DisplayPort so I can alleviate the desync problem caused by that HDMI converter. Maybe that’ll allow at least up to 460MHz to be stable and allow for 48Hz, albeit still with some color crushing.

I don't think 6bpc is an option for HDMI / DVI. It's more likely using chroma sub sampling. chroma sub sampling doesn't affect gray scale output but 6bpc would.
https://en.wikipedia.org/wiki/HDMI

Additionally, the following output appears in the Terminal whenever either TMDS adapter is present:

Error: AUX CMD: 0,16 = Error, 2
Error: AUX CMD: 20,3 = Error, 2
Error: AUX CMD: 80,16 = Error, 2
Error: AUX CMD: 100,2 = Error, 2
Error: AUX CMD: 107,1 = Error, 2
Error: AUX CMD: 10a,1 = Error, 2
Error: AUX CMD: 111,1 = Error, 2
Error: AUX CMD: 200,8 = Error, 2
Error: AUX CMD: 42f,1 = Error, 2
Error: AUX CMD: 2200,16 = Error, 2
Error: AUX CMD: 68028,1 = Error, 2
Error: AUX CMD: 6921d,3 = Error, 2
Error: AUX CMD: 69330,2 = Error, 2
Error: AUX CMD: 69493,1 = Error, 2

Error: AUX CMD: 0,16 = Error, 2
Error: AUX CMD: 20,3 = Error, 2
Error: AUX CMD: 80,16 = Error, 2
Error: AUX CMD: 100,2 = Error, 2
Error: AUX CMD: 107,1 = Error, 2
Error: AUX CMD: 10a,1 = Error, 2
Error: AUX CMD: 111,1 = Error, 2
Error: AUX CMD: 200,8 = Error, 2
Error: AUX CMD: 42f,1 = Error, 2
Error: AUX CMD: 2200,16 = Error, 2
Error: AUX CMD: 68028,1 = Error, 2
Error: AUX CMD: 6921d,3 = Error, 2
Error: AUX CMD: 69330,2 = Error, 2
Error: AUX CMD: 69493,1 = Error, 2

None of this appears when running AGDCDiagnose with only one or both 62603s.

Those appear to be errors from reading DPCD registers (0,16 is 00000h to 0000Fh and 20,3 is 00020h to 00022h). Since those are not DisplayPort devices, it reports errors. If you add 2>&1 to the end of the command, it will put those errors into the output file so you can see where they correspond to.

I thought this at first too, but none of the color fringing I've seen in photos lines up with my output. The image is crystal clear, just with gradient banding not more noticeable than a CRT running 16-bit color.

Maybe some chroma sub sampling tests will show for sure.
https://www.rtings.com/tv/learn/chroma-subsampling
Or try some gradients:
https://forums.macrumors.com/thread...icon-m1-m2-now-possible.2381664/post-31987527
There's probable some better tests. Maybe involving animation?

 

[jeremywork]

Thanks for all of these details! My technical skills aren't quite at your level but I'll do my best to keep up.

I'm not aware of any tools that will easily let you add tile info.

I imagine if this is a hiccup I can fashion a couple of the hardware EDID override dongles originally sold alongside the DVI-DL->LFH-60 adapters (http://www.grimm.jp/edidrom) so that each of the two Accell DP devices will read a different EDID, and tiling info can be added per side. (the T221's onboard EDID flash mode will always output the same EDID for all connected signals, so I imagine even a clever software override would have trouble with that.)

If the tile info in the EDID overrides is not sufficient for macOS, then an .mtdd file will need to be created. Actually, it may be that Nvidia GPUs don't support multi-tile displays except for the Dell UP2715K so you may need to switch to AMD if you want to explore this route.
https://www.tonymacx86.com/threads/...ell-ultrasharp-27-monitor.158311/post-1687123
I am not 100% sure about that. I know there's some Dell UP2715K specific code but I don't know if patching that code is required for tile support of other displays:
https://www.tonymacx86.com/threads/...trafine-5k-sierra-10-12-4.219872/post-1640968

If I get the EDIDs figured out and it really should work but still doesn't, it's probably sensical to find an RX 6800 eventually anyhow. I'll read up on those threads.

Both the TH2G DP and TH2G SE have DP input, but you say the SE can do up to 452.24 MHz while the DP can do only up to 360MHz. 360MHz is the limit for HBR x4 8bpc RGB. I don't know what could cause a limit of 452.24 MHz. It means you are slightly short of the 48Hz limit of the display. 452.24 MHz is nearly DVI-SL 165MHz x 3 (495 MHz).

The DP edition will definitely not exceed 360 MHz. Sending even slightly more causes the LED inside the box to stay red, but it turns green at 360MHz or below. The Digital SE will report a 365 MHz limit when plugged directly into my 2015 MacBook Pro's mDP, and will actually sync and produce stable output at even 460MHz+ with the HDMI, but 452.24 MHz is the fastest signal the HDMI->TH2G[DigitalSE]->T221 displays with accurate colors (banding notwithstanding.) Pushing slighty beyond induces some line artifacts, and anything meaningfully higher looks like a feverdream, but all desktop elements are still recognizeable and the T221 still shows a unified desktop over the three stripes, at 48Hz on the OSD. I suspect this is all distorting in the HDMI adapter since the TH2G still indicates stable sync. I'll try to get some pictures of this.

It might be interesting to get the DPCD info using AllRez from the TH2G SE and TH2G DP and compare them.

I've just downloaded AllRez and I'll start collecting data. Thanks for creating this!

Maybe the HDMI to DisplayPort adapter is allowing 4:2:2 or 4:2:0? 4:2:2 halves the color resolution horizontally and 4:2:0 halves the color resolution both vertically and horizontally. You probably shouldn't see any banding with "Use gray levels" option in SwitchResX.

I'll try this again tomorrow and confirm whether any banding is still present with gray levels.

There exist HDMI 2.1 to DisplayPort adapters now. They have no benefit for HDMI 2.0 outputs except they support width > 4096. Perhaps you can chain a HDMI to DisplayPort adapter to a DisplayPort to HDMI adapter? But if you find that this is only working because of chroma sub sampling, then maybe the TH2G is not the way to go. What about the QH2G?

The stacked adapters idea is interesting. At least it would allow more than one T221 to run over TH2Gs as a single logical display at ~47 Hz. I've kept my eye out for a QuadHead2Go. I've been fortunate so far to find all of the DH2Gs and TH2Gs at under $100 used, but QH2Gs seem consistently more expensive as I've been browsing.

Once we learn from the DPCD what the limits of the TH2G are, we might be able to figure out what is needed to go beyond that.

Will definitely post back what I find, both directly over DP and when connected via the HDMI->DP adapter.

OpenCore can load Lilu/WhateverGreen earlier which might be necessary for some patches. I don't think the firmware version matters.

I may try installing OpenCore. I'm not even entirely convinced the pixel clock override is working properly since it seems the 358.20 MHz limit still appears as the DP connection is first established. By the time 600MHz appears the display is already showing an image (and the 2015 MBP can send 365MHz to the TH2G, so 358.20 MHz definitely isnt' the real DP limit.)

macOS supports tiled 4K60 MST displays but I don't know how I would get that to work for other displays and I don't know if it has code to handle an arbitrary number of tiles (more than two horizontal tiles).

Since I do have the two DVI-DL->LFH60 adapters and Accell DP->DVI DLs it should only require two 1920x2400@48Hz tiles. The left and right EDID tiles posted on the left column by Jack Doerner below may already fit exactly what would be needed here, but I don't fully understand how this works yet... https://jackdoerner.net/exposition/#2017/05/IBM_T221_Linux/

Yes, both the EDID DisplayID tile block and .mtdd override file support varying dimensions of tiles. The .mtdd can specify which tile is responsible for audio, which timings each tiled mode can use, and what EDID should be used to represent the entire display.

Very interesting. I clearly have a lot to learn still!

I don't think 6bpc is an option for HDMI / DVI. It's more likely using chroma sub sampling. chroma sub sampling doesn't affect gray scale output but 6bpc would.

I'll definitely run through all the chroma tests tomorrow and take photos. I initially found a few tests which seemed to confirm the output was not subsampled, but I didn't take photos and I should've. I don't even properly remember whether the banding was still present when I tried gray levels. Will post back...

Those appear to be errors from reading DPCD registers (0,16 is 00000h to 0000Fh and 20,3 is 00020h to 00022h). Since those are not DisplayPort devices, it reports errors. If you add 2>&1 to the end of the command, it will put those errors into the output file so you can see where they correspond to.

Thanks for this pointer; perfectly fits your explanation, the errors appear during the Register Dump of Port 3 [TMDS.]

 

[Amethyst1]

Very interesting. I'll definitely be curious to know what you find.

I did some quick testing with the 9503-DG3, using two links driven by the Iris Pro 5200 and two Delock 62603’s.

• 2× 1920×2400 at 34.128 Hz CVT-RB (172.00 MHz pixel clock) works. 173.00 MHz or higher pixel clocks don't.
• 2× 1568×2400 at 40.999 Hz CVT-RB (171.66 MHz pixel clock) works.
• The links don't have to run at the same resolution or refresh rate for the panel to sync, but there's visible tearing where the two tiles meet when displaying moving content, even when both are using the exact same timing.
• Unlike the 9503-DGP, the 9503-DG3 doesn't play ball with top and bottom tiles (I tried 2× 3840×1200). It just displays one of them.

Four in perfect servicability. I could only really justify the quantity due to the cables being so hard to come by and the prices for entire displays with multiple cables being so relatively inexpensive.

Awesome. I'm with you on the cables, I got one 2×SL-DVI<->LFH-60 cable with each of my three monitors, so I can only run one using more than two links at a time. I should have asked the guy I bought them from to throw in some extra cables...

If I get the EDIDs figured out and it really should work but still doesn't, it's probably sensical to find an RX 6800 eventually anyhow.

If you don't need HDMI 2.1, a Radeon RX 480/580 with three DisplayPort 1.4s, one dual-link DVI and one HDMI 2.0) or Radeon Pro W5700 (five miniDisplayPort 1.4s plus one USB-C with DisplayPort 1.4 Alternate Mode) may be less expensive.

 

[joevt]

I imagine if this is a hiccup I can fashion a couple of the hardware EDID override dongles originally sold alongside the DVI-DL->LFH-60 adapters (http://www.grimm.jp/edidrom) so that each of the two Accell DP devices will read a different EDID, and tiling info can be added per side. (the T221's onboard EDID flash mode will always output the same EDID for all connected signals, so I imagine even a clever software override would have trouble with that.)

Certainly a hardware EDID override is best. They exist for DVI and HDMI devices. Dr HDMI 8K works for HDMI 2.1 but doesn't support more than 256 bytes for the EDID which is a problem if you want to include a full CTA block and DisplayID block.

I don't know of a relatively inexpensive hardware EDID override for DisplayPort 1.4. And in that case, one might also want a DPCD override as well.

I may try installing OpenCore. I'm not even entirely convinced the pixel clock override is working properly since it seems the 358.20 MHz limit still appears as the DP connection is first established. By the time 600MHz appears the display is already showing an image (and the 2015 MBP can send 365MHz to the TH2G, so 358.20 MHz definitely isnt' the real DP limit.)

Pixel clock patch might work for some limits but not all limits. 358.20 MHz is a hardware limit related to HBR link rate and the inability of the macOS driver to allow 4:2:2 or 6bpc for higher pixel clocks. Need to see some AllRez output to better guess at what the MBP 2015 is doing.

Since I do have the two DVI-DL->LFH60 adapters and Accell DP->DVI DLs it should only require two 1920x2400@48Hz tiles. The left and right EDID tiles posted on the left column by Jack Doerner below may already fit exactly what would be needed here, but I don't fully understand how this works yet... https://jackdoerner.net/exposition/#2017/05/IBM_T221_Linux/

If the sample EDID's don't work, then EDIDs that look like the ASUS PQ321 might work? Can the display accept 1920x2160@60Hz? Otherwise the timings need to be modified.

 

[jeremywork]

I did some quick testing with the 9503-DG3, using two links driven by the Iris Pro 5200 and two Delock 62603’s.

• 2× 1920×2400 at 34.128 Hz CVT-RB (172.00 MHz pixel clock) works. 173.00 MHz or higher pixel clocks don't.
• 2× 1568×2400 at 40.999 Hz CVT-RB (171.66 MHz pixel clock) works.
• The links don't have to run at the same resolution or refresh rate for the panel to sync, but there's visible tearing where the two tiles meet when displaying moving content, even when both are using the exact same timing.
• Unlike the 9503-DGP, the 9503-DG3 doesn't play ball with top and bottom tiles (I tried 2× 3840×1200). It just displays one of them.

Thanks! This is interesting- so genlock isn't really a requirement, but the tiled mode isn't present on yours. According to wikipedia et al the DG1 (therefore also DG3?) received a firmware update which added 4x1920x1200 tile mode. I wonder if the files are still around to perform this update.

I'll see if I can also get 172 MHz working on the DGM/DGP at 1920 x 2400 with CVT-RB timing...

I'm also curious if you can record some observations about the actual panel timing. On the DGM/DGP it's very apparent using testUFO and my iPhone 6S's high speed video mode whenever a signal is being directly synced to the panel; stepping through frame-by-frame in quicktime player I can count the average number of 240fps frames between the point at which each UFO fades away as the next fades in are roughly equal. When the retiming buffer is active, this suddenly changes to a skipped UFO or a UFO that persists for twice as many frames. Of course, at 24 Hz the average is again consistent, but double the number of frames between changes. I'd be curious to know the behavior at 36, 37, 38, 39, 40, 41, 42 Hz, etc. to see if there's actually a direct sync range like the DGM/DGP seem to have. If it really is 'fixed,' the 41 Hz timing will be even, but 40- and 42+ will each exhibit dropping/pulldown.

If you don't need HDMI 2.1, a Radeon RX 480/580 with three DisplayPort 1.4s, one dual-link DVI and one HDMI 2.0) or Radeon Pro W5700 (five miniDisplayPort 1.4s plus one USB-C with DisplayPort 1.4 Alternate Mode) may be less expensive.

This is good info. The W5700 looks interesting...

Pixel clock patch might work for some limits but not all limits. 358.20 MHz is a hardware limit related to HBR link rate and the inability of the macOS driver to allow 4:2:2 or 6bpc for higher pixel clocks. Need to see some AllRez output to better guess at what the MBP 2015 is doing.

I still haven't installed OpenCore but I've attached the AllRez ouptuts for the MacPro/1080Ti using the two DH2Gs over DP + TH2G[DigitalSE] over HDMI (AllRezHDMI.txt) and the two DH2Gs + TH2G[DigitalSE] all over DP (AllRezDP.txt).

I connected the TH2G Digital SE to the 2015 MBP over DP again and my brain must have a memory leak something's fishy: SRX shows a limit of 360.00 MHz and not 365.00 MHz (but it showed 365 MHz last time I used it- maybe I need to use a different cable. Sorry about that! 😵) I dumped the AllRez data in this configuration (AllRezDigitalSE.txt) as well as the TH2G DP Edition connected to the 2015 MBP over DP (AllRezDPedition.txt).

If the sample EDID's don't work, then EDIDs that look like the ASUS PQ321 might work? Can the display accept 1920x2160@60Hz? Otherwise the timings need to be modified.

I just tested that it's stable at 2 x 1920x2160 @ 60Hz.
(At 2 x 1920 x 2400 @ 60 Hz the secondary stripe does flash black intermittently as cirthix described. This is a 9503-DGP, 2x DVI-DL->LFH60 without the overclock performed; signals not genlocked.)
It's good to know for overclocking that 60 Hz is stable at 3840x2160 though!

chroma sub sampling doesn't affect gray scale output but 6bpc would.

Interestingly it seems the banding is even more noticeable when using gray levels in SwitchResX. (Left of bezel is the two DH2G panel using DP ports; right is HDMI at 452.24 MHz.) Chroma tests look okay even when the banding is present.

anything meaningfully higher looks like a feverdream, but all desktop elements are still recognizeable and the T221 still shows a unified desktop over the three stripes, at 48Hz on the OSD.

This is using a more conventional 48, 32, 80; 2, 6, 26 timing mode at 466.92 MHz for 47.958 Hz on the HDMI->TH2G->T221. Something's overrun but it doesn't appear to be the DVI links...


So it seems if I want a single full bandwidth display the TH2G isn't viable without loss of color information.

 

[jeremywork]

I connected the TH2G Digital SE to the 2015 MBP over DP again and my brain must have a memory leak; SRX definitely shows a limit of 360.00 MHz and not 365.00 MHz. Sorry about that! 😵 I dumped the AllRez data in this configuration (AllRezDigitalSE.txt)

Perusing the AllRezDigitalSE.txt file I'm confused... SRX definitely showed 360.00 when I dumped it just now but clearly all of my saved modes (which worked fine still) were based on a 365.00 MHz limit, which is what I remember seeing and recording in the notes on my Bertha page.

I'll try a few different cables tomorrow to see if I can bring back the 365.00 MHz limit in SRX and dump AllRez again.

I edited the prior post in the meantime to reflect this confusion...

 

[Amethyst1]

Thanks! This is interesting- so genlock isn't really a requirement, but the tiled mode isn't present on yours.

I don't remember trying 4× 1920×1200 on the 9503-DG3 but the OSD does show the tiled mode as one of the four officially sanctioned configurations, just like on the 9503-DGP.

This is good info. The W5700 looks interesting...

If you can find it, there's also a Fujitsu RX 460 with the full set of outputs (3× DP, DL-DVI, HDMI) too. I have it. The fan says Zotac but I don't know if it's the original one. But the 460 is not a gaming card by any means. The RX 400/500 will work in High Sierra, the W5700 requires Catalina.

Perusing the AllRezDigitalSE.txt file I'm confused... SRX definitely showed 360.00 when I dumped it just now but clearly all of my saved modes (which worked fine still) were based on a 365.00 MHz limit, which is what I remember seeing and recording in the notes on my Bertha page.

It shows the TH2G[DigitalSE] is limited to HBR×4, implying a 360 MHz pixel clock limit via DisplayPort at 8bpc RGB.

## Register Dump Port 3 - Start ##
000000: 0x11 0x0a 0x84 0x01 0x00 0x00 0x00 0x00 0x02 0x07 0x00 0x00 0x00 0x00 0x01 0x00
  Reg: 000000: 11 : DPCD_REV: 1.1
  Reg: 000001: 0a : MAX_LINK_RATE: HBR
  Reg: 000002: 84 : MAX_LANE_COUNT: 4 [...]

I have tested my Berthas with additional Macs so if you want to add these to your website, you're most welcome. From oldest to newest:

• PowerBook G4 Titanium (2002) 800 MHz, ATI Mobility Radeon 7500: Mac OS 9.2.2; Mac OS X 10.1.5; Mac OS X 10.2.8: OK at 3840×2400 (12.7 Hz)
• PowerBook G4 17" (2004) 1.5 GHz, ATI Mobility Radeon 9700: Mac OS X 10.2.8: framebuffer update issues after width of 2656 pixels
• PowerBook G4 12" (2004) 1.33 GHz, NVIDIA GeForce FX 5200: Mac OS X 10.2.8/10.4.11: image totally corrupted
• PowerBook G4 12" (2005) 1.5 GHz, NVIDIA GeForce FX 5200: Mac OS X 10.4.11: image totally corrupted
• PowerBook G4 15" (2005) 1.67 GHz non-DLSD, ATI Mobility Radeon 9700: Mac OS X 10.3.9/10.4.11/10.5.8: framebuffer update issues after width of 2656 pixels (as you found)
• Mac mini G4 (2005) 1.33 GHz, ATI Radeon 9200: Mac OS 9.2.2: OK at 1920×2400 (20 Hz), image totally corrupted at 3840×2400 (12.7 Hz)
• Mac mini G4 (2005) 1.33 GHz, ATI Radeon 9200: Mac OS X 10.4.11: OK at 3840×2400 (12.7 Hz)
• MacBook Core 2 Duo (2008) 2.4 GHz, Intel GMA X3100: Mac OS X 10.6.8: monitor not recognised

Some other observations regarding the 9503-DGP (which are probably not very useful in most cases):

• (Some) single-link resolutions greater than 3840×2400 can be displayed but are truncated after 3840×2400 [photo at 5120×2880]
• Maximum single-link width I've been able to test is 8032 pixels (8192 including blanking; NVIDIA Kepler GPU limit) [photo at 8032×1968; 8032×1969 results in "out of sync" flashing]
• Maximum single-link height I've been able to test is 4075 lines (4096 including blanking; NVIDIA Kepler GPU limit) [photo at 3840×4075]
• If the combined width of the input timings exceeds 9999, the OSD displays 9999 [photo at 3× 3840×4075]

 

[joevt]

I still haven't installed OpenCore but I've attached the AllRez ouptuts for the MacPro/1080Ti using the two DH2Gs over DP + TH2G[DigitalSE] over HDMI (AllRezHDMI.txt) and the two DH2Gs + TH2G[DigitalSE] all over DP (AllRezDP.txt).

I connected the TH2G Digital SE to the 2015 MBP over DP again and my brain must have a memory leak something's fishy: SRX shows a limit of 360.00 MHz and not 365.00 MHz (but it showed 365 MHz last time I used it- maybe I need to use a different cable. Sorry about that! 😵) I dumped the AllRez data in this configuration (AllRezDigitalSE.txt) as well as the TH2G DP Edition connected to the 2015 MBP over DP (AllRezDPedition.txt).

The AllRezDigitalSE.txt says HBR x4 limit < 360MHz but the current mode is set to 365MHz. We need Lilu/WhateverGreen/OpenCore to capture the properties since all your GPUs have drivers from a generation that doesn't report color info in the detailed timings.

I just tested that it's stable at 2 x 1920x2160 @ 60Hz.
(At 2 x 1920 x 2400 @ 60 Hz the secondary stripe does flash black intermittently as cirthix described. This is a 9503-DGP, 2x DVI-DL->LFH60 without the overclock performed; signals not genlocked.)
It's good to know for overclocking that 60 Hz is stable at 3840x2160 though!

Then maybe the display could work as a 4K MST display. It depends if macOS will accept the two tiles with appropriate EDIDs connected to an MST hub. There might still be differences between that and a real 4K MST display. I don't think I have an AllRez dump from a 4K MST display so I don't know what the MST stuff looks like. 4K MST displays don't have a .mtdd file. For the ASUS PQ321, I only have the EDID for the left tile.

Interestingly it seems the banding is even more noticeable when using gray levels in SwitchResX. (Left of bezel is the two DH2G panel using DP ports; right is HDMI at 452.24 MHz.) Chroma tests look okay even when the banding is present.

I would use a programatically generated image of gradients to test this like the one I linked.

This is using a more conventional 48, 32, 80; 2, 6, 26 timing mode at 466.92 MHz for 47.958 Hz on the HDMI->TH2G->T221. Something's overrun but it doesn't appear to be the DVI links...

Hard to say if the problem is with the display or with the TH2G. Maybe if you had other displays to test the same mode. It's interesting how the first few pixels if each scan line have correct colors.

 

[Amethyst1]

For the ASUS PQ321, I only have the EDID for the left tile.

These look to be EDIDs for both tiles of the Dell UP2414Q.

I connected the TH2G Digital SE to the 2015 MBP over DP again […]

Would you be willing to open the TH2G-DP and TH2G-SE to reveal which chipset they use? The DH2G-ME and DH2G-SE use an IDT VMM1402.

 

[jeremywork]

I don't remember trying 4× 1920×1200 on the 9503-DG3 but the OSD does show the tiled mode as one of the four officially sanctioned configurations, just like on the 9503-DGP.

Oops, I misinterpreted your 2 x 3840x1200 as using the two DH2Gs because I somehow missed that Bertha can actually display this configuration using two DVI-SL links. Interestingly the OSD considers this a stripe configuration even though the two "stripes" are stacked vertically.

If I run the same configuration using two DVI-DL links it simply displays them side-by-side and cuts off the right half of each stripe (this is why I thought it didn't work.)

I have tested my Berthas with additional Macs so if you want to add these to your website, you're most welcome. From oldest to newest:

Much appreciated! I'll add these to my tested machines section shortly. Likewise, feel free to mirror/summarize any of the information on my site if you feel inclined.

Some other observations regarding the 9503-DGP (which are probably not very useful in most cases):

• (Some) single-link resolutions greater than 3840×2400 can be displayed but are truncated after 3840×2400 [photo at 5120×2880]
• Maximum single-link width I've been able to test is 8032 pixels (8192 including blanking; NVIDIA Kepler GPU limit) [photo at 8032×1968; 8032×1969 results in "out of sync" flashing]
• Maximum single-link height I've been able to test is 4075 lines (4096 including blanking; NVIDIA Kepler GPU limit) [photo at 3840×4075]
• If the combined width of the input timings exceeds 9999, the OSD displays 9999 [photo at 3× 3840×4075]

Fascinating. I wonder if the entirety of those frames are actually being stored on Bertha's framebuffer. Although oversize resolutions may not be particularly useful, I've wondered for a while if it would be possible to sacrifice some refresh to use the bandwidth for 30-bit color data (if it's even possible to do that over DVI.) If the framebuffer has the space to store it and the firmware can be adapted, the panel already translates 30-bit data from the output side of the buffer for the purposes of color calibration if I understand correctly.

The AllRezDigitalSE.txt says HBR x4 limit < 360MHz but the current mode is set to 365MHz. We need Lilu/WhateverGreen/OpenCore to capture the properties since all your GPUs have drivers from a generation that doesn't report color info in the detailed timings.

Ahh, got it. I'll work on getting OpenCore running on the MBP first since it's less infrastructural to me, but I'll install it to both of them once I get the hang of it.

I would use a programatically generated image of gradients to test this like the one I linked.

Sorry I missed the code there (thanks for supplying it!) I do notice a difference in the banding by the time it reaches the two displays (DP and HDMI->DP) but if I use Utilities/Digital Color Meter with a 5x5 aperture I see the exact same R/G/B values on the two images as I crawl across the 10/12-bit part of the gradient (where on one screen I can see banding and the other I can't.) The image was opened in Preview FWIW but seemed to tell what we need it to for this test.

Hard to say if the problem is with the display or with the TH2G. Maybe if you had other displays to test the same mode. It's interesting how the first few pixels if each scan line have correct colors.

I've figured if the DVI outputs on the TH2G or the input buffers on the T221 were overrun I'd see this same pattern three times on the display instead of just once. Either the DP out on the HDMI adapter or the DP input on the TH2G seems more suspect IMO. I have other T221s but the only other display I have with a DP input is an EIZO SX2462W (1920x1200@49-62Hz) so I can't run the HDMI adapter above 452 MHz with that.

Maybe I can get the HDMI working on the DP edition with two Accell adapters and two 30-inch Cinema displays somewhere in the 50-60Hz range but that might take some fiddling... when I tried the two Accell + DP Edition on the T221 with two DVI-DL->LFH60 adapters it wasn't able to run past about 271 MHz for the entire panel at 8pbc, significantly less than with two DVI-SL links (345.2 MHz.)

Would you be willing to open the TH2G-DP and TH2G-SE to reveal which chipset they use? The DH2G-ME and DH2G-SE use an IDT VMM1402.

I'd be happy to. I've just done the DP Edition and it's using an IDT VPP1101. (Full resolution image at http://stormdecay.com:1984/rd/rd_matrox.html)

I'll do the Digital SE tomorrow since there'll be a second one arriving in the mail (even if I'm stuck with 37Hz or 47Hz/banding it's worth not resizing my windows all the time...)

 

[joevt]

These look to be EDIDs for both tiles of the Dell UP2414Q.

Good find. Interesting how they blank the serial number in the parsed output but not the hex output. That's one of the 4K MST displays that macOS should be able to support.
https://web.archive.org/web/20191123020413/support.apple.com/en-us/HT206587
One thing to consider is that an MST display may count as two displays even though it behaves as a single display which is why a video wall processor like the Matrox devices is useful.
https://web.archive.org/web/20210127072021/support.apple.com/en-us/HT208366

Would you be willing to open the TH2G-DP and TH2G-SE to reveal which chipset they use? The DH2G-ME and DH2G-SE use an IDT VMM1402.

The DPCD doesn't show OUI for the Matrox devices but does show this:

                        Sink Device-Specific
                            004a0h : 49 44 54 31 33 31 03 04 00 00 00 00 00 00 00 00 // IDT131..........
                            004b0h : 8c 00 02 00 00 00 00 00 02 00 00 00 04 00 00 00 // ................
                            004c0h : 01 52 41 43 4c 45 00 00 00 00 00 00 00 00 00 00 // .RACLE..........

In Synaptics devices, the chip number is the last two bytes of the BRANCH_ID, so VMM6100 is like this:

                        Branch Device-Specific
                            00500h BRANCH_OUI: 90-CC-24 = Synaptics, Inc
                            00503h BRANCH_ID: 53 59 4e 41 61 00 // SYNAa.
                            00509h BRANCH_HW_REV: 1.0
                            0050ah BRANCH_SW_REV: 6.3
                            0050ch : 7b 06 00 00 // {...
                            005e0h : 0f 41 55 58 20 63 6c 6f 63 6b 20 69 73 20 32 34 // .AUX clock is 24

You can also see there a line of text at 005e0h. This appears to be part of some kind of console output which I haven't explored. Maybe the full output can be seen using the Synaptics firmware update tools in Windows.
https://forums.macrumors.com/thread...ith-apple-silicon-m1-m2-now-possible.2381664/
The VMM7100 has a similar log but not the VMM5210, VMM5333, VMM5350.

 

[Amethyst1]

Oops, I misinterpreted your 2 x 3840x1200 as using the two DH2Gs because I somehow missed that Bertha can actually display this configuration using two DVI-SL links.

Yeah, the 9503-DG5/DGM/DGP can do it. The 9503-DG3 can't.

Interestingly the OSD considers this a stripe configuration even though the two "stripes" are stacked vertically.

Maybe the OSD considers any 2× config a stripe (Update: the manual confirms this is the case)? I wonder what 3× 3840×800 (does that work?) is considered to be.

I have other T221s but the only other display I have with a DP input is an EIZO SX2462W (1920x1200@49-62Hz) so I can't run the HDMI adapter above 452 MHz with that.

Can you provide images from the adapter or open it to reveal its chipset? I have a DP display capable of handling >700 MHz I could test it with, if I got hold of one.

I've just done the DP Edition and it's using an IDT VPP1101.

Thanks a lot. That's the same chipset as the DH2G-DP [images]. This discovery has made me buy a DH2G-DP to see if it can drive the 9503-DG3 at 3840×2400 using two DVI-SL’s as your tests have shown the TH2G-DP can handle that resolution.

 

[jeremywork]

I wonder what 3× 3840×800 (does that work?) is considered to be.

Unfortunately, tile mode both on the OSD and on the panel. (7680 x 1600)

Can you provide images from the adapter or open it to reveal its chipset? I have a DP display capable of handling >700 MHz I could test it with, if I got hold of one.

I'll try to do this soon. I'm curious about it too...

Thanks a lot. That's the same chipset as the DH2G-DP [images]. This discovery has made me buy a DH2G-DP to see if it can drive the 9503-DG3 at 3840×2400 using two DVI-SL’s as your tests have shown the TH2G-DP can handle that resolution.

Interesting, looks like the DH2G DP Edition is the same board as the TH2G DP Edition but missing an output driver. The board in that photo looks to be F7361-02 REV.A and mine is F7361-04 REV.B.
Assuming all else is identical this mode should work for you...


I used my 2012 15" MBP for this photo since the 2015 has the buffer limit. I had never used the 62603 on this one before and I noticed in SRX it appeared with a total clock limit of 179.10 MHz which I thought was oddly specific.

I did confirm the 172.06 MHz 1920 x 2400 mode with CVT-RB timings works for me too, though I can use 48, 32, 56; 1, 2, 1 at 170.62 MHz for a faster overall refresh FWIW.

For 1280 x 2400 at its maximum 176.64 MHz I need to use 48, 32, 62 instead of 48, 32, 56.

Turns out Bertha will accept the full 179.10 MHz signal at 960 x 2400 for nearly 68 Hz, but at 48, 32, 56; 1, 2, 1. At the EDID provided 8, 32, 56; 2, 2, 20; H+, V+ I can run 68.198 Hz (almost a quarter hertz faster) but only up to 174.57 MHz.

 

[Amethyst1]

Unfortunately, tile mode both on the OSD and on the panel. (7680 x 1600)

Presumably 4× 3840×600 doesn't work either then.

Interesting, looks like the DH2G DP Edition is the same board as the TH2G DP Edition but missing an output driver. The board in that photo looks to be F7361-02 REV.A and mine is F7361-04 REV.B.
Assuming all else is identical this mode should work for you...

I'm definitely going to give this a try.

I had never used the 62603 on this one before and I noticed in SRX it appeared with a total clock limit of 179.10 MHz which I thought was oddly specific.

This is the limit for HBR×2 at 8bpc RGB. Strange since the MBP and the 62603 can do HBR×4. Actually, the NVIDIA GPU can do HBR2×4 but the Thunderbolt 1 controller can’t.

I found additional documentation. Some notes from these that may be worth adding to your site (model names link to sources). I tried to match IBM models to "clones" based on what EDIDs and configurations they can handle.

IBM 9503-DG0:

• No controls except for power button and a mechanical brightness slider.
• No mention of an OSD or programmable EDIDs.
• The only supported modes listed are 960×1200@41Hz and 4× 960×2400@41Hz (actually listed as 4× 960×1200@41Hz but that must be a typo.)

IBM 9503-DG1:

• Default EDID is 020 for 4× 960×2400@41Hz.
• Alternative documented EDIDs are 029, 034 and 035.
• Other modes are 3840×2400@12.7Hz, 2× 1920×2400@20Hz, 2× 1920×2400@24Hz, 2× 1920×2400@25Hz, 4× 1920×1200@41Hz (after firmware update).

IBM 9503-DG3:

• Default EDID is 029.
• Alternative documented EDIDs are 020, 021, 034 and 035.

IDTech MD22292B:

• MD22292B1 = 9503-DG1
• MD22292B2 = 9503-DG3
• MD22292B5 = 9503-DG5/DGM/DGP

Iiyama AQU5611D[T] BK:

• Based on 9503-DG3.
• The only alternative documented EDID is 029.
• 960×1200 is not listed.
• Lists an additional 3840×2400@13Hz mode (129 MHz pixel clock) [found in EDID 030 and 031].

ViewSonic VP2290b:

• VP2290b = 9503-DG3
• VP2290b-2 = 9503-DG3
• VP2290b-3 = 9503-DG5/DGM/DGP
• 960×1200 is called "MATROX VGA".
• Lists an additional 3840×2400@13Hz mode (129 MHz pixel clock) [found in EDID 030 and 031].
• EDIDs are numbered differently and timings don't quite match the 9503's.

The following table tries to match the EDIDs based on what modes they include.

IBM	ViewSonic
029	001
034	002
035	003
	004 (')
	005 (')
021	006 (*)
002	007
003	008
036	009
037	010
045	011
006	012 (*)
022	013 (*)

(') Listed as for internal testing purposes only. Not documented further.
(*) IBM's EDIDs contain up to four timings. ViewSonic's contain up to three. ViewSonic's EDIDs 006, 012 and 013 are missing the two-links ("twin input") configuration.

Addendum: I tried to change my 9503-DG3's EDID to 020, 034 and 035 as they're not documented on your site. The process failed everytime with an "x" behind the number. My DCC version is 3.5, so the numbers are valid and I tried powering off/on as well as power-cycling after the procedure.

 

[joevt]

Without OpenCore, installing my Lilu/WhateverGreen should at least allow AllRez to show additional attribute info and maybe that will show how > 360 MHz is obtainable for some HBR x4 limited connections.

You just need -iofbon as a boot-arg and restart. Then run AllRez for the > 360MHz mode.

I tested this in High Sierra with a Radeon HD 4870 but haven't found a > 360MHz mode for that.

 

[Amethyst1]

I tested this in High Sierra with a Radeon HD 4870 but haven't found a > 360MHz mode for that.

I could only get >360 MHz modes working in Snow Leopard and Lion.

 

[jeremywork]

This is the limit for HBR×2 at 8bpc RGB. Strange since the MBP and the 62603 can do HBR×4. Actually, the NVIDIA GPU can do HBR2×4 but the Thunderbolt 1 controller can’t.

Ah, this makes sense. I think the mDP connector was dirty, after a couple inserts SRX showed 358.20 (I should've noticed the relation between those two figures.)

Maybe this isn't anything new, but it seems the T221 is more limited by the total width and refresh than the total height or total bandwidth. Following yesterday's post I tried a bunch of additional timings to try to determine the upper limits for each "full," "half," "third," and "quarter" modes. In cases where CVT-RB uses a wider picture, the overall refresh is slightly reduced but the total timing limit is higher. In cases where I used the same width as an EDID but a tighter height, the total allowed bandwidth seems to stay the same and a higher refresh is allowed as a result.

I'm still not finished testing modes, but seems this pattern was worth mentioning. I've added color coding to my "tested and overclocked inputs" section because it was getting messy with 'tightest stable modes' and fastest CVT-RB modes.

I realize increasing the vertical refresh should usually be accompanied by more vertical blanking, but I'm not sure how much it matters on this display since the panel is fed by an onboard buffer. I don't notice much visual difference in motion clarity between the tighest and CVT-RB modes, but maybe later I'll catch it on the high speed camera to be sure...

I found additional documentation. Some notes from these that may be worth adding to your site (model names link to sources). I tried to match IBM models to "clones" based on what EDIDs and configurations they can handle.

Thank you so much! I'll definitely incorporate this information into the EDID data section as well as the model breakdown section.

Addendum: I tried to change my 9503-DG3's EDID to 020, 034 and 035 as they're not documented on your site. The process failed everytime with an "x" behind the number. My DCC version is 3.5, so the numbers are valid and I tried powering off/on as well as power-cycling after the procedure.

Interesting. Out of curiosity did you try (after power cycling) dumping the EDID in SRX anyways? I have at least one which successfully changes EDID modes but always shows the X. I can't find anything practically wrong with it, despite that the documentation states this is a failure to switch modes.

Without OpenCore, installing my Lilu/WhateverGreen should at least allow AllRez to show additional attribute info and maybe that will show how > 360 MHz is obtainable for some HBR x4 limited connections.

You just need -iofbon as a boot-arg and restart. Then run AllRez for the > 360MHz mode.

I appreciate this, though something seems to have stopped working. I can verify Lilu and WhateverGreen both appear in the MBP's IOResources section in IORegistryExplorer and '-iofbon' appears in 'boot-args' when running 'nvram -p' but the MBP screen blacks out and the external display doesn't come on whenever the TH2G is plugged in. All I can seem to do to resolve this is unplug the display and hard reboot without the display plugged in to get the internal display back. Same thing happens if starting up with the TH2G already connected.

I'm pretty far out of my depth here but I did find the guide for installing OpenCore on the MacPro5,1 so I'm going to try following that to hopefully have a USB drive act as the OC EFI partition in case something goes wrong.

Can you provide images from the adapter or open it to reveal its chipset?

I did pop the shield off (easier than I expected) and it's using a Lontium LT6711A. I couldn't easily find a device manufacturer so I put the full resolution photos in this temp directory: http://stormdecay.com:1984/rd/rd_orphans.html