On Tue, 2003-12-02 at 23:13, Soeren Sonnenburg wrote: > On Mon, 2003-12-01 at 23:38, Benjamin Herrenschmidt wrote: > > > > Do you have X running ? Same problem if not ? Does the screen come back > > > > up at all or not ? > > > > > > I've been doing some more tests and the results are random. I tried three > > > ways of suspending the machine: > > > > > > 1.- Closing the lid (pmud). > > > 2.- Issuing the snooze command (pmud-utils). > > > 3.- Some code I've been playing with some time ago [See below]. > > > > You didn't reply about running X or not. Can you try in pure console > > without X beeing ever started ? Also, which radeonfb driver did you > > use ? My 2.6 tree contains actually 2 of them. (Make sure you are > > using my tree btw, mainstream 2.6 doesn't contain up to date sleep > > support yet). > > > > Regarding the specs... well... we had _some_ from MkLinux or earlier > > Darwin sources (though Apple quickly un-opensourced the PMU driver), > > from the Open Firmware forth code, and for things related to sleep, > > a whole bunch of reverse engineering & trial & error... > > > > For the code putting the radeon chips to sleep & waking them up, you > > have to thank ATI for providing it. > > > > Ben. > > Hmmhh I remember I also had problems with sleep in a certain kernel > config. but I don't remember the settings... > However as the new radeonfb is still pretty slow _here_ I wonder how > difficult it would be to fix the compile errors with the old driver, > such that I can try reproducing this 'sluggishness behaviour' ...
What do you mean ? There is no way the new radeonfb would be slower than the old one in 2.6. If you run in 8bpp, you won't get any better without acceleration and the 2.6 radeonfb isn't accelerated (neither the old one nor the new one). 2.4 was. I don't have time to look into the accel code for 2.6 for now. Regarding the fixes, just pick the 2 missing #define's in a tree without my changes ;) I'll fix that asap in my tree. Ben.
