From nobody Tue Jan 4 15:53:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 140AD193EDDC for ; Tue, 4 Jan 2022 15:53:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSxwy3P30z4Qmf; Tue, 4 Jan 2022 15:53:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 204FrSZM099991; Wed, 5 Jan 2022 00:53:28 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 5 Jan 2022 00:53:28 +0900 From: Tomoaki AOKI To: FreeBSD Hackers Cc: Stefan Blachmann , Emmanuel Vadot , Warner Losh , Joseph Mingrone , =?ISO-2022-JP?B?GyRCIi4bKEJ6a2Fu?= KIRIK , Michael Schuster , Kyle Evans , Karel Gardas Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20220105005328.e75c6948ec6d14adf29dee33@dec.sakura.ne.jp> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> <20220104143234.d9af3a4aa841c80219cdcf75@bidouilliste.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSxwy3P30z4Qmf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 4 Jan 2022 15:20:08 +0100 Stefan Blachmann wrote: > On 1/4/22, Emmanuel Vadot wrote: > > You can't get or set the mode after ExitBootService in UEFI, you only > > have the framebuffer setup by the firmware. > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS´ CSM part. Just call the CSM BIOS init to set up GPU and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > > > > UGA have nothing to do with having CSM. > > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > > think that the firmware will setup the handler in non-CSM mode. > > After the UEFI boot service is no longer needed, one can check the VGA > BIOS UEFI signature for presence of a dual BIOS with normal VGA BIOS > (which is being used in CSM mode) in addition to UEFI BIOS. > Afaik, there are few if any UEFI compatible graphics cards without > dual BIOS, as those would not work in computers without UEFI. > If VGA BIOS presence is detected on the graphics card, calling the VGA > BIOS init sets up the int 10h handler. > After doing this, the UEFI crap limitations are gone. Possibly notebooks without discrete GPU (forced to use internal GPU on CPU) don't have CSM. IIRC, I heard M$ Surface doesn't have CSM (UEFI only). Just a thought, but adding something like hw.kms.in_use, initially 0 and incremented when a KMS driver is sanely attached, can help? It should be needed to be decremented when a KMS driver is detached. And something like hw.kms.intel.0.mode having needed data to manage suspend/resume would also be needed (set by KMS drivers). # Not sure if multiple KMS drivers can coexist or not, though. > On 1/4/22, Emmanuel Vadot wrote: > > On Tue, 4 Jan 2022 08:14:23 +0100 > > Stefan Blachmann wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> > last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > > > > ? > > You can't get or set the mode after ExitBootService in UEFI, you only > > have the framebuffer setup by the firmware. > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS´ CSM part. Just call the CSM BIOS init to set up GPU and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > > > > UGA have nothing to do with having CSM. > > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > > think that the firmware will setup the handler in non-CSM mode. > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it also > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> > last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, 〓zkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > > > -- > > Emmanuel Vadot > > > > -- Tomoaki AOKI