https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261751
--- Comment #4 from Ed Maste <ema...@freebsd.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.
