Date: Wed, 02 Mar 2022 13:40:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261751 --- Comment #4 from Ed Maste <firstname.lastname@example.org> --- Thank you for the photo, I have an idea what's happening here and why I don't see it. I believe this issue is reproducible with vt_vga only, not with an EFI framebuffer. In sys/dev/vt/hw/vga/vt_vga.c:vga_bitblt_one_text_pixels_block() there is an optimized special case for a "pixel block" having only two colours, and a more general case for n colours. In the case in your photo we are using the general case. I suspect the general case has the R and B channels swapped. If you can easily try a patch we could confirm this by disabling the optimization. For example, diff --git a/sys/dev/vt/hw/vga/vt_vga.c b/sys/dev/vt/hw/vga/vt_vga.c index 563867399e53..c8041f1dac8b 100644 --- a/sys/dev/vt/hw/vga/vt_vga.c +++ b/sys/dev/vt/hw/vga/vt_vga.c @@ -770,7 +770,7 @@ vga_bitblt_one_text_pixels_block(struct vt_device *vd, * The pixels block is completed, we can now draw it on the * screen. */ - if (used_colors == 2) + if (0 && used_colors == 2) vga_bitblt_pixels_block_2colors(vd, pattern_2colors, fg, bg, x, y, vf->vf_height); else If I am correct this would result in a display that is consistently incorrect -- the entire dialog background would be red, not just the location of the mouse cursor. -- You are receiving this mail because: You are the assignee for the bug.