Comment # 97 on bug 1112963 from Thomas Zimmermann

(In reply to Edward Van Every from comment #94)
> I have not tested for the screen corruption.  Unfortunately it can not be
> generated on demand.  Its a matter of just working in the environment long
> enough to see if it occurs.  It can take a couple of hours or it can take a
> couple of days.  And, of course, there is no way to ensure it has been
> tested "long enough" if we can't generate the problem on demand.
> 
> ASPEED believes it has something to do with switching resolutions (although
> not by user request).  It just happens all at once for no apparent reason
> during some otherwise innocuous operation (like opening an xterm or
> something).  ASPEED has even given me a new driver to integrate in the
> kernel and test, but I have had to fallback to getting more productive
> things done and not have any time to test it.
> 
> Ultimately, the screen corruption does appear to be related somewhat to the
> WM and DM in use.  In our production image we are forced to switch away from
> sddm/plasma as we can't run remote xclients (on Windows (Xming) or other
> Suse platforms) due to xdmcp not working properly.  We fought this issue
> long and hard both with Novell and the Xming developer and never did get it
> resolved. Lots of finger pointing and blaming of changes to gnome.  Back
> then it was issues when running gdm/gnome and right now I can confirm remote
> X11 issues with sddm/plasma.  ANYWAY, lightdm/lxde continues to meet our
> user interface requirements and seems to work fine with remote X11 clients
> so we use that configuration.  Once we switched away from sddm/plasma to
> lightdm/lxde we have not seen the video corruption issue appear again.
> 
> This is not to say there is a problem with sddm/plasma, just that particular
> environment may do things in a manner which precipitates the issue...
> 
> Although I haven't had time to test the updated driver offered by ASPEED, I
> would happily put you in touch with the developer if you want to "refresh"
> the driver in the kernel...  Note that this is newer than the latest driver
> posted on their website.  I believe it is a beta driver built specifically
> to try and resolve this issue.  As they sent it to me in a pwd protected
> archive I will not pass it on, but I expect they will work directly with you
> if desired.  Please let me know!

I don't think I can easily help you with this, as I don't even have a manual
for the AST hardware. It sounds like the problem could be anywhere. If you
like, we can use this bug report to keep track of the problem.

(In reply to Edward Van Every from comment #95)
> ...also, can someone please be sure to post a note to this thread when the
> fix to the kernel goes live?  Thanks!

No problem.