<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Garbled graphics when resuming from standby" href="https://bugs.freedesktop.org/show_bug.cgi?id=100679#c39">Comment # 39</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Garbled graphics when resuming from standby" href="https://bugs.freedesktop.org/show_bug.cgi?id=100679">bug 100679</a> from <a class="email" href="mailto:martin651@gmx.de" title="Marty <martin651@gmx.de>"> Marty</a> <pre>(In reply to Kevin Brace from <a href="show_bug.cgi?id=100679#c35">comment #35</a>) 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 <a href="show_bug.cgi?id=100679#c29">comment #29</a>) > > 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</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>