Hi Marty,

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 --enable-viaregtool CFLAGS="-Wall"
$ make
$ cd tools
$ sudo ./via_regs_dump -d > Fujitsu_Siemens_AMILO_Li_1705_via_regs_dump_Version_0_x.txt

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 interface.
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.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/log/
https://cgit.freedesktop.org/openchrome/drm-openchrome/log/

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.

Created attachment 130868 [details]
Xorg.0.log

Created attachment 130869 [details]
lspci output

Created attachment 130870 [details]
via_regs_dump Version 0.3.3

Created attachment 130871 [details]
via_regs_dump Version 0.6.107

Hi Kevin,

Thank you for looking into this.
I have attached all files you requested.

Regards,
Marty

Hi Marty,

Thanks for providing me with the information I asked.
I may need a little more information since I do not have a similar model (VN896 chipset with a 24-bit interface FP) with me.

1) CRTC Register 0x96 (3D5.96)

$ sudo ./via_regs_dump -r 3d5.96

I will like to know this register's value since "via_regs_dump -d" does not provide the value of this register.
At least I need to know the value for Version 0.6.10x, but it will be nice to know the value for Version 0.3.3 as well.

2) Xorg.0.log for Version 0.3.3

I2C bus probing of FP is disabled with Version 0.6, although I am planning to get it back eventually.
That being said, this feature worked with Version 0.3.3, so I will like to know how it performs.

3) via_regs_dump -d after Ctrl + Alt + F1

In order to capture it, copy via_regs_dump to /home/"Your User ID".
You can switch to VT (Virtual Terminal), enter User ID and password, and then type

$ sudo ./via_regs_dump -d > ("Whatever appropriate name")

When doing this, you will have to deal with a messed up screen, so you may want to remember that you need to enter your password before the program is executed.
It will be nice if you can do this for both Version 0.3.3 and 0.6, but 0.6 alone might be enough.


Again, it is probably desirable for an external monitor to be used when dealing with this since you will lose control of the FP.
As for myself, I will try to come up with a patch for you to try in a day or two, based on the information I have now.

Created attachment 130889 [details]
VIA Register 0x96  for V0.3.3

Created attachment 130890 [details]
VIA Register 0x96  for V0.6.107

Created attachment 130891 [details]
Xorg.0.log for Version 0.3.3

Created attachment 130892 [details]
VIA Registers after Ctrl-Alt-F1 for Version 0.6.107

Created attachment 130893 [details]
VIA Registers after Ctrl-Alt-F1 for Version 0.3.3

Hi Kevin,

Here are the files you requested.
One remark: Switching to tty1 works with Version 0.3.3!

Regards,
Marty

Just to be more specific on the last remark:

Ctrl-Alt-F1 works with V0.3.3 only if I disable the graphical terminal in the grub settings (/etc/default/grub):

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=console

This trick doesn't work with V0.6.107 anymore.

Hi
I have similar problems with CN896/VN896/P4M900 [Chrome 9 HC].
What does not work with 0.6.107:
-after switching to console (Ctrl-Alt-F2-7), disappears (probably somewhere is) - the screen is black,
-after suspend/resume, there is no cursor (as a remedy I set software cursor), and what does not work - xv (before susppend he was working).

In the case of another configuration (with viafb) is even worse. Right after the start Xorg no hardware cursor and xv.

Created attachment 130920 [details]
Xorg.0.log

Created attachment 130921 [details]
VIA Registers after start

Created attachment 130922 [details]
VIA Registers after start - switch to console

Created attachment 130923 [details]
VIA Registers after resume

Created attachment 130924 [details]
VIA Registers after resume - switch to console

> and what does not work - xv (before susppend he was working).

Probably xv after suspend-resume works. Only the content goes where it's needed. Mplayer (simple benchmark -vo xv) it does not show any difference, except the most important one - the content of the screen.

Created attachment 130925 [details]
VIA Registers after start - openchrome 0.3.3 (switch to console - works)

Created attachment 130935 [details] [review]
VN896 chipset 24-bit FP interface patch Version 1

This is the first version of the patch to test whether or not 24-bit FP interface mode is working on VN896 chipset.
The patch was generated against Version 0.6.108 that was just committed, but it should also work against Version 0.6.107 as well.

Hi Marty,

