While the OpenChrome DDX code has not received much attention lately, I put in two fixes into the upstream repository.

The first fix changes the way the VGA registers are saved.  Now the VGA registers are saved during DDX initialization rather than when DDX enters GUI mode.  This change appears to improve the display condition when the user switches to VT (Virtual Terminal) screen after going through one or more standby resume events.  Previously, VT screen will go completely blank in most computers if the user goes through one or more standby resume events.  The only catch right now is that the code is still not perfect, and in some computers, the VT screen does not get restored correctly.

The second fix is meant for standby resume to work correctly on VIA Embedded EPIA-M830 mainboard.  The code fix for OpenChrome DRM happened back in July, but due to my own lack of interest, I did not develop the fix until recently.

It will be nice if I can fix this bug soon, but I do not have the exact equipment for testing purposes.  The person who reported the bug has not responded so far.

I was supposed to post this message back in October 2018, but I forgot to do it.  Anyway, I released xf86-video-r128 Version 6.12 to fix two urgent build failures reported by users.  Here is the official announcement.

https://lists.x.org/archives/xorg-announce/2018-October/002926.html

I did not state in the official announcement, but there is practically no change in the functionality of the DDX device driver.  All the rendering issues present with the current r128 DDX EXA code (i.e., occasional artifacts and sluggish 2D rendering performance) are still there.  The only thing I noticed about the artifact bug is that if I allocate excess amount of storage dedicated to EXA off screen memory, the artifact bug does not seem to happen.

I have not experimented with it for almost 2 months, but I still have not found the registers I need to restore when resuming from standby in order to prevent system lockup.  I am assuming that AGP related PLL not getting restored correctly is causing the system lockup, but so far, that has not really fixed the issue.