Bug reported by Chip Salzenberg on the Debian BTS a couple days ago, applies to 1.1.0 and current git. If an X session with the radeonhd driver is running on my Thinkpad, and I suspend it (with acpitool), then on resume, all text (non-X) vts are all black. Nothing seems to bring them back. The config and log are both available at the URL above.
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?
With text you are referring to text consoles, ie vt's? In this case there is very little we can do here. The good news: the chip seems to be initialized sufficiently and the driver does a sufficient amount of setup to make X work. The bad news: there is no such thing for the text console, yet. This the text console may remain unusable after a resume while X is still running. If this is what you are seeing I'm afraid we can only close this with an 'NOTABUG' or 'NOTOURBUG'.
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-.
What happens when you switch to a text vt before suspending?
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.
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 first supported APM! And it has absolutely *NOTHING* to do with any driver. 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. No wonder this driver has such problems. PS: I do happen to know something about open source development, so don't bother with "what do you know?" flamage.
(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?
I'm not using APM. Neither, at the moment, am I using radeonhd, so further reproduction and testing will have to wait until I'm not depending on the system for proper function. PS: Assigning me the bug did not affect my feedback. I just missed the earlier mail.
(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.
No further feedback from reported, so closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.