* [9front] displayport thinkpad x230 external monitor black screen @ 2023-03-30 17:37 Romano 2023-03-30 17:47 ` Stanley Lieber ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Romano @ 2023-03-30 17:37 UTC (permalink / raw) To: 9front I have a TP x230 that has a displayport and vga socket. I have an adapter from vga-to-hdmi (wиth а USB dongle for power) that works with an ultrawide LG, but the largest mode via VGA is 1920x1080. Using the displayport to connect to the monitor shows a 2560x1080 mode, along with the same modes that are shown with the VGA adapter. However, when trying to use any mode with the displayport directly, I just get a black screen. I ran 'cat /dev/vgactl' "blind", when using the ultrawide LG external monitor to see if that yielded anything interesting, but didn't see it. I then switched back to built-in LCD screen to capture the rc output, which I've attached to the end of this message. I reviewed the log for changes to igfx to see if I could pin down the commit that might be related, and the best I could come up with is 6f63752d84254b470322fc028dce1c79f7443e3b back in May 2017 (almost 6 years ago). I reverted /sys/src/9/pc/vgaigfx.c to that commit to see if it would build, but unsurprisingly, it does not: vgaigfx.c:18 structure not fully declared Pcidev vgaigfx.c:68 structure not fully declared Pcidev warning: vgaigfx.c:61 used and not set: gtt vgaigfx.c:92 structure not fully declared Pcidev vgaigfx.c:92 structure not fully declared Pcidev vgaigfx.c:95 structure not fully declared Pcidev vgaigfx.c:95 structure not fully declared Pcidev vgaigfx.c:161 structure not fully declared Pcidev vgaigfx.c:214 name not declared: arrow Before go any further, I thought I'd ask on the list: has anyone had something similar happen, or know of where the problem might be? # --- rc output when connecting to external monitor --- cpu% whatis modes fn modes { @ { rfork n; aux/realemu; aux/vga -m igfx -p } } cpu% modes ... edid mfr LGD edid serialstr edid name edid product 728 edid serial 0 edid version 1.3 edid mfrdate 2012.0 edid size (cm) 28x16 edid gamma 2.20 edid vert (Hz) 0-0 edid horz (Hz) 0-0 edid pclkmax 0 edid flags digital standby suspend activeoff edid 1366x768@60Hz clock=75.2 shb=1414 ehb=1478 ht=1582 vrs=772 vre=779 vt=792 hsync=+ vsync=- edid mfr GSM edid serialstr edid name LG ULTRAWIDE edid product 23026 edid serial 256914 edid version 1.4 edid mfrdate 2021.6 edid size (cm) 80x34 edid gamma 2.20 edid vert (Hz) 56-75 edid horz (Hz) 30000-90000 edid pclkmax 240000000 edid flags digital standby edid 2560x1080@60Hz clock=185.58 shb=2624 ehb=2688 ht=2784 vrs=1083 vre=1093 vt=1111 hsync=- vsync=- edid 1920x1080@60Hz clock=148.5 shb=2008 ehb=2052 ht=2200 vrs=1084 vre=1089 vt=1125 hsync=+ vsync=- edid 640x480@60Hz clock=25.175 shb=656 ehb=752 ht=800 vrs=490 vre=492 vt=525 hsync=- vsync=- edid 640x480@75Hz clock=31.5 shb=656 ehb=720 ht=840 vrs=481 vre=484 vt=500 hsync=- vsync=- edid 800x600@60Hz clock=40 shb=840 ehb=968 ht=1056 vrs=601 vre=605 vt=628 hsync=+ vsync=+ edid 800x600@75Hz clock=49.5 shb=816 ehb=896 ht=1056 vrs=601 vre=604 vt=625 hsync=+ vsync=+ edid 1024x768@60Hz clock=65 shb=1048 ehb=1184 ht=1344 vrs=771 vre=777 vt=806 hsync=- vsync=- edid 1024x768@75Hz clock=78.75 shb=1040 ehb=1136 ht=1312 vrs=769 vre=772 vt=800 hsync=+ vsync=+ edid 1280x1024@75Hz clock=135 shb=1296 ehb=1440 ht=1688 vrs=1025 vre=1028 vt=1066 hsync=+ vsync=+ cpu% whatis lcd fn lcd { @ { rfork n; aux/realemu; aux/vga -m igfx -l 1366x768 } } cpu% whatis lg fn lg { @ { rfork n; aux/realemu; aux/vga -m igfx -l 1920x1080 } } cpu% cat /dev/vgactl type igfx size 1376x768x32 x8r8g8b8 actualsize 1366x768 tilt none hwgc igfxhwgc hwaccel off hwblank on addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 softscreen on cpu% lg cpu% cat /dev/vgactl type igfx size 1920x1080x32 x8r8g8b8 tilt none hwgc igfxhwgc hwaccel off hwblank on addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 softscreen on cpu% lcd cpu% ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-03-30 17:37 [9front] displayport thinkpad x230 external monitor black screen Romano @ 2023-03-30 17:47 ` Stanley Lieber 2023-04-03 22:27 ` qwx 2023-04-04 22:39 ` igor 2 siblings, 0 replies; 18+ messages in thread From: Stanley Lieber @ 2023-03-30 17:47 UTC (permalink / raw) To: 9front On March 30, 2023 1:37:57 PM EDT, Romano <unobe@cpan.org> wrote: >I have a TP x230 that has a displayport and vga socket. I have an >adapter from vga-to-hdmi (wиth а USB dongle for power) that works with >an ultrawide LG, but the largest mode via VGA is 1920x1080. Using the >displayport to connect to the monitor shows a 2560x1080 mode, along >with the same modes that are shown with the VGA adapter. However, >when trying to use any mode with the displayport directly, I just get >a black screen. I ran 'cat /dev/vgactl' "blind", when using the >ultrawide LG external monitor to see if that yielded anything >interesting, but didn't see it. I then switched back to built-in LCD >screen to capture the rc output, which I've attached to the end of this >message. > >I reviewed the log for changes to igfx to see if I could pin down the commit >that might be related, and the best I could come up with is > 6f63752d84254b470322fc028dce1c79f7443e3b >back in May 2017 (almost 6 years ago). I reverted >/sys/src/9/pc/vgaigfx.c to that commit to see >if it would build, but unsurprisingly, it does not: > >vgaigfx.c:18 structure not fully declared Pcidev >vgaigfx.c:68 structure not fully declared Pcidev >warning: vgaigfx.c:61 used and not set: gtt >vgaigfx.c:92 structure not fully declared Pcidev >vgaigfx.c:92 structure not fully declared Pcidev >vgaigfx.c:95 structure not fully declared Pcidev >vgaigfx.c:95 structure not fully declared Pcidev >vgaigfx.c:161 structure not fully declared Pcidev >vgaigfx.c:214 name not declared: arrow > >Before go any further, I thought I'd ask on the list: has anyone had >something similar happen, or know of where the problem might be? > ># --- rc output when connecting to external monitor --- >cpu% whatis modes >fn modes { > @ { > rfork n; aux/realemu; aux/vga -m igfx -p > } >} >cpu% modes >... >edid mfr LGD >edid serialstr >edid name >edid product 728 >edid serial 0 >edid version 1.3 >edid mfrdate 2012.0 >edid size (cm) 28x16 >edid gamma 2.20 >edid vert (Hz) 0-0 >edid horz (Hz) 0-0 >edid pclkmax 0 >edid flags digital standby suspend activeoff >edid 1366x768@60Hz > clock=75.2 > shb=1414 ehb=1478 ht=1582 > vrs=772 vre=779 vt=792 > hsync=+ vsync=- >edid mfr GSM >edid serialstr >edid name LG ULTRAWIDE >edid product 23026 >edid serial 256914 >edid version 1.4 >edid mfrdate 2021.6 >edid size (cm) 80x34 >edid gamma 2.20 >edid vert (Hz) 56-75 >edid horz (Hz) 30000-90000 >edid pclkmax 240000000 >edid flags digital standby >edid 2560x1080@60Hz > clock=185.58 > shb=2624 ehb=2688 ht=2784 > vrs=1083 vre=1093 vt=1111 > hsync=- vsync=- >edid 1920x1080@60Hz > clock=148.5 > shb=2008 ehb=2052 ht=2200 > vrs=1084 vre=1089 vt=1125 > hsync=+ vsync=- >edid 640x480@60Hz > clock=25.175 > shb=656 ehb=752 ht=800 > vrs=490 vre=492 vt=525 > hsync=- vsync=- >edid 640x480@75Hz > clock=31.5 > shb=656 ehb=720 ht=840 > vrs=481 vre=484 vt=500 > hsync=- vsync=- >edid 800x600@60Hz > clock=40 > shb=840 ehb=968 ht=1056 > vrs=601 vre=605 vt=628 > hsync=+ vsync=+ >edid 800x600@75Hz > clock=49.5 > shb=816 ehb=896 ht=1056 > vrs=601 vre=604 vt=625 > hsync=+ vsync=+ >edid 1024x768@60Hz > clock=65 > shb=1048 ehb=1184 ht=1344 > vrs=771 vre=777 vt=806 > hsync=- vsync=- >edid 1024x768@75Hz > clock=78.75 > shb=1040 ehb=1136 ht=1312 > vrs=769 vre=772 vt=800 > hsync=+ vsync=+ >edid 1280x1024@75Hz > clock=135 > shb=1296 ehb=1440 ht=1688 > vrs=1025 vre=1028 vt=1066 > hsync=+ vsync=+ >cpu% whatis lcd >fn lcd { > @ { > rfork n; aux/realemu; aux/vga -m igfx -l 1366x768 > } >} >cpu% whatis lg >fn lg { > @ { > rfork n; aux/realemu; aux/vga -m igfx -l 1920x1080 > } >} >cpu% cat /dev/vgactl >type igfx >size 1376x768x32 x8r8g8b8 >actualsize 1366x768 >tilt none >hwgc igfxhwgc >hwaccel off >hwblank on >addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 >softscreen on >cpu% lg >cpu% cat /dev/vgactl >type igfx >size 1920x1080x32 x8r8g8b8 >tilt none >hwgc igfxhwgc >hwaccel off >hwblank on >addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 >softscreen on >cpu% lcd >cpu% > > i do not have direct experience with the x230 vs displayport, but with my x301 vs displayport i needed to use an "active" adapter. this was years ago and i no longer have the hardware, but this might be a place to start. sl ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-03-30 17:37 [9front] displayport thinkpad x230 external monitor black screen Romano 2023-03-30 17:47 ` Stanley Lieber @ 2023-04-03 22:27 ` qwx 2023-04-04 22:39 ` igor 2 siblings, 0 replies; 18+ messages in thread From: qwx @ 2023-04-03 22:27 UTC (permalink / raw) To: 9front On Thu Mar 30 19:37:16 +0200 2023, unobe@cpan.org wrote: > I have a TP x230 that has a displayport and vga socket. I have an > adapter from vga-to-hdmi (wиth а USB dongle for power) that works with > an ultrawide LG, but the largest mode via VGA is 1920x1080. Using the > displayport to connect to the monitor shows a 2560x1080 mode, along > with the same modes that are shown with the VGA adapter. However, > when trying to use any mode with the displayport directly, I just get > a black screen. Displayport not working is unfortunately a frequent issue for sandybridge (x220) and above, possibly even from earlier generations. I don't know what the issue is, it could be a lot of things, but checking for a regression is a very good idea. iirc x230 is among the first models that were worked on. > I reviewed the log for changes to igfx to see if I could pin down the commit > that might be related, and the best I could come up with is > 6f63752d84254b470322fc028dce1c79f7443e3b > back in May 2017 (almost 6 years ago). I reverted > /sys/src/9/pc/vgaigfx.c to that commit to see > if it would build, but unsurprisingly, it does not: > > vgaigfx.c:18 structure not fully declared Pcidev > vgaigfx.c:68 structure not fully declared Pcidev > warning: vgaigfx.c:61 used and not set: gtt > vgaigfx.c:92 structure not fully declared Pcidev > vgaigfx.c:92 structure not fully declared Pcidev > vgaigfx.c:95 structure not fully declared Pcidev > vgaigfx.c:95 structure not fully declared Pcidev > vgaigfx.c:161 structure not fully declared Pcidev > vgaigfx.c:214 name not declared: arrow You won't get far by reverting just this one file, a lot of system-wide changes have happened since; you'll have to also revert the rest of the changes elsewhere. I'd also go earlier and revert to 21570a47195d90b1dc2a3634d8042929543599d3. Perhaps just use a separate tree or something. Hope this helps, qwx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-03-30 17:37 [9front] displayport thinkpad x230 external monitor black screen Romano 2023-03-30 17:47 ` Stanley Lieber 2023-04-03 22:27 ` qwx @ 2023-04-04 22:39 ` igor 2023-04-04 22:43 ` sl 2023-04-05 7:01 ` qwx 2 siblings, 2 replies; 18+ messages in thread From: igor @ 2023-04-04 22:39 UTC (permalink / raw) To: 9front; +Cc: igor 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. Quoth Romano <unobe@cpan.org>: > I have a TP x230 that has a displayport and vga socket. I have an > adapter from vga-to-hdmi (wиth а USB dongle for power) that works with > an ultrawide LG, but the largest mode via VGA is 1920x1080. Using the > displayport to connect to the monitor shows a 2560x1080 mode, along > with the same modes that are shown with the VGA adapter. However, > when trying to use any mode with the displayport directly, I just get > a black screen. I ran 'cat /dev/vgactl' "blind", when using the > ultrawide LG external monitor to see if that yielded anything > interesting, but didn't see it. I then switched back to built-in LCD > screen to capture the rc output, which I've attached to the end of this > message. > > I reviewed the log for changes to igfx to see if I could pin down the commit > that might be related, and the best I could come up with is > 6f63752d84254b470322fc028dce1c79f7443e3b > back in May 2017 (almost 6 years ago). I reverted > /sys/src/9/pc/vgaigfx.c to that commit to see > if it would build, but unsurprisingly, it does not: > > vgaigfx.c:18 structure not fully declared Pcidev > vgaigfx.c:68 structure not fully declared Pcidev > warning: vgaigfx.c:61 used and not set: gtt > vgaigfx.c:92 structure not fully declared Pcidev > vgaigfx.c:92 structure not fully declared Pcidev > vgaigfx.c:95 structure not fully declared Pcidev > vgaigfx.c:95 structure not fully declared Pcidev > vgaigfx.c:161 structure not fully declared Pcidev > vgaigfx.c:214 name not declared: arrow > > Before go any further, I thought I'd ask on the list: has anyone had > something similar happen, or know of where the problem might be? > > # --- rc output when connecting to external monitor --- > cpu% whatis modes > fn modes { > @ { > rfork n; aux/realemu; aux/vga -m igfx -p > } > } > cpu% modes > ... > edid mfr LGD > edid serialstr > edid name > edid product 728 > edid serial 0 > edid version 1.3 > edid mfrdate 2012.0 > edid size (cm) 28x16 > edid gamma 2.20 > edid vert (Hz) 0-0 > edid horz (Hz) 0-0 > edid pclkmax 0 > edid flags digital standby suspend activeoff > edid 1366x768@60Hz > clock=75.2 > shb=1414 ehb=1478 ht=1582 > vrs=772 vre=779 vt=792 > hsync=+ vsync=- > edid mfr GSM > edid serialstr > edid name LG ULTRAWIDE > edid product 23026 > edid serial 256914 > edid version 1.4 > edid mfrdate 2021.6 > edid size (cm) 80x34 > edid gamma 2.20 > edid vert (Hz) 56-75 > edid horz (Hz) 30000-90000 > edid pclkmax 240000000 > edid flags digital standby > edid 2560x1080@60Hz > clock=185.58 > shb=2624 ehb=2688 ht=2784 > vrs=1083 vre=1093 vt=1111 > hsync=- vsync=- > edid 1920x1080@60Hz > clock=148.5 > shb=2008 ehb=2052 ht=2200 > vrs=1084 vre=1089 vt=1125 > hsync=+ vsync=- > edid 640x480@60Hz > clock=25.175 > shb=656 ehb=752 ht=800 > vrs=490 vre=492 vt=525 > hsync=- vsync=- > edid 640x480@75Hz > clock=31.5 > shb=656 ehb=720 ht=840 > vrs=481 vre=484 vt=500 > hsync=- vsync=- > edid 800x600@60Hz > clock=40 > shb=840 ehb=968 ht=1056 > vrs=601 vre=605 vt=628 > hsync=+ vsync=+ > edid 800x600@75Hz > clock=49.5 > shb=816 ehb=896 ht=1056 > vrs=601 vre=604 vt=625 > hsync=+ vsync=+ > edid 1024x768@60Hz > clock=65 > shb=1048 ehb=1184 ht=1344 > vrs=771 vre=777 vt=806 > hsync=- vsync=- > edid 1024x768@75Hz > clock=78.75 > shb=1040 ehb=1136 ht=1312 > vrs=769 vre=772 vt=800 > hsync=+ vsync=+ > edid 1280x1024@75Hz > clock=135 > shb=1296 ehb=1440 ht=1688 > vrs=1025 vre=1028 vt=1066 > hsync=+ vsync=+ > cpu% whatis lcd > fn lcd { > @ { > rfork n; aux/realemu; aux/vga -m igfx -l 1366x768 > } > } > cpu% whatis lg > fn lg { > @ { > rfork n; aux/realemu; aux/vga -m igfx -l 1920x1080 > } > } > cpu% cat /dev/vgactl > type igfx > size 1376x768x32 x8r8g8b8 > actualsize 1366x768 > tilt none > hwgc igfxhwgc > hwaccel off > hwblank on > addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 > softscreen on > cpu% lg > cpu% cat /dev/vgactl > type igfx > size 1920x1080x32 x8r8g8b8 > tilt none > hwgc igfxhwgc > hwaccel off > hwblank on > addr p 0xe0000000 v 0xfffffe80e0000000 size 0x4000000 > softscreen on > cpu% lcd > cpu% > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-04 22:39 ` igor @ 2023-04-04 22:43 ` sl 2023-04-05 7:01 ` qwx 1 sibling, 0 replies; 18+ messages in thread From: sl @ 2023-04-04 22:43 UTC (permalink / raw) To: 9front tutu! sl ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-04 22:39 ` igor 2023-04-04 22:43 ` sl @ 2023-04-05 7:01 ` qwx 2023-04-09 6:59 ` unobe 1 sibling, 1 reply; 18+ messages in thread From: qwx @ 2023-04-05 7:01 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-05 7:01 ` qwx @ 2023-04-09 6:59 ` unobe 0 siblings, 0 replies; 18+ messages in thread From: unobe @ 2023-04-09 6:59 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 2698 bytes --] 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. [-- Attachment #2: igfx-dp.patch.txt --] [-- Type: text/plain, Size: 9988 bytes --] From: Romano <unobe@cpan.org> Date: Sun, 09 Apr 2023 06:31:09 +0000 Subject: [PATCH] [PATCH] DP 1.2 on igfx; EDID wrapping; VGA display connections This patch more fully implements the training patterns for DP 1.2 per the spec, which then allows more monitors to successfully train and therefore connect. In my case it was an LG 34UM68-P. Secondly, this fixes EDID shifting to work with a wider range of values, notably ones which wrap. Lastly, a small correction in vesa.c as to which bits are used to determine available connections. --- diff 60b1a2f82dc96b254d6dec1bfd1c14ca056c21dd f2bdc9318599dc0cf578f83765fb6024b6290fe5 --- a/sys/src/cmd/aux/vga/edid.c +++ b/sys/src/cmd/aux/vga/edid.c @@ -6,6 +6,8 @@ #include "pci.h" #include "vga.h" +static uchar magic[8] = { 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00 }; + static void addmode(Modelist **l, Mode m) { @@ -180,10 +182,40 @@ return vesalookup(m, str); } +uchar* +edidshift(uchar buf[256]) +{ + uchar tmp[263]; + int i = 256; + if(memcmp(buf, magic, 8) == 0) + return buf; + + // Some devices (e.g., igfx) access address space which has wrapped values, so shift if needed. + // Comparing and copying is easier by extending temp buffer slightly. + memcpy(tmp, buf, 256); + memcpy(tmp+256, buf, 7); + while(--i){ + if(memcmp(tmp+i, magic, 8) == 0){ + trace("magic begins at index %d, shifting\n", i); + memcpy(buf, tmp+i, 256-i); + memcpy(buf+(256-i), tmp, i); + i = 1; + } + } + + trace("edid:\n"); + for(i=0; i<256; i++){ + trace("\t%x", buf[i]); + if ( (i+1) % 16 == 0) + trace("\n"); + } + + return buf; +} + Edid* parseedid128(void *v) { - static uchar magic[8] = { 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00 }; uchar *p, *q, sum; int dpms, estab, i, m, vid; Mode mode; --- a/sys/src/cmd/aux/vga/igfx.c +++ b/sys/src/cmd/aux/vga/igfx.c @@ -501,22 +501,22 @@ igfx->dp[x].ctl = snarfreg(igfx, 0xE4000 + 0x100*x); igfx->hdmi[1].ctl = snarfreg(igfx, 0x0E1140); /* HDMI_CTL_B */ - igfx->hdmi[1].bufctl[0] = snarfreg(igfx, 0x0FC810); /* HTMI_BUF_CTL_0 */ - igfx->hdmi[1].bufctl[1] = snarfreg(igfx, 0x0FC81C); /* HTMI_BUF_CTL_1 */ - igfx->hdmi[1].bufctl[2] = snarfreg(igfx, 0x0FC828); /* HTMI_BUF_CTL_2 */ - igfx->hdmi[1].bufctl[3] = snarfreg(igfx, 0x0FC834); /* HTMI_BUF_CTL_3 */ + igfx->hdmi[1].bufctl[0] = snarfreg(igfx, 0x0FC810); /* HDMI_BUF_CTL_0 */ + igfx->hdmi[1].bufctl[1] = snarfreg(igfx, 0x0FC81C); /* HDMI_BUF_CTL_1 */ + igfx->hdmi[1].bufctl[2] = snarfreg(igfx, 0x0FC828); /* HDMI_BUF_CTL_2 */ + igfx->hdmi[1].bufctl[3] = snarfreg(igfx, 0x0FC834); /* HDMI_BUF_CTL_3 */ igfx->hdmi[2].ctl = snarfreg(igfx, 0x0E1150); /* HDMI_CTL_C */ - igfx->hdmi[2].bufctl[0] = snarfreg(igfx, 0x0FCC00); /* HTMI_BUF_CTL_4 */ - igfx->hdmi[2].bufctl[1] = snarfreg(igfx, 0x0FCC0C); /* HTMI_BUF_CTL_5 */ - igfx->hdmi[2].bufctl[2] = snarfreg(igfx, 0x0FCC18); /* HTMI_BUF_CTL_6 */ - igfx->hdmi[2].bufctl[3] = snarfreg(igfx, 0x0FCC24); /* HTMI_BUF_CTL_7 */ + igfx->hdmi[2].bufctl[0] = snarfreg(igfx, 0x0FCC00); /* HDMI_BUF_CTL_4 */ + igfx->hdmi[2].bufctl[1] = snarfreg(igfx, 0x0FCC0C); /* HDMI_BUF_CTL_5 */ + igfx->hdmi[2].bufctl[2] = snarfreg(igfx, 0x0FCC18); /* HDMI_BUF_CTL_6 */ + igfx->hdmi[2].bufctl[3] = snarfreg(igfx, 0x0FCC24); /* HDMI_BUF_CTL_7 */ igfx->hdmi[3].ctl = snarfreg(igfx, 0x0E1160); /* HDMI_CTL_D */ - igfx->hdmi[3].bufctl[0] = snarfreg(igfx, 0x0FD000); /* HTMI_BUF_CTL_8 */ - igfx->hdmi[3].bufctl[1] = snarfreg(igfx, 0x0FD00C); /* HTMI_BUF_CTL_9 */ - igfx->hdmi[3].bufctl[2] = snarfreg(igfx, 0x0FD018); /* HTMI_BUF_CTL_10 */ - igfx->hdmi[3].bufctl[3] = snarfreg(igfx, 0x0FD024); /* HTMI_BUF_CTL_11 */ + igfx->hdmi[3].bufctl[0] = snarfreg(igfx, 0x0FD000); /* HDMI_BUF_CTL_8 */ + igfx->hdmi[3].bufctl[1] = snarfreg(igfx, 0x0FD00C); /* HDMI_BUF_CTL_9 */ + igfx->hdmi[3].bufctl[2] = snarfreg(igfx, 0x0FD018); /* HDMI_BUF_CTL_10 */ + igfx->hdmi[3].bufctl[3] = snarfreg(igfx, 0x0FD024); /* HDMI_BUF_CTL_11 */ igfx->lvds = snarfreg(igfx, 0x0E1180); /* LVDS_CTL */ goto PCHcommon; @@ -2193,6 +2193,7 @@ return -1; return buf[0]; } + static int wdpaux(Igfx *igfx, Dp *dp, int addr, uchar val) { @@ -2202,9 +2203,86 @@ } static int +trainpatt(Igfx *igfx, Dp *dp, int w, int rd, int tr0, int mask1, int mask2) +{ + int ln[4], tr[4], la, retry, try, i, r; + + ln[0] = ln[1] = ln[2] = ln[3] = 0; + tr[0] = tr[1] = tr[2] = tr[3] = tr0; + for (try=0;;try++){ + if(try > 5) + goto FailPatt; + sleep(1<<rd); + for (i=0; i<=w;i++) + wdpaux(igfx, dp, 0x103 + i, tr[i]); + sleep(1<<rd); + if((r = rdpaux(igfx, dp, 0x202)) < 0) + goto FailPatt; + trace("lane 0,1 status is %x\n", r); + retry=0; + ln[1] = (r & (mask1<<4))>>4; + ln[0] = r & mask1; + if(r & 0x11){ + if(!((r = rdpaux(igfx, dp, 0x204)) & 1)){ + trace("lane 0,1 align status is %x\n", r); + if((r = rdpaux(igfx, dp, 0x206)) >= 0){ + trace("adjust tr[0,1] %x\n", r); + if(tr[0] != (r & mask2)<<1){ + tr[0] = (r & mask2)<<1; + retry++; + } + if(tr[1] != ((r & (mask2<<4))>>4)<<1){ + tr[1] = ((r & (mask2<<4))>>4)<<1; + retry++; + } + } + } + } + if(w>1){ + if((r = rdpaux(igfx, dp, 0x202)) < 0) + goto FailPatt; + trace("lane 2,3 status is %x\n", r); + ln[2] = r & mask1; + ln[3] = (r & (mask1<<4))>>4; + if(r & 0x11){ + if((r = rdpaux(igfx, dp, 0x204)) & 0x80){ + trace("lane 2,3 align status is %x\n", r); + if((r = rdpaux(igfx, dp, 0x207)) >= 0){ + trace("adjust tr[2,3] %x\n", r); + if(tr[2] != (r & mask2)<<1){ + tr[2] = (r & mask2)<<1; + retry++; + } + if(tr[3] != ((r & (mask2<<4))>>4)<<1){ + tr[3] = ((r & (mask2<<4))>>4)<<1; + retry++; + } + } + } + } + } + for (i=0; i<=w; i++) + if(ln[i] != mask1) + retry++; + if(!retry) + break; + } + trace("pattern finished after try %d: %x %x %x %x\n", try, ln[0], ln[1], ln[2], ln[3]); + return 0; + +FailPatt: + trace("training pattern failed on try %d: %x %x %x %x\n", try, ln[0], ln[1], ln[2], ln[3]); + /* disable port */ + dp->ctl.v &= ~(1<<31); + loadreg(igfx, dp->ctl); + wdpaux(igfx, dp, 0x102, 0x00); + return -1; +} + +static int enabledp(Igfx *igfx, Dp *dp) { - int try, r; + int r, rd, try; u32int w; if(dp->ctl.a == 0) @@ -2212,6 +2290,9 @@ if((dp->ctl.v & (1<<31)) == 0) return 0; + r = rdpaux(igfx, dp, 0x0); + trace("DPCD Rev. 1.%d%c\n", ((r & ~0xf)>>4 & 0xf), (r & 0xf) + 0x60); + /* Link configuration */ for(try=0; try<30; try++) if(wdpaux(igfx, dp, 0x100, (270*MHz) / 27000000) >= 0) @@ -2219,46 +2300,37 @@ if(try >= 30) trace("can\'t start training\n"); w = dp->bufctl.v >> (igfx->type == TypeHSW ? 1 : 19) & 7; + if(igfx->type == TypeIVB) + w = (dp->ctl.v >> 19) & 7; + trace("using %x lane(s)\n", w+1); wdpaux(igfx, dp, 0x101, w+1); - r = 0; + rd = rdpaux(igfx, dp, 0x0e); + trace("read interval is %x\n", rd); - /* Link training pattern 1 */ + /* Link training pattern 1, see DisplayPort 1.2 Spec, p. 356ff. */ + trace("link training pattern \n"); dp->ctl.v &= ~(7<<8); loadreg(igfx, dp->ctl); - for(try = 0;;try++){ - if(try > 5) - goto Fail; - /* Link training pattern 1 */ - wdpaux(igfx, dp, 0x102, 0x01); - sleep(100); - if((r = rdpaux(igfx, dp, 0x202)) < 0) - goto Fail; - if(r & 1) /* LANE0_CR_DONE */ - break; - } - trace("pattern1 finished: %x\n", r); + wdpaux(igfx, dp, 0x102, 0x10001); + wdpaux(igfx, dp, 0x102, 0x21); + if(trainpatt(igfx, dp, w, rd, 0x1, 0x1, 0x3)) + return -1; - /* Link training pattern 2 */ + /* Link training pattern 2, see DisplayPort 1.2 Spec, p. 358ff. */ + trace("link training pattern 2\n"); dp->ctl.v &= ~(7<<8); dp->ctl.v |= 1<<8; loadreg(igfx, dp->ctl); - for(try = 0;;try++){ - if(try > 5) - goto Fail; - /* Link training pattern 2 */ - wdpaux(igfx, dp, 0x102, 0x02); - sleep(100); - if((r = rdpaux(igfx, dp, 0x202)) < 0) - goto Fail; - if((r & 7) == 7) - break; - } - trace("pattern2 finished: %x\n", r); + wdpaux(igfx, dp, 0x102, 0x10002); + wdpaux(igfx, dp, 0x102, 0x22); + if(trainpatt(igfx, dp, w, rd, 0x8, 0x7, 0xc)) + return -1; if(igfx->type == TypeHSW){ /* set link training to idle pattern and wait for 5 idle * patterns */ + trace("idle pattern\n"); dp->ctl.v &= ~(7<<8); dp->ctl.v |= 2<<8; loadreg(igfx, dp->ctl); @@ -2272,36 +2344,8 @@ /* stop training */ wdpaux(igfx, dp, 0x102, 0x00); return 1; - -Fail: - trace("training failed: %x\n", r); - - /* disable port */ - dp->ctl.v &= ~(1<<31); - loadreg(igfx, dp->ctl); - wdpaux(igfx, dp, 0x102, 0x00); - return -1; } -static uchar* -edidshift(uchar buf[256]) -{ - uchar tmp[256]; - int i; - - /* shift if neccesary so edid block is at the start */ - for(i=0; i<256-8; i++){ - if(buf[i+0] == 0x00 && buf[i+1] == 0xFF && buf[i+2] == 0xFF && buf[i+3] == 0xFF - && buf[i+4] == 0xFF && buf[i+5] == 0xFF && buf[i+6] == 0xFF && buf[i+7] == 0x00){ - memmove(tmp, buf, i); - memmove(buf, buf + i, 256 - i); - memmove(buf + (256 - i), tmp, i); - break; - } - } - return buf; -} - static Edid* snarfdpedid(Igfx *igfx, Dp *dp, int addr) { @@ -2319,7 +2363,7 @@ if(dpauxtra(igfx, dp, CmdMot|CmdRead, addr, nil, 0) < 0) return nil; - for(i=0; i<sizeof(buf); i+=16){ + for(i=0; i<sizeof(buf); i+=16){ if(dpauxtra(igfx, dp, CmdMot|CmdRead, addr, buf+i, 16) == 16) continue; if(dpauxtra(igfx, dp, CmdMot|CmdRead, addr, buf+i, 16) == 16) --- a/sys/src/cmd/aux/vga/vesa.c +++ b/sys/src/cmd/aux/vga/vesa.c @@ -638,7 +638,7 @@ u.bx = 0x200; if(vbecall(vbe, &u) < 0) u.cx = 0; - dspcon = u.cx >> 8; /* CH = connected, CL = available? */ + dspcon = (u.cx >> 8) & 0xf; /* detect active display devices */ vbesetup(vbe, &u, 0x5F64); --- a/sys/src/cmd/aux/vga/vga.h +++ b/sys/src/cmd/aux/vga/vga.h @@ -294,6 +294,7 @@ }; extern Flag edidflags[]; extern void printflags(Flag *f, int b); +extern uchar* edidshift(uchar*); extern Edid* parseedid128(void *v); extern void printedid(Edid *e); ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen
@ 2023-04-09 21:26 qwx
2023-04-09 22:42 ` sirjofri
2023-04-11 21:32 ` Roberto E. Vargas Caballero
0 siblings, 2 replies; 18+ messages in thread
From: qwx @ 2023-04-09 21:26 UTC (permalink / raw)
To: 9front
> From: Romano <unobe@cpan.org>
> Date: Sun, 09 Apr 2023 06:31:09 +0000
> Subject: [PATCH] [PATCH] DP 1.2 on igfx; EDID wrapping; VGA display connections
>
>
> This patch more fully implements the training patterns for DP 1.2 per the spec,
> which then allows more monitors to successfully train and therefore connect. In
> my case it was an LG 34UM68-P.
>
> Secondly, this fixes EDID shifting to work with a wider range of values, notably
> ones which wrap.
>
> Lastly, a small correction in vesa.c as to which bits are used to determine
> available connections.
Wow, great work! I only skimmed through your patch, and I do have
some comments, but this is awesome. I don't have access to any
displayport monitors here to try that stuff myself, but I'll look over
your patch as soon as I can, though perhaps others already have/will.
I'll try to scavenge some equipment at work.
Prost,
qwx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-09 21:26 qwx @ 2023-04-09 22:42 ` sirjofri 2023-04-11 21:33 ` Steve Simon 2023-04-12 22:13 ` unobe 2023-04-11 21:32 ` Roberto E. Vargas Caballero 1 sibling, 2 replies; 18+ messages in thread From: sirjofri @ 2023-04-09 22:42 UTC (permalink / raw) To: 9front Hey, I remember having some eDP issues on my toughbook (some older VW car engine test device, CF-52 I think), it was impossible to get any graphics working on that device. Is it possible that the patch can also help in that situation? Maybe it's time for me to try again... sirjofri ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-09 22:42 ` sirjofri @ 2023-04-11 21:33 ` Steve Simon 2023-04-12 22:13 ` unobe 1 sibling, 0 replies; 18+ messages in thread From: Steve Simon @ 2023-04-11 21:33 UTC (permalink / raw) To: 9front i don’t know if it is relevant - i have done nothing with DP but spent longer than i would like in the world of CEC and HDMI. i have a cec packet dissector if its of use. -Steve > On 9 Apr 2023, at 11:43 pm, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote: > > Hey, > > I remember having some eDP issues on my toughbook (some older VW car engine test device, CF-52 I think), it was impossible to get any graphics working on that device. Is it possible that the patch can also help in that situation? Maybe it's time for me to try again... > > sirjofri ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-09 22:42 ` sirjofri 2023-04-11 21:33 ` Steve Simon @ 2023-04-12 22:13 ` unobe 1 sibling, 0 replies; 18+ messages in thread From: unobe @ 2023-04-12 22:13 UTC (permalink / raw) To: 9front Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>: > I remember having some eDP issues on my toughbook (some older VW car engine test device, CF-52 I think), it was impossible to get any graphics working on that device. Is it possible that the patch can also help in that situation? Maybe it's time for me to try again... It's possible. From the spec there are some extensions for eDP (that is, "features beyond those provided by DP1.1.a...optional features"), but not required. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-09 21:26 qwx 2023-04-09 22:42 ` sirjofri @ 2023-04-11 21:32 ` Roberto E. Vargas Caballero 2023-04-17 7:53 ` qwx 1 sibling, 1 reply; 18+ messages in thread From: Roberto E. Vargas Caballero @ 2023-04-11 21:32 UTC (permalink / raw) To: 9front Hi, > Wow, great work! I only skimmed through your patch, and I do have > some comments, but this is awesome. I don't have access to any > displayport monitors here to try that stuff myself, but I'll look over > your patch as soon as I can, though perhaps others already have/will. > I'll try to scavenge some equipment at work. I have one DP monitor here (qwx do you remember that we used it for our tests in the last hackathon ;) ?. I can try it but not in this week. Regards, ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-11 21:32 ` Roberto E. Vargas Caballero @ 2023-04-17 7:53 ` qwx 2023-04-19 20:50 ` unobe 0 siblings, 1 reply; 18+ messages in thread From: qwx @ 2023-04-17 7:53 UTC (permalink / raw) To: 9front On Sun Apr 9 08:58:34 +0200 2023, unobe@cpan.org wrote: > 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. Alright, sorry for taking so long. I'm going to test the patch on a w500 and a w520 (resp. gm965 and sandybridge, iirc) as soon as I'm able. I don't actually have any remarks on what you did itself, looks good; I only have one comment on style: please be consistent with the rest of the code, mostly add spacing around operators (for example the shifts), and remove useless parenthesis (less important). The only other thing: > + while(--i){ > + if(memcmp(tmp+i, magic, 8) == 0){ > + trace("magic begins at index %d, shifting\n", i); > + memcpy(buf, tmp+i, 256-i); > + memcpy(buf+(256-i), tmp, i); > + i = 1; > + } > + } Why not just a `break;' there? Anyway, not important. > 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 > } > } You don't need to run aux/realemu unless you will use vesa, which you don't. Also, in practice, do you still have to run aux/vga twice, or is that just for testing? Do you need this function at all now, that is, does it not work by just having `monitor=auto' in plan9.ini? @k0ga: On Tue Apr 11 23:30:37 +0200 2023, k0ga@shike2.com wrote: > I have one DP monitor here (qwx do you remember that we used it for our tests > in the last hackathon ;) ?. I can try it but not in this week. Yes, please do :) In fact, I bid anyone who has igfx to please check for a regression :) Unfortunately, I don't have access for a few weeks to other machines. For reference, anything up to and including broadwell (x250 generation) that has its pci device id in /lib/vgadb and in /sys/src/cmd/aux/vga/igfx.c should still work with the integrated screen, and now possibly with an external screen through DP (not hdmi). Thanks again! Cheers, qwx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-17 7:53 ` qwx @ 2023-04-19 20:50 ` unobe 2023-04-20 23:40 ` qwx 2023-04-24 18:52 ` qwx 0 siblings, 2 replies; 18+ messages in thread From: unobe @ 2023-04-19 20:50 UTC (permalink / raw) To: 9front Quoth qwx@sciops.net: > On Sun Apr 9 08:58:34 +0200 2023, unobe@cpan.org wrote: > > 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. > > Alright, sorry for taking so long. I'm going to test the patch on a > w500 and a w520 (resp. gm965 and sandybridge, iirc) as soon as I'm > able. Not at all! I appreciate the feedback. > I don't actually have any remarks on what you did itself, looks > good; I only have one comment on style: please be consistent with the > rest of the code, mostly add spacing around operators (for example the > shifts), and remove useless parenthesis (less important). I attempted to, but apparently failed. Admittedly, it was a manual check on my part. C programming is not yet native to me, and I'm still trying to learn the formatting style. Is style(6) still the standard? Or is there a C beautifier that can be used so that this (valid) sort of criticism is then a simple matter of just having the contributor run a script over the code? That is, if I run cb(1) using the '-s' flag, will that suffice? Gofmt was a smart move. Perl::Tidy (which I used in my day job) helps with this sort of thing as well, and allows a comment to "turn off" beautifying for a section of code. That sort of thing is helpful when the formatting itself is non-standard yet provides clarity to the code. I didn't see the same ability with cb(1), other than it not reformatting structure initializers. > The only other thing: > > > + while(--i){ > > + if(memcmp(tmp+i, magic, 8) == 0){ > > + trace("magic begins at index %d, shifting\n", i); > > + memcpy(buf, tmp+i, 256-i); > > + memcpy(buf+(256-i), tmp, i); > > + i = 1; > > + } > > + } > > Why not just a `break;' there? Anyway, not important. I vacillated on this exact thing, and apparently chose the road less traveled by, and that has made all the difference. > > 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 > > } > > } > > You don't need to run aux/realemu unless you will use vesa, which you > don't. Thanks; I'll need to explore when I need to use this in my day-to-day usage, because I recall having to load it for something like looking for valid modes. This reminds me of another confusing point--realemu(8) refers to /dev/realmode, yet arch(3) refers to /dev/realmodemem, the latter of which is actually provided. I have assumed the docs for realemu(8) are wrong and need to be updated. Also, in practice, do you still have to run aux/vga twice, or > is that just for testing? I use it for testing because otherwise I won't have a screen. The mouse control for the window loses focus, so I can't just keep typing 'lcd' to restore, thus the 'sleep 5;'. Perhaps it's more of a problem with aux/vga not failing and reverting to the Last Known Good like it should, but the 'sleep' method works for me now. > Do you need this function at all now, that > is, does it not work by just having `monitor=auto' in plan9.ini? I have not tried that. It's an external monitor and not always connected. I don't see 'monitor=auto' described in plan9.ini(8). I'd have to look at the implementation to see exactly what it does, and if it's "smart" enough to switch to the built-in LCD screen when the external isn't connected. Sincerely, Romano ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-19 20:50 ` unobe @ 2023-04-20 23:40 ` qwx 2023-04-24 18:52 ` qwx 1 sibling, 0 replies; 18+ messages in thread From: qwx @ 2023-04-20 23:40 UTC (permalink / raw) To: 9front On Wed Apr 19 22:51:39 +0200 2023, unobe@cpan.org wrote: > > I don't actually have any remarks on what you did itself, looks > > good; I only have one comment on style: please be consistent with the > > rest of the code, mostly add spacing around operators (for example the > > shifts), and remove useless parenthesis (less important). > > I attempted to, but apparently failed. Admittedly, it was a manual > check on my part. C programming is not yet native to me, and I'm > still trying to learn the formatting style. Is style(6) still the > standard? Or is there a C beautifier that can be used so that this > (valid) sort of criticism is then a simple matter of just having the > contributor run a script over the code? That is, if I run cb(1) using > the '-s' flag, will that suffice? Gofmt was a smart move. Perl::Tidy > (which I used in my day job) helps with this sort of thing as well, > and allows a comment to "turn off" beautifying for a section of code. > That sort of thing is helpful when the formatting itself is > non-standard yet provides clarity to the code. I didn't see the same > ability with cb(1), other than it not reformatting structure > initializers. cb(1) doesn't really work well, you can't rely on it because of a number of shortcomings. style(6) is more or less standard, but there's wiggle room. I'd also point to [1] and [2]. I suspect that not everyone would even agree with the suggestions I made, but eitherway imo the most important part is just consistency, use the same style as the rest of the code you're editing. > > You don't need to run aux/realemu unless you will use vesa, which you > > don't. > > Thanks; I'll need to explore when I need to use this in my day-to-day > usage, because I recall having to load it for something like looking > for valid modes. This reminds me of another confusing > point--realemu(8) refers to /dev/realmode, yet arch(3) refers to > /dev/realmodemem, the latter of which is actually provided. I have > assumed the docs for realemu(8) are wrong and need to be updated. Huh, you're probably right, thanks. Strictly speaking, I don't think we do anything to prevent igfx to configure any mode, regardless of whether the monitor can handle it or not; I've done some stupid shit at times with that. You'd need to run realemu to check which modes are available for vesa, but if igfx works, it's irrelevant. > Also, in practice, do you still have to run aux/vga twice, or > > is that just for testing? > > I use it for testing because otherwise I won't have a screen. The > mouse control for the window loses focus, so I can't just keep typing > 'lcd' to restore, thus the 'sleep 5;'. Perhaps it's more of a problem > with aux/vga not failing and reverting to the Last Known Good like it > should, but the 'sleep' method works for me now. That's fine for testing, I was just wondering. Right now, I don't think there's a way to know if configuration was actually successful, or if there was a last known good one, and also if the driver is buggy, there's a good chance the other screen will never be reconfigured correctly until you reboot. > > Do you need this function at all now, that > > is, does it not work by just having `monitor=auto' in plan9.ini? > > I have not tried that. It's an external monitor and not always > connected. I don't see 'monitor=auto' described in plan9.ini(8). I'd > have to look at the implementation to see exactly what it does, and if > it's "smart" enough to switch to the built-in LCD screen when the > external isn't connected. monitor=auto is specific to igfx, but basically as long as it manages to snarf the edid of the connected displays and match one mode against the $vgasize you set, it will configure that automatically, regardless of which port it uses, at boot if in plan9.ini, or later on the command line. So, if there aren't any other bugs, you should be able to switch between monitors with it just fine at any time. Cheers, qwx [1] http://doc.cat-v.org/bell_labs/pikestyle [2] http://aiju.de/misc/c-style ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-19 20:50 ` unobe 2023-04-20 23:40 ` qwx @ 2023-04-24 18:52 ` qwx 2023-04-26 3:32 ` unobe 1 sibling, 1 reply; 18+ messages in thread From: qwx @ 2023-04-24 18:52 UTC (permalink / raw) To: 9front On Wed Apr 19 22:51:39 +0200 2023, unobe@cpan.org wrote: > I attempted to, but apparently failed. Admittedly, it was a manual > check on my part. C programming is not yet native to me, and I'm > still trying to learn the formatting style. Is style(6) still the > standard? Or is there a C beautifier that can be used so that this > (valid) sort of criticism is then a simple matter of just having the > contributor run a script over the code? That is, if I run cb(1) using > the '-s' flag, will that suffice? Gofmt was a smart move. Perl::Tidy > (which I used in my day job) helps with this sort of thing as well, > and allows a comment to "turn off" beautifying for a section of code. > That sort of thing is helpful when the formatting itself is > non-standard yet provides clarity to the code. I didn't see the same > ability with cb(1), other than it not reformatting structure > initializers. > > > The only other thing: > > > > > + while(--i){ > > > + if(memcmp(tmp+i, magic, 8) == 0){ > > > + trace("magic begins at index %d, shifting\n", i); > > > + memcpy(buf, tmp+i, 256-i); > > > + memcpy(buf+(256-i), tmp, i); > > > + i = 1; > > > + } > > > + } > > > > Why not just a `break;' there? Anyway, not important. > > I vacillated on this exact thing, and apparently chose the road less > traveled by, and that has made all the difference. Alright, since there are no reports for breakage, I suggest that we -- you or me, as you prefer -- make a few minor edits as mentioned, make a new diff and just push it. Apologies for the delays! Thanks again, qwx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-24 18:52 ` qwx @ 2023-04-26 3:32 ` unobe 2023-04-30 3:12 ` qwx 0 siblings, 1 reply; 18+ messages in thread From: unobe @ 2023-04-26 3:32 UTC (permalink / raw) To: 9front Quoth qwx@sciops.net: > Alright, since there are no reports for breakage, I suggest that we -- > you or me, as you prefer -- make a few minor edits as mentioned, make > a new diff and just push it. Apologies for the delays! No apology needed: you're the one helping me! Of the issues you brought up, I was certain about how to fix the 'i = 1;' -> 'break;', but less certain of how to match the surrounding code in all cases. The for loops spacing was easy enough, and the added space at the end of a for loop that was unneeded (i.e., hunk @@ -2319,7, +2363,7 @@). However, the shift operators I saw have both styles even within the same block. In some cases there were surrounding spaces, and in others there weren't (e.g., hunk @@-2219,46 +2300,37 @@). I don't want to delay the push of the patch needlessly, but also don't want to create disturbances in the Force by not catching the ones you noticed. So I'd prefer you to fixup as you see fit. Sincerely, Romano P.S. Thanks for also pushing the /lib/dict change! ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9front] displayport thinkpad x230 external monitor black screen 2023-04-26 3:32 ` unobe @ 2023-04-30 3:12 ` qwx 0 siblings, 0 replies; 18+ messages in thread From: qwx @ 2023-04-30 3:12 UTC (permalink / raw) To: 9front On Wed Apr 26 05:39:14 +0200 2023, unobe@cpan.org wrote: > Of the issues you brought up, I was certain about how to fix the 'i = > 1;' -> 'break;', but less certain of how to match the surrounding code > in all cases. The for loops spacing was easy enough, and the added > space at the end of a for loop that was unneeded (i.e., hunk @@ > -2319,7, +2363,7 @@). > > However, the shift operators I saw have both styles even within the > same block. In some cases there were surrounding spaces, and in > others there weren't (e.g., hunk @@-2219,46 +2300,37 @@). I don't > want to delay the push of the patch needlessly, but also don't want to > create disturbances in the Force by not catching the ones you noticed. > So I'd prefer you to fixup as you see fit. > > Sincerely, > Romano I did a bunch of bikeshedding, more than enough, and just commited this. It wouldn't have been terrible to push it as it was when you sent it originally, like I said I only had minor comments on style -- so, bikeshedding. You'll find plenty of examples of differences in style in the tree, the point is to just not help form any mutinies of deviated preverts who use a significantly different style clashing with everything else (but not even the case here). Anyway, thanks again for your work! Cheers, qwx ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2023-04-30 3:14 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-30 17:37 [9front] displayport thinkpad x230 external monitor black screen Romano 2023-03-30 17:47 ` Stanley Lieber 2023-04-03 22:27 ` qwx 2023-04-04 22:39 ` igor 2023-04-04 22:43 ` sl 2023-04-05 7:01 ` qwx 2023-04-09 6:59 ` unobe 2023-04-09 21:26 qwx 2023-04-09 22:42 ` sirjofri 2023-04-11 21:33 ` Steve Simon 2023-04-12 22:13 ` unobe 2023-04-11 21:32 ` Roberto E. Vargas Caballero 2023-04-17 7:53 ` qwx 2023-04-19 20:50 ` unobe 2023-04-20 23:40 ` qwx 2023-04-24 18:52 ` qwx 2023-04-26 3:32 ` unobe 2023-04-30 3:12 ` qwx
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).