[Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

[Kevin Brace]

Hi Xavier,

Regarding the first fix, I can consider taking it, but not really for the second fix.
I think the problem here is that OpenChrome code currently lacks the proper initialization of certain unknown registers related to FP that VGA BIOS is setting correctly for IGA1, but not IGA2.
After numerous experiments with OpenChrome DDX and the still in development OpenChrome DRM with KMS support, it appears that VGA BIOS initializes IGA1 for FP use coming out when the computer boots whatever OS, but due to certain registers not being set correctly by OpenChrome, it is the likely cause of why it does not work properly for IGA2 on VX900 chipset.
Unfortunately, I do not own a laptop with VX900 chipset, although I do have two desktop models with VX900 chipset (ZOTAC ZBOX nano VD01 and ECS VX900-I mainboard).
None of them support flat panels (VX900-I has LVDS connector traces, but the connector is not populated)
    The solution to this bug I think will be to figure out which unknown register needs to be turned on in order for IGA2 to work correctly with a FP, not reversing the commit.
I do not know the particular laptop model you are using, but assuming that the laptop in question comes with a VGA connector, you may want to use that when doing the debugging.
You will like to do a dump of the registers to see what is going on.

$ ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug --enable-viaregtool CFLAGS="-Wall"
$ make
$ cd tools
$ sudo ./via_regs_dump -d > VX900_Laptop_via_regs_dump.txt


In general, OpenChrome has historically suffered from not initializing all the relevant register when performing mode setting.
>From my own experience dealing with this issue, this has turned out to be the biggest reason why FP fails when resuming from standby.
OpenChrome code in the past was way too much relying on VGA BIOS to set the registers for proper operation, and this is why FP often gets lost when the computer comes out of standby.
I am against a quick fix kind of way OpenChrome has operated for too long, and we will need to come up with a more permanent long term fix to deal with this issue.
The next generation OpenChrome DRM will also need this fix eventually, so I will rather figure out a fix now than later.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer


> Date: Sat, 11 Mar 2017 00:06:44 +0100
> From: Xavier Bachelot <xavier at bachelot.org>
> To: openchrome-devel at lists.freedesktop.org
> Subject: [Openchrome-devel] openchrome 0.6.0 regressions on VX900
> 	laptop
> Message-ID: <891808d3-3665-1278-66ee-e61a31b6d9d0 at bachelot.org>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> I have a VX900 laptop that got broken twice between openchrome 0.5.0 and
> 0.6.0.
> 
> First breakage comes from the update of the panel resolution table with
> the table from viafb. 0xA got changed from 1368x768 to 1024x768. I'm not
> sure why the viafb table was assumed to be better than openchrome table,
> but at least in this case, it proved to be wrong.
> 
> Faulty commit : d90a71c7146470162cb2bd1f76f9c5cfcec09101
> Fix : attached patch.
> 
> Second breakage is unconditionally setting the flat panel to IGA2 for
> the VX900. The VX900 is the only chipset which was allowed to be on
> either IGA1 or IGA2, all older chipsets had the FP already fixed to
> IGA2. For whatever reason, this doesn't work for this laptop, which then
> only displays a garbled screen.
> 
> Faulty commit : 6b66a9ec3c0c3caf75e804f0abe19871df014c4b
> Fix : revert the commit.
> 
> Happy to provide more testing or info if needed.
> 
> Regards,
> Xavier
>