Date: Tue, 4 Jan 2022 08:14:23 +0100 From: Stefan Blachmann <sblachmann@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Joseph Mingrone <jrm@freebsd.org>, =?UTF-8?B?w5Z6a2FuIEtJUklL?= <ozkan.kirik@gmail.com>, Michael Schuster <michaelsprivate@gmail.com>, Kyle Evans <kevans@freebsd.org>, Karel Gardas <gardask@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <CACc-My1WHdgxidCiYDW2RrWxM4sKao7o_Tw-pZuuE_Y0WXC4JQ@mail.gmail.com> In-Reply-To: <CANCZdfq7s2ODPbrZRztXQ7q1aMeDtK-bsoEoW%2BZKDkiyktKUSQ@mail.gmail.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <CADqw_gKkii%2BBHk7_jPE0DV5ZdF86ydEq956WDtZOP1N9GBjAPw@mail.gmail.com> <CACNAnaH4GH_n8GVYN44op-VO7VZ5_GLP8SBj0SfoC5KoBSFDQw@mail.gmail.com> <CADqw_gJuU6_Wt-GEJduz_Tm0oQg4dDv-5XDz1bsgWqtCmp1R2w@mail.gmail.com> <CAAcX-AHCom%2B5Zf2ENf%2BcFxPDrCWY=e_EaXfRamd%2BwnynBn1-VQ@mail.gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> <CACc-My26b1GZ7_s93Jx-DgeA=8%2BdS_2MYSoCv_D6uzRihyNHNQ@mail.gmail.com> <CANCZdfq7s2ODPbrZRztXQ7q1aMeDtK-bsoEoW%2BZKDkiyktKUSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/4/22, Warner Losh <imp@bsdimp.com> wrote: > Not without loading the xorg graphics stuff... graphics chips from the la= st > 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). With non-UEFI or old UGA UEFI implementations possibly one could use the dual BIOS=C2=B4 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. 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 <imp@bsdimp.com> wrote: > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com> > 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 la= st > 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 <jrm@freebsd.org> wrote: >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.org> wrote: >> > >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK <ozkan.kirik@gmail.com> >> >> 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 >> > >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACc-My1WHdgxidCiYDW2RrWxM4sKao7o_Tw-pZuuE_Y0WXC4JQ>