On Fri, 2014-02-14 at 11:47 +0000, Stefano Panella wrote: > 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.
I'd say more like "doesn't" than "has no way to". > 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() There's also mode->XCharSize, which in the example you give is 8; which would explain things, since 1366 % 8 != 0. But BytesPerScanline is probably a more obvious thing to look at. > 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. I think your understanding is correct. Sorry for being slow to respond to this, and thanks for investigating it! - ajax _______________________________________________ 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