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.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2652 invoked from network); 19 Apr 2023 20:54:48 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 19 Apr 2023 20:54:48 -0000 Received: from pb-smtp20.pobox.com ([173.228.157.52]) by 9front; Wed Apr 19 16:51:05 -0400 2023 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id C042D1E432F for <9front@9front.org>; Wed, 19 Apr 2023 16:50:58 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; s=sasl; bh=z6nqpwniPfYTf9AXu7/ZYUfkc qPRHmyfmYUsmfHTpCE=; b=okhDhsVAKeu2zOt/3VVWZwbNlZLKnfvlDh6+P7HrA ydQnAJAIn3omvTf6MQo2y1WhOoJ5wYHLmZ0ECfC0UOV/2DluPTAgk31xlSXrMa1x JOTy/3ir4+mPXj4ozhtN8wa7O63RUsGdeQ7GjJjI6CAnRrfk2za+0ja6VURJCAC1 tM= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id B8B091E432E for <9front@9front.org>; Wed, 19 Apr 2023 16:50:58 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from strider.localdomain (unknown [75.204.169.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 981001E432D for <9front@9front.org>; Wed, 19 Apr 2023 16:50:55 -0400 (EDT) (envelope-from unobe@cpan.org) Message-ID: <5CDF6C358171BFB3DCDAEE0C0B1F080F@smtp.pobox.com> To: 9front@9front.org Date: Wed, 19 Apr 2023 13:50:53 -0700 From: unobe@cpan.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E15111A4-DEF3-11ED-887F-C2DA088D43B2-09620299!pb-smtp20.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extension-oriented GPU SOAP over ORM shader core optimizer Subject: Re: [9front] displayport thinkpad x230 external monitor black screen Reply-To: 9front@9front.org Precedence: bulk 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