For some time, I have known that when OpenChrome DDX UMS (User Mode Setting) code goes through one or more standby resume (i.e., recovering from an ACPI S3 State), the computer will more or less likely completely lose the control of the VT (Virtual Terminal) screen.  It is highly system dependent and some models do not exhibit this behavior.  However, models that do not exhibit this behavior is fairly small.  The real answer as to why I could not deal with this was due to the lack of an idea on how to solve the issue.

Probably about several months ago, I started to think that if the DDX saved all display related registers during DDX initialization (i.e., X Server initialization), then I figured it should be able to restore perfectly all the time, including even after going through one standby resume cycle. So I made this commit in November that fixed the issue for some models (i.e., ones without an FP).

Two days ago, I got together with one actual OpenChrome user and this person pointed out the VT screen issue since the November commit.  After noticing that one particular register (CRA2 or 3X5.A2) was different between the code before the November commit and after, I was able to come up with the fix quickly.  VT now works fine before and after standby resume.  We both used HP 2133 Mini-Note for the validation (different OSes).

The problem I saw here was the flaws in the X Server RandR era callback functions.  It has no serious mechanism to handle a situation like this, and I had to come up with a “scheme” (or you can call this a “hack”) to deal with the matter.  I am probably the last person on Earth who will ever deal with X Server DDX UMS, but if there is going to be someone else who will deal with this, saving all the VGA registers during initialization “scheme” appears to do the trick for restoring VT.