This is the first version of the patch to see if the FP is working after returning from VT.
After researching this issue, it appears that all of the VN896 chipset laptops I have use a 12-bit interface to a FP LVDS chip.
Here, a FP LVDS bridge chip (typically VIA Technologies VT1637 dual channel LVDS bridge operating in single channel LVDS mode) converts dual edged (DDR or Double Data Rate.) interface signals to LVDS signals for the FP.
Because I did not have a laptop with a 24-bit interface, the code for it was not really there to support it properly.
In your case, it appears that an 18-bit interface (24-bit interface with a few bits removed from each RGB bits) is used to connect to VT1634AL single channel LVDS bridge chip.

(In reply to latalante from comment #14)

Hi latalante,

Just for my reference, it will be helpful to know the laptop model you are using, but that being said, I am aware of the existence of several VN896 related bugs with the current OpenChrome DDX.

1) Hardware cursor disappears when resuming

I am personally aware of this bug for some time.
It appears that you are using Arch Linux, but with Ubuntu based OSes, I know that Lubuntu 12.04 based OSes have issues with restoring the mouse cursor.
However, hardware cursor is properly restored on Xubuntu 14.04.
This issue also appears to be rather machine specific.
For example, MSI VR321 based laptop is prone to the bug on Lubuntu 12.04, but not HP 2133.
I still have not figured out the root cause of the bug.
Attaching a VGA monitor simultaneously appears to prevent the issue from happening in the first place.


2) VT screen goes completely dark when entering it after resuming from standby

Again, I have been aware of this problem, but I have even less clues as to how to fix it.
Many registers appear to get corrupted when resuming from standby, and frankly, this issue may not be solvable during the current DDX based mode setting (User Mode Setting or UMS) regime.
I am hoping that future KMS (Kernel Mode Setting) supporting OpenChrome DRM will not suffer from this issue, but OpenChrome DRM still suffers from 2 serious bugs  (Excessive memory usage issue and runtime mode setting X Server crash bug) left behind by the previous developer, so it is nowhere near ready for Linux kernel mainline inclusion.


3) Xv issues

I have not touched Xv or XvMC so far.
Hardware cursor issues might very well be video accelerator related issue since the two are sort of related on VIA IGP hardware.



> Hi
> I have similar problems with CN896/VN896/P4M900 [Chrome 9 HC].
> What does not work with 0.6.107:
> -after switching to console (Ctrl-Alt-F2-7), disappears (probably somewhere
> is) - the screen is black,
> -after suspend/resume, there is no cursor (as a remedy I set software
> cursor), and what does not work - xv (before susppend he was working).
> 
> In the case of another configuration (with viafb) is even worse. Right after
> the start Xorg no hardware cursor and xv.

(In reply to Kevin Brace from comment #24)

> Just for my reference, it will be helpful to know the laptop model you are
> using
It is MiTAC Notebook PC. Probably not much explain.

> 1) Hardware cursor disappears when resuming
It may not matter, but I get warnings when compiling (Xorg 1.19.3, gcc 6.3.1).

via_display.c: In function ‘iga1_crtc_commit’:
via_display.c:3848:9: warning: ‘xf86_reload_cursors’ is deprecated [-Wdeprecated-declarations]
         xf86_reload_cursors(crtc->scrn->pScreen);
         ^~~~~~~~~~~~~~~~~~~
In file included from via_driver.h:54:0,
                 from via_display.c:32:
/usr/include/xorg/xf86Crtc.h:991:37: note: declared here
 static _X_INLINE _X_DEPRECATED void xf86_reload_cursors(ScreenPtr screen) {}
                                     ^~~~~~~~~~~~~~~~~~~
via_display.c: In function ‘iga2_crtc_commit’:
via_display.c:4254:9: warning: ‘xf86_reload_cursors’ is deprecated [-Wdeprecated-declarations]
         xf86_reload_cursors(crtc->scrn->pScreen);
         ^~~~~~~~~~~~~~~~~~~
In file included from via_driver.h:54:0,
                 from via_display.c:32:
/usr/include/xorg/xf86Crtc.h:991:37: note: declared here
 static _X_INLINE _X_DEPRECATED void xf86_reload_cursors(ScreenPtr screen) {}
                                     ^~~~~~~~~~~~~~~~~~~
 
> 2) VT screen goes completely dark when entering it after resuming from
> standby
Not exactly, VT (Console: VGA 80x25) disappears after startup Xorg.

