9front - general discussion about 9front
 help / color / mirror / Atom feed
* 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 [9front] displayport thinkpad x230 external monitor black screen 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 21:26 [9front] displayport thinkpad x230 external monitor black screen 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-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-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

* 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-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-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-03-30 17:37 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-03-30 17:37 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 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

* [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

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-04-09 21:26 [9front] displayport thinkpad x230 external monitor black screen 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
  -- strict thread matches above, loose matches on Subject: below --
2023-03-30 17:37 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

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).