Hi all,
I have a question regarding the vesa driver stride when using horizontal
resolution not multiple which do not play nicely with HW constrains for
the stride.
I am working in a Xen/qemu environment where we emulate a Bochs VBE.
Our linux guests will usually use the vesa Xorg driver.
The problem I have noticed happen when we do not use the shadowFB and we
have a mode like 1366x768 with stride of 5504 which needs to be 64 bytes
aligned since we are using the GPU to scan the framebuffer of the guest
(this could not be a limitation for different qemu backends).
The reason why the problem happen is that in the vesa driver, as it is
now, has no way to detect the needed alignment of the framebuffer unless
using the shadowFB.
The VBE (as I understand) has only two ways to say the driver what the
stride should be for a given mode:
1) mode->BytesPerScanline
2) VBEGetLogicalScanline()
at the moment, in the vesa driver, the first information is only used
when using the shadowFB:
pMode = pScrn->modes;
do {
mode = ((VbeModeInfoData*)pMode->Private)->data;
if (mode->BytesPerScanline > pVesa->maxBytesPerScanline) {
pVesa->maxBytesPerScanline = mode->BytesPerScanline;
}
pMode = pMode->next;
} while (pMode != pScrn->modes);
where
pVesa->maxBytesPerScanline
gets only used in VESAWindowLinear()
VESAWindowLinear(ScreenPtr pScreen, CARD32 row, CARD32 offset, int mode,
CARD32 *size, void *closure)
{
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
VESAPtr pVesa = VESAGetRec(pScrn);
*size = pVesa->maxBytesPerScanline;
return ((CARD8 *)pVesa->base + row * pVesa->maxBytesPerScanline +
offset);
}
and as I said VESAWindowLinear() is used only if shadowFB is on
The second information is never used since VESASetMode() is only using
VBESetLogicalScanline() and is never checking if the value was accepted
from the HW or was rounded up and it looks like for mode 1366x768
BytesPerScanline=5504, pScrn->displayWidth if 1368, which results in a
scanline of 5472, which will result in a distorted image.
if (data->data->XResolution != pScrn->displayWidth)
VBESetLogicalScanline(pVesa->pVbe, pScrn->displayWidth);
The spec say that the HW could round up the value written with
VBESetLogicalScanline() (and our emulation is doing so) so I think it
would be appropriate to call VBEGetLogicalScanline() after to check if
the value was accepted as it was or if it was rounded up, in which case
pScrn->displayWidth and pScrn->virtualX should be updated accordingly.
If my understanding is correct, this would explain why when we disable
shadowFB the actual stride is wrong.
If you can confirm my reasoning is correct, I would be happy to post a
patch to fix this in case shadowFB is not used.
Thanks for your time,
Stefano
This is the mode creating problems:
[ 99.232] *Mode: 156 (1366x768)
[ 99.232] ModeAttributes: 0x9b
[ 99.232] WinAAttributes: 0x7
[ 99.232] WinBAttributes: 0x0
[ 99.232] WinGranularity: 64
[ 99.232] WinSize: 64
[ 99.232] WinASegment: 0xa000
[ 99.232] WinBSegment: 0x0
[ 99.232] WinFuncPtr: 0xc000948a
[ 99.232] BytesPerScanline: 5504
[ 99.232] XResolution: 1366
[ 99.232] YResolution: 768
[ 99.232] XCharSize: 8
[ 99.232] YCharSize: 16
[ 99.232] NumberOfPlanes: 1
[ 99.232] BitsPerPixel: 32
[ 99.232] NumberOfBanks: 1
[ 99.232] MemoryModel: 6
[ 99.232] BankSize: 0
[ 99.232] NumberOfImages: 2
[ 99.232] RedMaskSize: 8
[ 99.232] RedFieldPosition: 16
[ 99.232] GreenMaskSize: 8
[ 99.232] GreenFieldPosition: 8
[ 99.232] BlueMaskSize: 8
[ 99.232] BlueFieldPosition: 0
[ 99.232] RsvdMaskSize: 8
[ 99.232] RsvdFieldPosition: 24
[ 99.232] DirectColorModeInfo: 2
[ 99.232] PhysBasePtr: 0xf0000000
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
