Sometime when building -CURRENT and updating loader.efi between May 16 01:52 and Jun 24 03:12, the resulting loader.efi will result in 4K GOP output being slightly garbled in the menu of loader.efi. I see the bottom line of my screen as colored perlin noise and the titles of menu entries are offset, for some reason. 4K resolution for UEFI GOP isn't selected by default for me on RX 6800 XT, so I have this in /boot/lua/local.lua: require("cli") local color = require("color") local core = require("core") local config = require("config") if core.isUEFIBoot() then loader.perform("gop set 0") end I don't have the time currently to bisect this so I'll leave this PR here until I'll find some. I also see https://lists.freebsd.org/archives/freebsd-current/2026-June/010385.html which reports an issue that I experience too maybe.
(In reply to Evgenii Khramtsov from comment #0) Could you please try this? https://reviews.freebsd.org/D57821
(In reply to ShengYi Hung from comment #1) D57821 fixes it for me. I've also compared visually D57821 and loader.efi backup from May 16 01:52 and I did not find any difference except for the very top left ASCII symbol on screen which is different, e.g. something alike underscore vs. slash. I'm not sure if this is related to the recent regression or not, as I have never paid any attention to what the symbol in the top left corner of screen ever was.
(In reply to Evgenii Khramtsov from comment #2) Thanks! This patch fix two things. 1. Some firmware does not handle Blt ops with offset correctly. (from some open-sourced bootloader project) 2. My bad math on calculating pixel offset. The first part is in EFI_GRAPHICS_OUTPUT_BLT_PIXEL *src; chunk. The second part is in other chunk. I am curious which part fix the problem in the end. Could you please try to apply different chunk to help me identify this.
(In reply to ShengYi Hung from comment #3) > The first part is in EFI_GRAPHICS_OUTPUT_BLT_PIXEL *src; chunk. > The second part is in other chunk. > Could you please try to apply different chunk to help me identify this. I've applied the patch without the @@ -1104,13 +1104,20 @@ hunk (the one with "EFI_GRAPHICS_OUTPUT_BLT_PIXEL") this time. 2. alone fixes the regression for me.
I've had a few people that have contacted me about this too, and I've recommended https://reviews.freebsd.org/D57821 to them. I'll let you know how it works out for them.
(In reply to Warner Losh from comment #5) Thanks Warner!
(In reply to Evgenii Khramtsov from comment #2) Top left corner symbol is from spinner.
Changed to in progress since there's a patch in review.
(In reply to Warner Losh from comment #8) Patch at review D57821 fixes the issue on Minisforum MS-01 (AMI UEFI firmware). Applied onto commit base 7140742c8c684c96644c094ed489ff5167c77c5a. For a datapoint: ThinkPad P52 (Phoenix-based UEFI firmware) wasn't affected.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=76aa776b5f47ecd0d45336e22795fef98af57d2f commit 76aa776b5f47ecd0d45336e22795fef98af57d2f Author: ShengYi Hung <aokblast@FreeBSD.org> AuthorDate: 2026-06-24 14:31:03 +0000 Commit: ShengYi Hung <aokblast@FreeBSD.org> CommitDate: 2026-06-30 19:52:55 +0000 stand: Fix shadow buffer offset handling The shadow buffer is addressed relative to `tg_origin`, which includes the padding offset, whereas `gfxfb_blt` operates on coordinates without that offset. To make `gfx_fb_copy_area` emulate the behavior of `gfxfb_blt`, the source coordinates must include the padding offset, while the destination coordinates must not. The original implementation omitted the offset from the source coordinates; this change corrects that. Additionally, `gfx_fb_cons_display` already applies the padding offset, so the redundant adjustment is removed. PR: 296246 Reported by: 2khramtsov@gmail.com Reviewed by: imp Tested by: 2khramtsov@gmail.com, junchoon@dec.sakura.ne.jp, naito.yuichiro_@gmail.com Fixes: 32da2f23ae4d MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57821 stand/common/gfx_fb.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-)
(In reply to commit-hook from comment #10) Thanks!
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4a1a1bf3afc7643356ed7d139cbdad47a9efc4c4 commit 4a1a1bf3afc7643356ed7d139cbdad47a9efc4c4 Author: ShengYi Hung <aokblast@FreeBSD.org> AuthorDate: 2026-06-24 14:31:03 +0000 Commit: ShengYi Hung <aokblast@FreeBSD.org> CommitDate: 2026-07-25 13:13:24 +0000 stand: Fix shadow buffer offset handling The shadow buffer is addressed relative to `tg_origin`, which includes the padding offset, whereas `gfxfb_blt` operates on coordinates without that offset. To make `gfx_fb_copy_area` emulate the behavior of `gfxfb_blt`, the source coordinates must include the padding offset, while the destination coordinates must not. The original implementation omitted the offset from the source coordinates; this change corrects that. Additionally, `gfx_fb_cons_display` already applies the padding offset, so the redundant adjustment is removed. PR: 296246 Reported by: 2khramtsov@gmail.com Reviewed by: imp Tested by: 2khramtsov@gmail.com, junchoon@dec.sakura.ne.jp, naito.yuichiro_@gmail.com Fixes: 32da2f23ae4d MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57821 (cherry picked from commit 76aa776b5f47ecd0d45336e22795fef98af57d2f) stand/common/gfx_fb.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-)