From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 26017 invoked from network); 20 Apr 2023 23:48:20 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2023 23:48:20 -0000 Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Thu Apr 20 19:46:59 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706; t=1682033906; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=oaFt5v+YSH/eN/hR8WF4y4PX/AMkv+IFFLZTjeXEvdk=; b=4hetPez5mvHM8HkwXBLMy+4GVWJ9VQKF4Hi6UJeMwlxcjVPbc7qoqwKJsquSqB1dLmRaOv TgI2bZM/d3FcnSpd299KmQ4No8zAnDZIDDuUgc/NRpqKFsLKW9veNM+gPQc3IbwXgbGFbN 0hJ0tWJ5vB7m2x4GsZ2djPS7FJ1Hewo= Received: by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 75c1e302 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO) for <9front@9front.org>; Thu, 20 Apr 2023 16:38:24 -0700 (PDT) Message-ID: Date: Fri, 21 Apr 2023 01:40:14 +0200 From: qwx@sciops.net To: 9front@9front.org In-Reply-To: <5CDF6C358171BFB3DCDAEE0C0B1F080F@smtp.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: SSL grid plugin Subject: Re: [9front] displayport thinkpad x230 external monitor black screen Reply-To: 9front@9front.org Precedence: bulk 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