Mailinglist Archive: radeonhd (353 mails)
| < Previous | Next > |
[radeonhd] [Bug 13983] radeonhd: after Thinkpad suspend, text consoles are all black
- From: bugzilla-daemon@xxxxxxxxxxxxxxx
- Date: Thu, 3 Apr 2008 09:30:58 -0700 (PDT)
- Message-id: <20080403163058.2BAE01300CD@xxxxxxxxxxxxxxxxxxxxxxxx>
http://bugs.freedesktop.org/show_bug.cgi?id=13983
Luc Verhaegen <libv@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |libv@xxxxxxxxx
AssignedTo|lverhaegen@xxxxxxx |chip@xxxxxxxxx
--- Comment #9 from Luc Verhaegen <libv@xxxxxxxxx> 2008-04-03 09:30:57 PST ---
(In reply to comment #6)
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@xxxxxxxxxxx
http://lists.x.org/mailman/listinfo/xorg-team
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
Luc Verhaegen <libv@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |libv@xxxxxxxxx
AssignedTo|lverhaegen@xxxxxxx |chip@xxxxxxxxx
--- Comment #9 from Luc Verhaegen <libv@xxxxxxxxx> 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@xxxxxxxxxxx
http://lists.x.org/mailman/listinfo/xorg-team
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |