Date: Tue, 30 Dec 2025 20:27:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 291935] Vidconsole (amd64 only) does now show anything on old hardware (MacBook2,1) Message-ID: <bug-291935-227-F43aK2d3hK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-291935-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291935 --- Comment #7 from Ahmad Khalifa <vexeduxr@FreeBSD.org> --- Created attachment 266658 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=266658&action=edit UGA gfxfb loader patch Hmm, digging deeper into this, there does seem to be some weirdness here. In gfxfb_blt(), we assume that gfx_state.tg_private points to a EFI_GRAPHICS_OUTPUT_PROTOCOL structure (which in UGA's case, it doesn't). At first glance, that looks like it would be problematic, since we try to deference it and call it's Blt() function. However, it looks like both EFI_GRAPHICS_OUTPUT_PROTOCOL and EFI_UGA_DRAW_PROTOCOL have both their Blt functions at the same offset (which is probably why the loader isn't hanging/crashing). I doubt this is intentional though. So it would seem like the problem here is that the MacBook's Blt function just doesn't work. IMO we shouldn't be using the firmware provided Blt functions on UGA platforms at all. The attached patch switches to gfxfb's implementation of these functions if we're on UGA. Could you try and see if that fixes the issue? (this should be applied over the previous patch of course) -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-291935-227-F43aK2d3hK>