Re: Call for Foundation-supported Project Ideas

On Tue, 4 Jan 2022 15:20:08 +0100
Stefan Blachmann <sblachmann@gmail.com> wrote:

> On 1/4/22, Emmanuel Vadot <manu@bidouilliste.com> 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$B!-(B 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 <manu@bidouilliste.com> wrote:
> > On Tue, 4 Jan 2022 08:14:23 +0100
> > Stefan Blachmann <sblachmann@gmail.com> wrote:
> >
> >> On 1/4/22, Warner Losh <imp@bsdimp.com> 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$B!-(B 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 <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
> >> > 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 <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, $B".(Bzkan 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
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >
> >
> > --
> > Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>
> >
> 
> 


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>