Wrong virtualX when using vesa driver with no shadowFB

[Adam Jackson]

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