[Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

[Kevin Brace]

Hi Xavier,

Sorry for missing the reply for several days, but I have been thinking about this issue for the past few days.
I have several possible explanations as to why things are not working.
Of course, it is not proven so you will need to test it yourself.
Xavier, since you mentioned pitch, I noticed that when reading the Xorg.0.log, I noticed that the screen resolution is 1368 x 768.
I believe the correct resolution is 1366 x 768.
I know that sounds strange, but VIA EPIA-M830 user manual lists the panel index, and it assigns 1366 x 768 for panel index 10.
Yes, 1366 is a number that is not dividable by 8, but for some reason, the flat panel industry uses this odd resolution for some FPs.
    You might be wondering why this causes the old code which allowed IGA1 to work fine with 1366 x 768 flat panel, but not with IGA2.
Due to the way IBM developed VGA (and probably this goes back to EGA and even Motorola MC6845 I suppose), when IGA1 horizontal display period is set, the value being set has to be shifted by 3 bit positions (8 pixel boundary).
IGA1 pretty much drags the original VGA way of setting the horizontal display period since it is a superset of VGA, but IGA2 is implemented without such restriction since it is a clean sheet design.
IGA2 horizontal resolution can be set at 1 pixel boundary.
Since you were using 1368 instead of 1366, this means that all other display parameters get messed up like blank period and sync period as well. 
I know that the screen can easily get messed up if these numbers are off even slightly, so this might be why you are seeing a distorted picture with V2 and V3 patches I sent to you.
That being said, you said you are seeing a cursor with the V2 and V3 patches that previously did not display.
This probably means that not specifying IGA2 for LVDS1 was one of the reason why the screen regression happened, but also 1366 vs. 1368 issue came into play, and I also speculate IGA2 itself is far more sensitive to the display period being off by even 2 pixels.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer


> Sent: Thursday, March 16, 2017 at 11:17 AM
> From: "Xavier Bachelot" <xavier at bachelot.org>
> To: "Kevin Brace" <kevinbrace at gmx.com>
> Cc: openchrome-devel at lists.freedesktop.org
> Subject: Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop
>
> Hi Kevin,
> 
> On 15/03/2017 23:33, Kevin Brace wrote:
> > Try this third version of the patch.
> > I changed the FP power on / off code to use software controlled method already proven with CX700 / VX700 and VX800 chipsets.
> >
> No improvement over patch v2 with patch v3. I haven't collected neither 
> log nor regs dump though.
> 
> I started to poke at register manually after applying v2 the other day, 
> but no luck. Is there any specific range of registers that are more 
> likely than others to help ?
> 
> Would a picture of the distorted screen, together with a picture of how 
> it should look like, help ? I don't know how to describe the distortion, 
> a picture is worth a thousand word :-) The display is compressed in the 
> top third or half of the screen, and diagonally stretched to the right. 
> The remaining bottom part of the screen seems like uninitialized memory. 
> It seems like the framebuffer is using a different horizontal resolution 
> than the display. Could it be something like wrong "pitch" ?
> 
> Regards,
> Xavier
>