Re: [9front] displayport thinkpad x230 external monitor black screen

[qwx@sciops.net]

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