Quoth qwx@sciops.net: > On Wed Apr 5 00:39:47 +0200 2023, igor@9lab.org wrote: > > I have a TP t420s as well as a x230i connected to an LG Ultrawide > > screen at 3440x1440. The following shows the TP t420s: > > > > • https://9lab.org/plan9/thinkpad-t420s/#monitor > > > > The LG Ultrawide works just as well via DP with the TP x230i; here is > > my /lib/vgadb entry for the screen: > > > > # LG ULTRAWIDE > > lgUW=3440x1440 # 60Hz > > clock=319.75 > > shb=3488 ehb=3520 ht=3600 > > vrs=1443 vre=1453 vt=1481 > > hsync=+ vsync=- > > > > With that entry in place I can use the monitor on the x230i as > > follows: > > > > % @{rfork n; aux/realemu; aux/vga -m lgUW -l '3440x1440'} > > > > … with a resolution of 3440x1440. > > Nice! The issue does also depend on the actual monitor as well, but > it's good to know that some work at least. I should recheck my own. > > Cheers, > qwx Thank you, sl, igor, qwx. I figured out the problem--the DisplayPort link training needed to be implemented more fully. I didn't know really much at all about DisplayPort; that has changed. I've attached a patch that implements pattern 1 & 2 training for HBR, along with fixing a couple other minor things I came across.[1] I'd be curious if the patch works for you, igor and qwx. I don't see why it wouldn't, but who knows. Reader be warned: I'm not a C programmer, so I'm sure there's much that can be improved upon. To test my patch, I defined this test function to ensure I could get my working display back. I didn't need to add anything to /lib/vgadb. fn lg { @ { rfork n; aux/realemu; cd /sys/src/cmd/aux/vga; mk; /sys/src/cmd/aux/vga/6.out -v -V -m igfx -l 2560x1080; sleep 5; aux/vga -m igfx -l 1366x768 } } My monitor is consistently working at 2560x1080 now, with a passive DP cable. However, since the LG is a monitor that is notorious for agress power-savings mode, I need to run 'lg' pretty quickly upon connection, otherwise the monitor will already be in a deep sleep state.[2] - Romano [1] VGA connected displays are defined the VGA BIOS OEM docs from 1989; EDID data (or perhaps its superset, DisplayID) can wrap, so the shifting sub should account for that. [2] My next project might be implementing I2C over DP AUX more generally, which I think is needed query and send a monitor control command to "wake up" the monitor before running the training patterns. There's i2c(3), which I looked at briefly, and am wondering if it would make sense to create a driver to expose the I2C-over-AUX DisplayPorts as I2C devices so that i2c(3) can then be leveraged.