#14548 closed bug (invalid)

EFI BootLoader color icons not printed over desaturated icons

Reported by: v.vill Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/beta1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

Description

Greetings,

just a minor cosmetic issue, but could be worth investigating since we’re entering beta phase…

Using the latest EFI bootloader, here’s what I see when booting:

… instead of:

As you can see, the two differences are:

  • the Haiku logo isn’t printed
  • the colorful icons are printed _below_ the desaturated icons, instead of overwriting them.

(as of hrev52365, and earlier versions AFAICR.)

Attachments (2)

1afa94f3721ce584.png (76.8 KB ) - added by v.vill 15 months ago.
hka1splash.png (34.5 KB ) - added by v.vill 15 months ago.

Download all attachments as: .zip

Change History (11)

by v.vill, 15 months ago

Attachment: 1afa94f3721ce584.png added

by v.vill, 15 months ago

Attachment: hka1splash.png added

comment:1 by tqh, 15 months ago

What graphics card do you have? It seems strange as the code for drawing the icons are the same for different bootloaders Not sure what could cause this.

comment:2 by diver, 15 months ago

It looks like you have 2 haiku_loader packages. Can you check /system/packages folder?

comment:3 by v.vill, 15 months ago

@tqh: It's a 2015 laptop with an nvidia GeForce mobile card and an Intel integrated card. (Both of which are referred to as "Driver not implemented" by Haiku.) I suspect the nvidia card is pretty much ignored by the OS.

@diver:

~> cd /system; find -name "*haiku_loader*"
./package-links/haiku_loader-r1~beta1_hrev52369-1
./packages/haiku_loader-r1~beta1_hrev52369-1-x86_64.hpkg
./haiku_loader

I did, however, have to manually copy the BOOTX64.efi file onto my hd's EFI boot partition. (I tried with both the default one provided with recent releases, and one I built myself from master. The boot screen looked the same.)

comment:4 by waddlesplash, 15 months ago

The boot screen looked the same.)

The one you built yourself will not have OFFICIAL_BRANDING enabled and thus it won't have the logo. The haiku_loader package will of course have OFFICIAL_BRANDING enabled, and so it will assume the stage0 loader already wrote the logo to the framebuffer. So if you are using your master-built loader, that is the difference.

comment:5 by v.vill, 15 months ago

Oh, interesting. Is it documented somewhere? git grep OFFICIAL_BRANDING doesn't return anything.

comment:6 by vidrep, 14 months ago

I noted the same issue as far back as hrev50701 when testing GPT installs on large 2.2TB+ size hdd . I mentioned the double row of boot icons several times on IRC (looking at my notes from then).

comment:7 by waddlesplash, 14 months ago

Ah, right, sorry, it's HAIKU_DISTRO_COMPATIBILITY_OFFICIAL. By default, configure sets this to ... "default", not "official", which strips all the trademarked Haiku logos from generated binaries. So anything custom-built will not have the logos, and this of course includes the bootloader.

comment:8 by v.vill, 14 months ago

Oh, OK. So, using the "official" EFI loader @kallisti5 just uploaded on the website, I can verify that the graphical boot sequence is indeed displayed correctly. (And I suspect with the appropriate UserBuildConfig, I'll be able to make it work with my own binaries as well.)

As far as I'm concerned, this is indeed not a valid issue (at least not until we actually ship ootb-useable EFI code :-)

comment:9 by waddlesplash, 14 months ago

Resolution: invalid
Status: newclosed

You don't need to change UserBuildConfig, just pass the appropriate flag when running configure

Note: See TracTickets for help on using tickets.