On 06/30/2014 02:25 PM, Christopher Friedt wrote:
On Mon, Jun 30, 2014 at 7:48 AM, Thomas Hellstrom thellstrom@vmware.com wrote:
I don't think we can blame video-vmware for this. A kernel driver change that breaks existing user-space is by definition a kernel driver bug, regardless whether exisiting user-space is doing something horrendously stupid.
I wouldn't be so quick to say it's a kernel bug. The fbdev contract hasn't changed. Also xf86-video-vmware isn't using the fbdev driver, and the fbdev driver code is obviously correct (see screenshots in link submitted with initial patch).
As I said. A kernel change that breaks existing user-space is ALWAYS BY DEFINITION a kernel bug. kernel changes are NOT ALLOWED to break existing user-space. The only exception I can see here is if someone uses the old non-kms driver which is not intended to work if vmware fbdev is loaded but that's not the case here, from what I can tell?
So the fix must IMO be a kernel driver fix. My initial guess is that once we set the bytes per line register, it might not be automatically updated when the screen width is changed, but the documentation is poor. I see if I can shed some light over this.
Having dumped all of the svga registers while hacking on vmwgfx, I noticed that the BYTES_PER_LINE field is initially incorrectly set to something way off. My initial reaction is that video-vmware doesn't properly compute the bytes-per-line register, and therefore that it is a video-vmware bug that has always existed.
xf86-video-vmware in kms mode uses the kernel driver to set these registers. FWIW, the modesetting part of the kernel driver uses SVGA_REG_PITCHLOCK instead of SVGA_REG_BYTES_PER_LINE to set the pitch. That's probably where the clash happens.
/Thomas
I'm reproducing the problem and providing a fix for video-vmware as I write this.
C