http://bugs.freedesktop.org/show_bug.cgi?id=13983 Ildar Muyukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ildar@users.sourceforge.net --- Comment #1 from Ildar Muyukov 2008-01-17 22:05:21 PST --- This must not be radeonhd-related. Can you confirm, that making init 3 and suspending (i.e. suspending without X) would give same or different results? -- 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

http://bugs.freedesktop.org/show_bug.cgi?id=13983 --- Comment #3 from Chip Salzenberg 2008-02-04 14:48:50 PST --- This is *definitely* a bug. Else why does fglrx handle it? 'cause it does. (Well, except for the last release, which freezes. Bleh. But for all the previous releases, suspending and resuming does not leave the text vts unusable. Perhaps my original report was unclear. I don't demand the content of the text consoles to survive suspend/resume. But it's not acceptable - i.e. it *is* a bug - if after suspend/resume any attempt to go to the text consoles results in blank screens without any video, any cursor, any -anything-. -- 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

http://bugs.freedesktop.org/show_bug.cgi?id=13983 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|eich@pdx.freedesktop.org |chip@pobox.com Severity|normal |enhancement --- Comment #5 from Egbert Eich 2008-03-31 08:45:56 PST --- I don't agree that this is a bug as the Xserver has nothing to do with setting up the console. The fglrx driver may handle this situation by not saving the mode on every switch vt->X. This is IHMO wrong as changes made to a console mode should be reflected in X. I'd need to think about it some more. It would help however if the last commenter would answer the question in comment #3: what happens when the machine is suspended in vt text console? (I assume 'suspend' refers to 'suspend to ram' here). Marking as an enhancement for now and reassigning to the last commenter. -- 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

http://bugs.freedesktop.org/show_bug.cgi?id=13983 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|chip@pobox.com |lverhaegen@suse.de --- Comment #7 from Egbert Eich 2008-03-31 15:10:59 PST --- (In reply to comment #6)

When suspending in text console mode, the text console is restored. Of course. How can you even ask this? It's been the behavior of Linux ever since Linux

How can I ask this? Because sometimes the text console is not restored when suspend to RAM is done. Can't you imagine that this gets asked for a reason?

first supported APM! And it has absolutely *NOTHING* to do with any driver.

APM? Your system is still using APM? APM attempts to restore the video mode itself.

BTW - you're assigning the bug to me? I'm just the reporter, I know nothing about the internals of the driver. This is one screwed-up development process.

Because bugzilla was updated and the NEEDINFO state was removed. So this has proven to be the only reliable way to get feedback from the reporter. Look at comment #4. How long has this been sitting there before there was any feedback? -- 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

http://bugs.freedesktop.org/show_bug.cgi?id=13983 Luc Verhaegen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |libv@skynet.be AssignedTo|lverhaegen@suse.de |chip@pobox.com --- Comment #9 from Luc Verhaegen 2008-04-03 09:30:57 PST --- (In reply to comment #6)

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