[Openchrome-devel] [Bug 100679] Garbled graphics when resuming from standby
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sat Apr 15 07:11:23 UTC 2017
Kevin Brace <kevinbrace at gmx.com> changed:
What |Removed |Added
CC| |kevinbrace at gmx.com
--- Comment #1 from Kevin Brace <kevinbrace at gmx.com> ---
I will need the following data.
1) Xorg.0.log from /var/log
2) lspci output
3) via_regs_dump -d output from Version 0.3.3
4) via_regs_dump -d output from Version 0.6.10x (latest one will be better)
After moving to your folder (directory) where xf86-video-openchrome Git cloned
image is located.
$ lspci -vvnn > Fujitsu_Siemens_AMILO_Li_1705_lspci.txt
$ ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug
$ cd tools
$ sudo ./via_regs_dump -d >
In order to reinstall OpenChrome DDX Version 0.3.3, do the following.
$ sudo apt-get remove xserver-xorg-video-openchrome
$ sudo apt-get install xserver-xorg-video-openchrome
In order to get back to OpenChrome DDX Version 0.6.10x, reinstall Version 0.3.3
using the above procedure, and then recompile the code from the latest Git
repository master branch head.
If I were to give some background on what is going on, I personally think
the issue is fixable.
What happened with OpenChrome DDX in the past is that the code was heavily
relying on the VGA BIOS during boot time to set certain registers related to
the FP (Flat Panel).
This is really a disaster since when the computer resumes from standby (ACPI S3
State), the registers are typically in an indeterminate state.
This is why the display gets messed up when resuming from standby.
Unfortunately, all the three laptops with VN896 chipset I have appear to use a
12-bit interface to connect to the FP.
It appears that your laptop uses a 24-bit interface to connect to the FP, and
very likely the code is not currently written properly to support a 24-bit
Note that I have been collecting various VIA chipset hardware, but there are
limits to getting a hold of dated hardware in a good condition.
Your particular model I do not think was sold here in the United States of
America, so that's another reason why the code is not working properly.
Around December 2016 to January 2017, I had to deal with a rather odd issue
of HP 2133 Mini-Note's PCIe WLAN going wrong with the latest OpenChrome.
It turned out some rather interesting way VIA Technologies implemented their
PCIe and FP interface that caused the bug.
Based on that experience, I think I have a better understand of which registers
to turn on or off correctly to fix your problem.
About the same time you reported the issue, I started the process of
rewriting the FP related code since the existing code is in a bad shape.
Another reason for this rewrite is to share the code between the existing
OpenChrome DDX and the next generation OpenChrome DRM.
Of the several "maintained" Linux x86 graphics stacks (i.e., someone is still
actively writing code today), only OpenChrome currently does not have the
support for KMS (Kernel Mode Setting).
The Big 3 of Linux x86 graphics stack (in no particular order, AMD Radeon,
Intel, and Nouveau for NVIDIA) have already converted to KMS long time ago, but
OpenChrome is way, way lagging behind.
This is due to the previous developer who worked on drm-openchrome disappeared
completely, and a novice developer with little experience and assistance (me)
had to figure everything out on my own effort.
I have done some rewrite and using common code for analog (VGA) and one type of
DVI encoder, and I am working on this for FP, but FP's registers have changed
over the years, so it is a little harder to rewrite the code since it is my
policy not to break the code when I commit the code (In practice, breakage
happens, but it is my general intention not to break the code when I commit new
code even on the master branch.).
drm-openchrome's mode setting code at this point behaves quite differently than
OpenChrome DDX's mode setting code, and I find this undesirable since
drm-openchrome is a lot buggier than OpenChrome DDX at this point.
Plus, it takes 5 minutes to compile and test OpenChrome DDX versus 30 minutes
for drm-openchrome, so it is far easier to prove that code works on OpenChrome
DDX than drm-openchrome.
For these various reasons, I am in the process of rewriting OpenChrome DDX's
mode setting code, and porting it to drm-openchrome, so that mode setting
behavior between the two will become more or less similar.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openchrome-devel