OSDev.org

Hi,

I'm making my own experimental haswell 2D graphics driver and I've just managed to perform a few successful hardware BLTs. They are not fully correct though due to my inability to figure out how many scan lines the display (my video output comes out in 1080i60 format) has. Is this something that should be contained in the EDID information for the display or is it a graphics card parameter?

Setup is as straightforward. I'm re-using the BIOS initialization of the card (display ports - hdmi in this case) for now due to the great complexity of initialization and port clocking/training routines I am not willing to go through yet.

Hi,

mateuszb wrote:I'm making my own experimental haswell 2D graphics driver and I've just managed to perform a few successful hardware BLTs. They are not fully correct though due to my inability to figure out how many scan lines the display (my video output comes out in 1080i60 format) has. Is this something that should be contained in the EDID information for the display or is it a graphics card parameter?

EDID tells you which different combinations of video signals the monitor supports (not which one its currently using).

I'm not sure what you mean by "graphics card parameter", and also not sure how you managed to set a video mode without knowing which video mode you set. Typically you examine the "VBE mode information" for each mode before you can know which video mode is the one you're looking for; and the "VBE mode information" you would've already used contains the information you need (including horizontal and vertical resolution, number of bytes between screen lines, and pixel format).


Cheers,

Brendan

Brendan,

I'm not using VBE. I'm running my code on a native UEFI system and I got all the necessary information about the current video mode set by the UEFI firmware via GOP protocol. The GOP Doesn't provide me with the scan line information. I know horozontal and vertical resolutions only and pixel format. Setting width and height as well as pitch arguments to these values when performing a full screen blit doesn't fill out the whole screen but only about 1/3 of it. I found myself having to increase number of scan lines dramatically to fill out entire screen. Not sure what is going on.

Ok, so I solved it. It all boiled down to a simple mistake of not multiplying the appropriate dimensions by the pixel size (4 bytes).

Hi,

mateuszb wrote:I'm not using VBE. I'm running my code on a native UEFI system and I got all the necessary information about the current video mode set by the UEFI firmware via GOP protocol. The GOP Doesn't provide me with the scan line information. I know horozontal and vertical resolutions only and pixel format. Setting width and height as well as pitch arguments to these values when performing a full screen blit doesn't fill out the whole screen but only about 1/3 of it. I found myself having to increase number of scan lines dramatically to fill out entire screen. Not sure what is going on.

Hrm - for some reason I thought you were re-using the BIOS initialization of the card.

The GOP protocol (the "EFI_GRAPHICS_OUTPUT_MODE_INFORMATION" structure) does include a "PixelsPerScanLine" field. Do not use the horizontal resolution instead of the pixels per scanline, because for some video modes they are different. For example, for 1920*1280 mode you might have 2048 pixels per scan line (1920 visible pixels and 128 invisible pixels).


Cheers,

Brendan