Syslinux - Mar 2021 - Equivalent to GRUB_GFXPAYLOAD_LINUX=keep with vesamenu?

On Tuesday, March 16, 2021 11:59:26 PM EDT Gregory Bartholomew
wrote:
> On Tue, Mar 16, 2021 at 9:07 PM nerdopolis <bluescreen_avenger at
verizon.net>
> wrote:
> 
> > ...
> > I could do a VGA= option, but with GRUB_GFXPAYLOAD_LINUX=keep you
don't
> > have to
> > pass a VGA= option for a framebuffer to be initialized. It's not a
kernel
> > parameter, but a bootloader wide option, to not switch back to text
mode
> > while
> > booting the kernel
> >
> > Since I am doing this on an ISO, I want to make as little assumptions
> > about the
> >
> > hardware as possible, so I am trying to see if there is a way I can
ensure
> > a
> > framebuffer on all cards, including the 'vmware' card that
QEMU has.
> > With GRUB, it initializes a framebuffer with the
> > GRUB_GFXPAYLOAD_LINUX=keep
> > option. Otherwise, including with ISOLINUX, it does not initialize a
> > framebuffer, and I read that it's the bootloader that initializes
the
> > framebuffer for the kernel usually.
> >
> >
> >
> > Is there an option to make syslinux/isolinux not return to text mode
when
> > booting a kernel? Or is this not possible?
> >
> > Thanks
> >
> >
> >
Hi
I am just realizing I mistakenly replied to you directly instead of the mailing
list. I am sorry about that. 
> According to
>
https://lists.syslinux.org/archives/syslinux-commits/2010-January/000027.html,
> syslinux should leave the video mode alone by default.
> 
> I'm not an expert on this, but I think all GRUB_GFXPAYLOAD_LINUX=keep
does
> is write "0x0f04" to the two bytes at offset 01FA (see here:
> https://www.kernel.org/doc/Documentation/x86/boot.txt). It is just a
> round-about way of setting vga=current without actually specifying it on
> the kernel command line. If your video mode is changing, I think it is the
> kernel that is changing it, not syslinux. You'll need to tell the
kernel,
> somehow, not to change the video mode. If you have something like Plymouth
> installed in the initramfs, that could also be the culprit. Maybe make sure
> "splash" and/or "rhgb" aren't specified on the
command line.
> 
OK, I am realizing that in syslinux there IS a special case for 
vga=current /
vgahttps://repo.or.cz/syslinux.git/blob/346d2278e23f1b9f02903506753263ad7226de58:/com32/lib/syslinux/load_linux.c#l497

Trying that option I do see much different behavior. It doesn't flush the
display, as if though going into text mode (which is a good start), but it
appears The kernel never creates the /dev/fb0 device like it does with grub
starting it.

I didn't know about that 0x0f04 option before as well, so that's cool.


If I have to continue to hardcode resolution options, that is fine. I had that
in these ISOs for quite a bit. 

The reason why I wanted to try to better guarantee a frame-buffer, is that if
modesetting doesn't work on these ISOs, it falls back to Weston's
framebuffer
backend, as Weston, not X11 is the default greeter.

And I am reading of a Linux mode setting driver that is in the works that might
rely on the Framebuffer space to act as a limited /dev/dri/card0
device
> I think there are also differences between BIOS and UEFI with regard to how
> framebuffers are handled. See for example
> https://cateee.net/lkddb/web-lkddb/FB_EFI.html and
> https://forums.gentoo.org/viewtopic-t-1066642-start-0.html.
> 
> Your best bet for a "one size fits all" solution is probably to
set a very
> standard/compatible resolution in syslinux (e.g. "menu resolution 800
600")
> and then set vga=current and nomodeset on the kernel command line. I think
> a lot of ISOs are distributed with multiple boot menu options that offer
> "fallback" video modes precisely because a "universal"
video mode across
> all hardware doesn't really exist (even less so right now because of
the
> BIOS to UEFI transition).
> 
Thanks

On Wed, Mar 17, 2021 at 10:35 PM nerdopolis via Syslinux <
syslinux at syslinux.org> wrote:
> ...
> OK, I am realizing that in syslinux there IS a special case for
> vga=current / vga>
>
https://repo.or.cz/syslinux.git/blob/346d2278e23f1b9f02903506753263ad7226de58:/com32/lib/syslinux/load_linux.c#l497
>
> Trying that option I do see much different behavior. It doesn't flush
the
> display, as if though going into text mode (which is a good start), but it
> appears The kernel never creates the /dev/fb0 device like it does with grub
> starting it.
> ...
>
From
https://github.com/torvalds/linux/blob/master/Documentation/fb/vesafb.rst:

" ... You should compile in both vgacon (for text mode) and vesafb (for
graphics mode). Which of them takes over the console depends on whenever
the specified mode is text or graphics. ..."

I wonder if the kernel is falling back to text mode because it doesn't
recognize "vga=current" as a graphics mode? Maybe you can force it
with
"video=vesafb:on" (or maybe "video=efifb:on" if you are
using syslinux.efi).