All in all current version it is the best possible configuration (loss of lost Xv after resuming).
I also tried the KMS version (drm-openchrome), without success. Xorg did not want to run.
"xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)"
or
"unable to map MMIO permission denied"
Maybe it was related to kernel config (CONFIG_STRICT_DEVMEM, CONFIG_IO_STRICT_DEVMEM) or the xorg version was too new.

Created attachment 130940 [details]
VIA Registers for Version 0.6.108 / PatchV1

Created attachment 130941 [details]
VIA Registers after Ctrl-Alt-F1 for Version 0.6.108 / PatchV1

Hi Kevin,

Unfortunately the patch didn't change anything with respect to VT.
I have attached the register dumps again before and after switching to tty1.

Regards,
Marty

(In reply to Marty from comment #27)

Hi Marty,

Does the X Server (OS GUI) screen come back after standby resume?
I am aware of VT (Ctrl + Alt + F(1-6)) screen going dark (i.e., blank screen) when you enter it after standby resume.
Unfortunately, I do not really know how to solve this particular issue at this point.


> Created attachment 130941 [details]
> VIA Registers after Ctrl-Alt-F1 for Version 0.6.108 / PatchV1
> 
> Hi Kevin,
> 
> Unfortunately the patch didn't change anything with respect to VT.
> I have attached the register dumps again before and after switching to tty1.
> 
> Regards,
> Marty

Hi Kevin,

After resume the screen is still not correctly restored. But the behaviour is different from V0.6.107 without patch:

1. The X-Server now at least allows to "recognize" the GUI (with correct size) and partly to read some things. But the whole screen is filled with big round colored artifacts. It looks very artistic! The mouse cursor seems to be invisible.

2. If I switch to VT I now get just a black screen. (I had never this before.)

I am not sure if it has any value anymore. But I did reg-dumps after resume. Let me attach them again.

Regards,
Marty

Created attachment 130953 [details]
VIA Registers after Resume for V0.6.108 / PatchV1

Created attachment 130954 [details]
VIA Registers after Resume and Switch to VT for V0.6.108 / PatchV1

All problems have disappeared under the addition to kernel - acpi_sleep=s3_bios

Now after standby resume works hardware cursor and Xv, it does everything I need.

One more strange thing. I do not use viafb.
The kernel parameters I use - modprobe.blacklist=viafb, vga=normal.
Openchrome 0.3.3
If I switch to VT from X, the screen is properly displayed. After waking up also.
Openchrome 0.6.108
If I switch to VT from X, the screen is black. And here is a surprise. After waking up suddenly appeared. Really weird.

Here's how it looks without running the X server.

kernel: modprobe.blacklist=viafb vga=normal
after resume - screen is black

kernel: modprobe.blacklist=viafb vga=normal acpi_sleep=s3_bios
after resume - screen is properly displayed

kernel: viafb.viafb_mode=1280x800 viafb.viafb_active_dev=LCD viafb.viafb_lcd_panel_id=19
after resume - screen is corrupted

kernel: viafb.viafb_mode=1280x800 viafb.viafb_active_dev=LCD viafb.viafb_lcd_panel_id=19 acpi_sleep=s3_bios
after resume - screen is properly displayed

(In reply to Marty from comment #29)

Hi Marty,

I did a commit some new code into the master branch.
The current latest version as of now is Version 0.6.109.
The patch I uploaded so far is no longer valid, so you will not have to use it anymore.
The code is slightly different than the v1 patch, and I am hoping that it will perform better than that one when resuming.
The code behavior is a little different for the 24-bit FP interface situation (i.e., Your particular hardware.).
    Regarding the cursor not getting restored, it is a known issue, but so far, I have not found a good fix for it other than the following workarounds for now.

1) Always attach a VGA monitor when resuming
2) Follow the workaround latalante has figured out (i.e., This is called VGA BIOS rePOST on some desktop mainboard BIOS.)

I suspect the issue is intimately related to video accelerator since the hardware cursor and video accelerator have some shared registers.
So far, I have not touched the video accelerator code, but I am afraid I may have to eventually.
    Your particular model appears to have the issue of the VGA switching to monochrome mode after resuming from standby.
