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"
>> <xav...@bachelot.org> To: "Kevin Brace" <kevinbr...@gmx.com> Cc:
>> openchrome-devel@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
>>
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
