http://bugs.freedesktop.org/show_bug.cgi?id=13983
Luc Verhaegen
When suspending in text console mode, the text console is restored. Of course.
... And it has absolutely *NOTHING* to do with any driver.
Chip, This seems to be exactly why we usually get switched to VT before going into suspend. All X drivers know is save/restore. There are no hooks for "we're going into suspend now" or "please fix-up some mode you didn't set up in the first place as we just had a suspend". Our driver usually does a pretty good job with save/restore, it also clearly does a very good job setting a full X mode on hardware that just came out of suspend. There are not many drivers which are doing this as well. What our driver doesn't do at all, is magically restore that VT to a state that it wasn't in before. How could it do this anyway? Would it be possible to verify whether the VT really restores out of a suspend/resume cycle, without having run X at all? Can you then also verify that X is being switched away before actually going into suspend? About "fglrx" doing this correctly... Whatever fglrx does is not our business, and even if it was, we have no real way of finding out what exactly it is doing and what the reasoning behind this is. It is a binary only driver. Feel free to keep on using this binary driver if you really feel that we, and our very open driver development model, are at fault here. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ xorg-team mailing list xorg-team@lists.x.org http://lists.x.org/mailman/listinfo/xorg-team -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org