On Wed, Jan 07, 2015 at 07:16:16AM +0100, Paolo Bonzini wrote:
On 06/01/2015 21:22, Kevin O'Connor wrote:
On Tue, Jan 06, 2015 at 08:59:09PM +0100, Paolo Bonzini wrote:
On 06/01/2015 16:49, Kevin O'Connor wrote:
- if (vga_emulate_text()) {
// Read bottom right pixel of the cell to guess bg colorop.y += cheight-1;handle_gfx_op(&op);op.y -= cheight-1;bgattr = op.pixels[7];fgattr = bgattr ^ 0x7;car = 1;- }
It's better to use the top right pixel. The bottom right has a false positive for characters 23 and 95.
Hrmm. How did you test? The script I wrote shows the bottom right as the least number of false positives. With the 8x16 font, there are six false positives, but all six are mirror images of other characters so there is no way to avoid them.
I used the 8x8 font. I suspect that my new favorite testcase (gwbasic, what else) will mess up PRINT "_" if you use the bottom right.
The patch only changes behavior when vga_emulate_text() is true though. That only happens for the "coreboot framebuffer" seavgabios, and it is only activated when the application thinks it's in text mode (mode 0x03).
Basically, cbvga seavgabios is used when coreboot knows how to initialize an onboard vga adapter, and the user doesn't have a real vgabios (or doesn't want to run it). The cbvga code emulates text mode character accesses by translating them to a graphical framebuffer (setup by coreboot). So, although the video adapter is technically in a graphical mode, we want the vgabios responses to look like text mode responses. The cbvga code only enables the 8x16 font, and it wouldn't really make sense for it to use an 8x8 font (given the size of modern lcd screens).
That said, it would be nice to try to avoid conflicts even with the 8x8 font - it's why I chose lower right instead of upper left or lower left. Unfortunately, upper right has additional conflicts for the 8x16 font.
So, unless I've missed something, I don't think it impacts gwbasic.
-Kevin