[Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

[Kevin Brace]

Hi Xavier,

These are things I will like to do moving forward.
I will like to commit a few things into the master branch.
They are,

1) Updated mode setting code for VX855 and VX900 chipset
2) Replacing the wrong VIA Panel Index 10 with 1366 x 768
3) Addition of two helper functions

For 1 and 2, I will add your name as "Signed-off-by < . . . >" in order to give you credit.
I hope you can agree to this.
I will not commit the power on / off code for now.
After this is done, then it will be easier to perform experiments with temporarily assigning IGA1 to FP and IGA2 to VGA.
Theoretically, if the code is written correctly, both settings should work fine.
As for my own equipment, OpenChrome Version 0.6 worked fine on ECS VX900-I mainboard when VGA was assigned to IGA1, and I utilized 1680 x 1050 resolution.
After the code commit is done, I will try to assign IGA2 for VGA to see how VX900-I mainboard performs.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer



> Sent: Saturday, March 18, 2017 at 11:37 PM
> 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 18/03/2017 22:32, Kevin Brace wrote:
> > Hi Xavier,
> > 
> > Sorry for missing the reply for several days, but I have been
> > thinking about this issue for the past few days.
> 
> No worries.
> 
> > 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.
> 
> That doesn't surprise me that much, iirc the (now mostly defunct)
> Samsung NC20 I own used 1366x768 too. I'd really need to fix it someday...
> 
> > 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.
> 
> Just gave it a try with 1366x768 instead of 1368x768, but that doesn't
> help. The screen is still distorted, not the same, but similarly. Also,
> the part of the screen displaying a picture is now bigger, it's covering
> half the height of the screen, rather than one third with 1368x768.
> 
> > 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.
> 
> The only condition I was not sure there was a cursor is when using 0.6.0
> + panel id fix (1368x768) + via_regs_dump -w 3d5.99 0x11
> I just checked and the cursor is there too.
> Both v2 and v3 also have the cursor.
> Oh, and not sure I mentioned it, the cursor looks fine. it's not
> distorted in any way.
> 
> > 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.
> > 
> Let's assume the Epia M830 manual is correct.
> I can't get my hands on the manual for this laptop to make sure of the
> expected resolution (assuming the manual specify it and is correct
> indeed) at the moment, I will need to dig deeper, I'm not even sure
> there was one in the first place. Can't find it on the net either, this
> is a noname computer, likely a reference design for VIA, who sent it to
> me for testing purposes back in the days.
> dmidecode says :
>         Manufacturer: iDOT Computers, Inc.
>         Product Name: L740
> 
> Any other idea ?
> 
> Regards,
> Xavier
> 
> 
> > 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
> >> 
> 
>