I did mention in an earlier post that I will discuss in more detail about r128 DDX’s present standby resume functionality. In general, when it comes to dealing with standby resume, it puts the developer in a tough spot if the OS completely locks up after standby resume. In my case, I am sort of in this situation presently with the following computer.
- AMD Sempron 3200+ (Socket 939)
- ASRock 939DUAL-SATA2
- 1 GB DDR400 DDR SDRAM (256 MB x 4)
- ATI Technologies RAGE 128 Pro 32 MB (I think it is Xpert 2000 Pro.)
If you are into PC mainboards, perhaps ASRock 939DUAL-SATA2 mainboard was probably one of the most exotic mainboard to ever exist. It comes with native Gen 1 PCIe x16 and AGP 8X slots (Note: A real AGP slot, not those “fake” AGP slots hooking up AGP cards to the South Bridge’s PCI bus.) It even comes with a AM2CPU upgrade card slot. What happens is that if I put the computer into standby and then resume it, the keyboard connected to it will respond for a few seconds (i.e., Num Lock or Caps Lock toggles), but it will soon freeze completely.
I also have another computer to mainly to work with RAGE 128.
- Intel Celeron 2.0A GHz
- SOYO Computer P4S Dragon Ultra
- 1 GB DDR266 DDR SDRAM (512 MB x 2)
- ATI Technologies RAGE 128 Pro 32 MB (I think it is Xpert 2000.)
For this board, it comes with a Universal AGP Pro slot, hence, I can use it with RAGE 128 (RAGE 128 does not support AGP 1.5 V signaling). Intel did not make chipsets that supported AGP 3.3 V signaling cards for their Pentium 4 chipsets (i.e., Intel 845 and 850), but SiS and VIA Technologies did. Furthermore, this mainboard supports ACPI S3 State, and it is actually pretty rare to find a mainboard that has a Universal AGP slot that happens to support ACPI S3 State. Anyway, with this mainboard, when I resume the computer from standby, the computer beeps and keyboard does not respond at all. Nothing is displayed on the screen.
Going back to the ASRock 939DUAL-SATA2 mainboard based computer, when it comes out of standby, if I frantically try to transition to VT (Virtual Terminal) and back to XFCE desktop, it is able to display “something.” The “something” here is a totally distorted display. Based on my experience of fixing most OpenChrome standby resume issues, I will assume that r128 DDX is not reinitializing all necessary registers for a proper operation.
Typically in this type of a situation, comparing the register values for before and after standby allows me to figure out which registers are causing display issue. But before I can do that, I will need to figure out how to regain control of the computer after I resume from standby.
It would be great if you could have a look into coreboot for such AGP based GPUs development and usage. You can then analyse S3 perfectly and debug as deep as you like.
There are many coreboot supported mainboards with AGP. You could maybe also take a look into porting some of your hardware to coreboot to get S3 support. This probably wont be that hard so i think it would be worth a try.