Critical bug in plotting pixels

[austanss]

Dare I say it: my display driver is broken.

I already had an issue with plotting pixels to the double buffer, but now the same issue has arised in plotting pixels to the framebuffer.

This is a big-time issue, ofc.

I am however unsure what level this issue is at. I can memset the double buffer a certain color, and buffer it, and it works.

Plotting pixels using the function, doesn't appear to work properly.

Rendering text, the text's pixels are spaced out by ~4 pixels.

I've worked my way through the functions from the top layer to the bottom and haven't found the bug.

Anyone have a clue?

Interesting source files:
https://github.com/microNET-OS/microCOR ... rc/gfx.cxx
https://github.com/microNET-OS/microCOR ... rminal.cxx
https://github.com/microNET-OS/microCOR ... /kmain.cxx

[ilmmatias]

Shouldn't it be

Code: Select all

gop.pixels_per_scan_line * posi.y

instead of

Code: Select all

4 * gop.pixels_per_scan_line * posi.y

(gfx.cxx, lines 57 and 62)?

[austanss]

I didn't think so, because the every 4 bytes is one pixel, so I thought I would be compensating for that, but now I am unsure.

[ilmmatias]

pixels_per_scan_line (if it's the same one from the EFI GOP) is already is multiplied by the pixel size (as it is supposed to be the size of a whole line in bytes).

[austanss]

Well now I am using

Code: Select all

gop.framebuffer_base[gop.x_resolution * posi.y + posi.x] = pixel;

which accounts for the size of the pixels and I am still getting this bug, which makes it appear it is the plotter, not the plotting, which in this case is the terminal driver.

[austanss]

OK, issue resolved.

I was applying fixes, but my build system was not updating the kernel.