I know I am sure you still see color on your display, but when IBM VGA was developed in '80s, there still used to be a thing called monochrome mode, and in this mode, the CRTC (Cathode Ray Tube Controller; something people still used until early to mid 2000s, at least for desktop PCs) address switches to 03B5H rather than the normal 03D5H for color mode.
I have one model that exhibits this behavior (Sylvania g netbook), and when this happens, the register dump from via_regs_tool becomes mostly useless.
This is what I mean,

__________________________________________________________________
. . .
Graphic Controller register dump (IO Port address: 0x3ce): 
   3cf.00 = 0x00 (Set / Reset)
   3cf.01 = 0x00 (Enable Set / Reset)
   3cf.02 = 0x00 (Color Compare)
   3cf.03 = 0x00 (Data Rotate)
   3cf.04 = 0x00 (Read Map Select)
   3cf.05 = 0x00 (Mode)
   3cf.06 = 0x00 (Miscellaneous)
   3cf.07 = 0x00 (Color Don't Care)
   3cf.08 = 0x00 (Bit Mask)
   3cf.20 = 0x00 (Offset Register Control)
   3cf.21 = 0x00 (Offset Register A)
   3cf.22 = 0x00 (Offset Register B)

CRT controller register dump (IO Port address: 0x3d4): 
   3d5.00 = 0xff (Horizontal Total)
   3d5.01 = 0xff (Horizontal Display End)
   3d5.02 = 0xff (Start Horizontal Blank)
   3d5.03 = 0xff (End Horizontal Blank)
   3d5.04 = 0xff (Start Horizontal Retrace)
   3d5.05 = 0xff (End Horizontal Retrace)
   3d5.06 = 0xff (Vertical Total)
   3d5.07 = 0xff (Overflow)
   3d5.08 = 0xff (Preset Row Scan)
   3d5.09 = 0xff (Max Scan Line)
   3d5.0a = 0xff (Cursor Start)
   3d5.0b = 0xff (Cursor End)
. . .
__________________________________________________________________

The 0xff means "there is nothing connected here" in this particular situation.
It is essentially emulating "bus high impedance (Hi-Z)" or no connection situation for backward compatibility reasons.
This behavior is highly VIA Technologies VGA BIOS dependent, however, X Server appears to have a way to cope with the occurrence.
In order to then read the register you will have to read off 03B5H registers manually.
For example,

$ sudo ./via_regs_dump -r 3b5.96
$ sudo ./via_regs_dump -r 3b5.97
$ sudo ./via_regs_dump -r 3b5.99
$ sudo ./via_regs_dump -r 3b5.9b

Those registers are important in this case.


> Hi Kevin,
> 
> After resume the screen is still not correctly restored. But the behaviour
> is different from V0.6.107 without patch:
> 
> 1. The X-Server now at least allows to "recognize" the GUI (with correct
> size) and partly to read some things. But the whole screen is filled with
> big round colored artifacts. It looks very artistic! The mouse cursor seems
> to be invisible.
> 
> 2. If I switch to VT I now get just a black screen. (I had never this
> before.)
> 
> I am not sure if it has any value anymore. But I did reg-dumps after resume.
> Let me attach them again.
> 
> Regards,
> Marty

(In reply to latalante from comment #32)

Hi latalante,

I think what is going on is that you are forcing something known as "Video rePOST when resuming from ACPI S3 State."
Some desktop mainboards have this option, but rarely you see this option in laptops.


> All problems have disappeared under the addition to kernel -
> acpi_sleep=s3_bios
> 
> Now after standby resume works hardware cursor and Xv, it does everything I
> need.

(In reply to latalante from comment #25)

Hi latalante,

> It may not matter, but I get warnings when compiling (Xorg 1.19.3, gcc
> 6.3.1).
> 
> via_display.c: In function ‘iga1_crtc_commit’:
> via_display.c:3848:9: warning: ‘xf86_reload_cursors’ is deprecated
> [-Wdeprecated-declarations]
>          xf86_reload_cursors(crtc->scrn->pScreen);
>          ^~~~~~~~~~~~~~~~~~~
> In file included from via_driver.h:54:0,
>                  from via_display.c:32:
> /usr/include/xorg/xf86Crtc.h:991:37: note: declared here
>  static _X_INLINE _X_DEPRECATED void xf86_reload_cursors(ScreenPtr screen) {}
>                                      ^~~~~~~~~~~~~~~~~~~
> via_display.c: In function ‘iga2_crtc_commit’:
> via_display.c:4254:9: warning: ‘xf86_reload_cursors’ is deprecated
> [-Wdeprecated-declarations]
>          xf86_reload_cursors(crtc->scrn->pScreen);
>          ^~~~~~~~~~~~~~~~~~~
> In file included from via_driver.h:54:0,
>                  from via_display.c:32:
> /usr/include/xorg/xf86Crtc.h:991:37: note: declared here
>  static _X_INLINE _X_DEPRECATED void xf86_reload_cursors(ScreenPtr screen) {}
>                                      ^~~~~~~~~~~~~~~~~~~
>  

The latest version of X.Org Server I am still using it 1.18.4 or something similar to that (Xubuntu 16.04.2).
Since I am using what Canonical calls HWE (Hardware Enablement) version, I should eventually be on X.Org Server 1.19 eventually.
When I get to X.Org Server 1.19, I am sure I will encounter the issue.
My guess is there will likely be a fix for this down the road, but not until Xubuntu 16.04.3 is released.


> > 2) VT screen goes completely dark when entering it after resuming from
> > standby
> Not exactly, VT (Console: VGA 80x25) disappears after startup Xorg.
> 
> All in all current version it is the best possible configuration (loss of
> lost Xv after resuming).
> I also tried the KMS version (drm-openchrome), without success. Xorg did not
> want to run.
> "xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)"
> or
> "unable to map MMIO permission denied"
> Maybe it was related to kernel config (CONFIG_STRICT_DEVMEM,
> CONFIG_IO_STRICT_DEVMEM) or the xorg version was too new.

drm-openchrome is still very buggy, and I do not really have a schedule of when it will become mainlined.

(In reply to Kevin Brace from comment #36)
>
> Hi latalante,
> 
> I think what is going on is that you are forcing something known as "Video
> rePOST when resuming from ACPI S3 State."
> Some desktop mainboards have this option, but rarely you see this option in
> laptops.
> 

This notebook it's a terrible crap. Some time ago I fought with reboot and poweroff. This big change in the kernel caused them.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.6-rc1&id=277edbabf6fece057b14fb6db5e3a34e00f42f42
Since then, all new releases have been affected. The only effective, sensible solution I have found is - "processor.nocst=1".
Now the notebook turns off and more importantly works reboot. Because this kind of hack, it's not a solution -
for i in {s,u,b}; do echo $i > /proc/sysrq-trigger; done.

The VIA Rhine II card began to be rock-solid from the moment of turning off DHCP. And more, more...

(In reply to Kevin Brace from comment #35)

Hi Kevin,

No change with Version 0.6.109. Still the very colorful image after resume.
Are you interested in the 03B5H registers before and after resume? What exactly should I do?
By the way: I would completely understand if you give up solving that issue as my hardware seems to be a little special...

Regards,
Marty

> (In reply to Marty from comment #29)
> 
> Hi Marty,
> 
> I did a commit some new code into the master branch.
> The current latest version as of now is Version 0.6.109.
> The patch I uploaded so far is no longer valid, so you will not have to use
> it anymore.
> The code is slightly different than the v1 patch, and I am hoping that it
> will perform better than that one when resuming.
> The code behavior is a little different for the 24-bit FP interface
> situation (i.e., Your particular hardware.).
>     Regarding the cursor not getting restored, it is a known issue, but so
> far, I have not found a good fix for it other than the following workarounds
> for now.
> 
> 1) Always attach a VGA monitor when resuming
> 2) Follow the workaround latalante has figured out (i.e., This is called VGA
> BIOS rePOST on some desktop mainboard BIOS.)
> 
> I suspect the issue is intimately related to video accelerator since the
> hardware cursor and video accelerator have some shared registers.
> So far, I have not touched the video accelerator code, but I am afraid I may
> have to eventually.
>     Your particular model appears to have the issue of the VGA switching to
> monochrome mode after resuming from standby.
> I know I am sure you still see color on your display, but when IBM VGA was
> developed in '80s, there still used to be a thing called monochrome mode,
> and in this mode, the CRTC (Cathode Ray Tube Controller; something people
> still used until early to mid 2000s, at least for desktop PCs) address
> switches to 03B5H rather than the normal 03D5H for color mode.
> I have one model that exhibits this behavior (Sylvania g netbook), and when
> this happens, the register dump from via_regs_tool becomes mostly useless.
> This is what I mean,
> 
> __________________________________________________________________
> . . .
> Graphic Controller register dump (IO Port address: 0x3ce): 
>    3cf.00 = 0x00 (Set / Reset)
>    3cf.01 = 0x00 (Enable Set / Reset)
>    3cf.02 = 0x00 (Color Compare)
>    3cf.03 = 0x00 (Data Rotate)
>    3cf.04 = 0x00 (Read Map Select)
>    3cf.05 = 0x00 (Mode)
>    3cf.06 = 0x00 (Miscellaneous)
>    3cf.07 = 0x00 (Color Don't Care)
>    3cf.08 = 0x00 (Bit Mask)
>    3cf.20 = 0x00 (Offset Register Control)
>    3cf.21 = 0x00 (Offset Register A)
>    3cf.22 = 0x00 (Offset Register B)
> 
> CRT controller register dump (IO Port address: 0x3d4): 
>    3d5.00 = 0xff (Horizontal Total)
>    3d5.01 = 0xff (Horizontal Display End)
>    3d5.02 = 0xff (Start Horizontal Blank)
>    3d5.03 = 0xff (End Horizontal Blank)
>    3d5.04 = 0xff (Start Horizontal Retrace)
>    3d5.05 = 0xff (End Horizontal Retrace)
>    3d5.06 = 0xff (Vertical Total)
>    3d5.07 = 0xff (Overflow)
>    3d5.08 = 0xff (Preset Row Scan)
>    3d5.09 = 0xff (Max Scan Line)
>    3d5.0a = 0xff (Cursor Start)
>    3d5.0b = 0xff (Cursor End)
> . . .
> __________________________________________________________________
> 
> The 0xff means "there is nothing connected here" in this particular
> situation.
> It is essentially emulating "bus high impedance (Hi-Z)" or no connection
> situation for backward compatibility reasons.
> This behavior is highly VIA Technologies VGA BIOS dependent, however, X
> Server appears to have a way to cope with the occurrence.
> In order to then read the register you will have to read off 03B5H registers
> manually.
> For example,
> 
> $ sudo ./via_regs_dump -r 3b5.96
> $ sudo ./via_regs_dump -r 3b5.97
> $ sudo ./via_regs_dump -r 3b5.99
> $ sudo ./via_regs_dump -r 3b5.9b
> 
> Those registers are important in this case.
> 
> 
> > Hi Kevin,
> > 
> > After resume the screen is still not correctly restored. But the behaviour
> > is different from V0.6.107 without patch:
> > 
> > 1. The X-Server now at least allows to "recognize" the GUI (with correct
> > size) and partly to read some things. But the whole screen is filled with
> > big round colored artifacts. It looks very artistic! The mouse cursor seems
> > to be invisible.
> > 
> > 2. If I switch to VT I now get just a black screen. (I had never this
> > before.)
> > 
> > I am not sure if it has any value anymore. But I did reg-dumps after resume.
> > Let me attach them again.
> > 
> > Regards,
> > Marty

(In reply to Marty from comment #39)

Hi Marty,

Regarding the CRTC registers 96H, 97H, 99H, and 9BH, you can redirect to a file.

sudo ./via_regs_dump -r 3b5.96 > CR96_After_Resume.txt

I also like to see CRTC 91H as well.
I only need 3B5H after resume since it is mapped to 3D5H during normal operation.
    I have been busy modernizing FP code the past week or so, and I am doing this for the hopes of making it easier to maintain the FP code moving forward.
I also hope to reuse some of the code with the next generation OpenChrome DRM (drm-openchrome), although FP code might be harder to do this.
In general, it is much harder to support FP than other display types, and VIA made it harder by never releasing hardware register programming guides for many devices including VN896 chipset.
I am not giving up regarding this bug, but since I do not own a similar device to the one you have (i.e., 2 chip PCIe chipset with 18- or 24-bit FP interface), it is hard to remotely debug this issue.
I am staying on top of this issue, but obviously not 100% of my available development time (Right now about 30%.).
I have upped the version to 0.6.112.
I made some changes to the FP power on code which is a fairly risky change to the code, but I had to do this at some point.


> Hi Kevin,
> 
> No change with Version 0.6.109. Still the very colorful image after resume.
> Are you interested in the 03B5H registers before and after resume? What
> exactly should I do?
> By the way: I would completely understand if you give up solving that issue
> as my hardware seems to be a little special...
> 
> Regards,
> Marty

Hi Kevin,

This time without attachment:
BEFORE resume ALL 4 registers you asked for are 0xff.

AFTER resume:
CR96=0x00
CR97=0x10
CR99=0x18
CR9B=0x10

This was tested still with version 0.6.109.

Regards,
Marty

just tested: the four registers have the same values with V0.6.112 as with V0.6.109

Regards,
Marty

Hi Marty,

Sorry for not responding for a while, but I am in the process of performing a major update to how the display devices are detected.
In this process, I will rewriting the FP related mode setting code.
It will take about 2 weeks before the new code is pushed into the Git repository.

Hi Marty,

I have been working on a major overhaul of the display detection code for the past 1 1/2 months.
Please try out the latest Version 0.6.133.

Hi Kevin,

Congratulations, this brought some progress:

1. Switching to other tty consoles (e.g. Ctrl-Alt-F1) works now, but only when I enable the graphical terminal in /etc/default/grub.
That means I have to comment the line "GRUB_TERMINAL=console". In the original Ubuntu 14.04 driver it was vice-versa: Only be uncommenting this line the switch to other consoles worked.

2. Resuming from standby works now! There is one little hitch: After resume the lock screen appears correctly and I can log-in. But if I then lock the screen again, it stays black. But I can blindly log-in and the normal screen restores correctly.

3. The color depth seems to be lower than with the original driver. I cannot say what color depth is used now but I can see it from color steps in the background image.

Best regards,
Marty

Hi Marty,

(In reply to Marty from comment #45)
> Hi Kevin,
> 
> Congratulations, this brought some progress:
> 

Yeah, I did work on the major code overhaul (i.e., new display device detection and initialization method) partially to fix the problem you encountered, but that being said, I was planning to do this for a while.
I did not make any commits between April 28th, 2017 to May 18th, 2017 because I was working on the updated code, and this is a relatively long period of not committing any code, at least in my standards.
The new code now probes for the attached display devices that can be identified by some means (i.e., I2C bus scan of the vendor ID and device ID) before assigning other devices that are more or less always available (i.e., VGA).
The code also leaves hints about which display channel the display is attached to, and this information ultimately comes from the probing.
Furthermore, I2C bus is also assigned based on probing results, and because of this, the code has regained the capacity to obtain EDID for FP via I2C bus for FP screen resolution determination (This feature was disabled in Version 0.6.).


> 1. Switching to other tty consoles (e.g. Ctrl-Alt-F1) works now, but only
> when I enable the graphical terminal in /etc/default/grub.
> That means I have to comment the line "GRUB_TERMINAL=console". In the
> original Ubuntu 14.04 driver it was vice-versa: Only be uncommenting this
> line the switch to other consoles worked.
> 

I think the VT implementation when used in conjunction with a non-KMS (Kernel Mode Setting) DDX device driver is a disaster, and it is my opinion that this will never really be fixed.
All I have been trying to do with the OpenChrome DDX is not to interfere or sabotage VT switch, and based on how the VT switch is implemented, what we have right now is probably as good as it will get.
The VT behavior appears highly dependent on the VGA BIOS (VBE or VESA BIOS Extension portion of VGA BIOS) and / or GRUB version, and it also differs wildly from platform to platform.
Furthermore, the behavior can be quite different between two different computers with the same chipset (HP 2133 vs. MSI VR321; both have VN896 chipset).
Other than not trying to sabotage the VT switch, there is little DDX can do, at least with the current antiquated UMS (User Mode Setting) DDX code.


> 2. Resuming from standby works now! There is one little hitch: After resume
> the lock screen appears correctly and I can log-in. But if I then lock the
> screen again, it stays black. But I can blindly log-in and the normal screen
> restores correctly.
> 

This may not really be an OpenChrome issue.
I do not really use Lubuntu 14.04, and the reason for not really wanting to use Lubuntu 14.04 is that I had many issues with how the power management control is implemented on Lubuntu 14.04.
For example, I cannot alter the power button behavior on Lubuntu 14.04.
The thing about Linux distributions is that the developers will NEVER fix anything after the code is released.
All of those .1, .2 releases (i.e., Lubuntu 14.04.1, 14.04.2, etc.) really do not fix anything other than security issues.
Many substantial usability issues might get fixed if you move to a newer version or maybe not.
For this reason, I use Xubuntu 14.04 for the drm-openchrome development, and power management control works for the most part.
That being said, I had to disable lightdm password prompt since it appears to cause several issues when I test drm-openchrome code.
 

> 3. The color depth seems to be lower than with the original driver. I cannot
> say what color depth is used now but I can see it from color steps in the
> background image.
> 
> Best regards,
> Marty

You may have to upload a screen shot of the screen if it helps to see what is going on, but it is possible that gamma correction is not being disabled properly (or the color palette is getting messed up) after resuming.
It is also possible that FP port signal adjustment parameter is off after resume.
Marty, you may have to do previously discussed the dump of the registers again.

Hi Kevin,

No problem regarding no.1 and 2 of my list because I have workarounds available (setting in /etc/default/grub and "blind login").

But the third one (color depth) is little annoying because the "reduced color depth" is always there, meaning also directly after a fresh reboot, not only after resume. I tested that with that web-page (using Firefox):

http://www.lagom.nl/lcd-test/gradient.php

With the original Openchrome driver the gradient is completely smooth. With Version 0.6.133 I clearly see two rows of 64 Bands each. Whatever that means...

This page
http://www.lagom.nl/lcd-test/display_settings.php
says I would have a color depth of 24 bit. I get the same result (24 bit) with:
xwininfo -root | grep Depth

So I have no clue where the color banding comes from.

Regarding VIA registers, I will be happy to provide you some values again. What exactly are you interested in? All registers? Before and after resume? Also before and after VT switching?

Best regards,
Marty

(In reply to Marty from comment #47)

Hi Marty,

> Hi Kevin,
> 
> No problem regarding no.1 and 2 of my list because I have workarounds
> available (setting in /etc/default/grub and "blind login").
> 

I am not 100% sure problem 1 and 2 are truly OpenChrome DDX related.
At this point, OpenChrome DDX is probably the only non-KMS DDX that tries to even handle STR (Suspend to RAM or ACPI S3 State; the particular type of standby mode we are dealing with) resume.


> But the third one (color depth) is little annoying because the "reduced
> color depth" is always there, meaning also directly after a fresh reboot,
> not only after resume. I tested that with that web-page (using Firefox):
> 
> http://www.lagom.nl/lcd-test/gradient.php
> 
> With the original Openchrome driver the gradient is completely smooth. With
> Version 0.6.133 I clearly see two rows of 64 Bands each. Whatever that
> means...
> 

I think this might be code changes I may have made while ago related to gamma correction.
Does this problem show up prior to standby?
Personally, I will consider this a separate bug, and you may want to file a new bug report.


> This page
> http://www.lagom.nl/lcd-test/display_settings.php
> says I would have a color depth of 24 bit. I get the same result (24 bit)
> with:
> xwininfo -root | grep Depth
> 
> So I have no clue where the color banding comes from.
> 
> Regarding VIA registers, I will be happy to provide you some values again.
> What exactly are you interested in? All registers? Before and after resume?
> Also before and after VT switching?
> 
> Best regards,
> Marty

The Xorg.0.log after the standby resume will be helpful.
Also, "via_regs_dump -d" after the standby resume is important.
Due to the color / monochrome register mapping issue that shows up, you may have to resort to obtaining a few key register values one at a time.

Created attachment 131903 [details]
xorg.0.log after standby/resume with V0.6.133

Created attachment 131904 [details]
via_regs_dump after standby/resume Version 0.6.133

Hi Kevin,

I have attached Xorg.0.log and via_regs_dump as requested.

In my opinion you may consider this bug and also 100678 as "resolved".
Regarding the color bands I will file a new bug.

Best regards,
Martin

Marty, can I close this bug report?
The upcoming OpenChrome DDX Version 0.7 will officially contain the fixes.

Hi Kevin,

Sure. Just closed it. Please check if I changed the status correctly.

Best regards,
Marty

Marty, the code you help develop will be incorporated into the upcoming OpenChrome DDX Version 0.7 and the future release of OpenChrome DRM.


(In reply to Marty from comment #52)
> Hi Kevin,
> 
> Sure. Just closed it. Please check if I changed the status correctly.
> 
> Best regards,
> Marty