http://bugzilla.kernel.org/show_bug.cgi?id=6001
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED],
| |[EMAIL PROTECTED]
------- Comment #33 from [EMAIL PROTECTED] 2008-03-14 08:47 -------
The switch from DOS=1 (demanded by ACPI spec, if above comments are correct) to
DOS=0 caused regressions (on 855 and 965 chipsetst).
The regressions are hangs as described in comment #25 on 855GM and GM965
(comment #32). But also non-working display switching on others.
We possibly like to switch back to DOS=1 (should also go to 2.6.24.X then to
stay consistent, which is a bit dangereous but IMO still better than to have
one kernel that behave in an other way than previous and following ones).
I gave this a try on a Compaq 6715 with an ATI card.
On console:
DOS=0 -> nothing happens
DOS=1 -> Display switching works fine
DOS=2 -> nothing happens
DOS=3 -> Display switching works fine
With X-server started(binary,fglrx):
DOS=[0-4] -> nothing happens
With X-server started(OpenSource,readonhd):
DOS=0 -> nothing happens
DOS=1 -> freeze
DOS=2 -> nothing happens
DOS=3 -> freeze
With X-server started(OpenSource,framebuffer):
DOS=0 -> nothing happens
DOS=1 -> freeze
DOS=2 -> nothing happens
DOS=3 -> freeze
While X-server was started and switched back to console, still the first
(console) is valid (DOS=0,2 does nothing, but DOS=1,3 can switch the display,
only tested 0 and 1...)
The display switch key is not exported via acpi event, but via normal key
event, but it is not know yet.
Hmm, while switching display on console is really cool..., I doubt it justifies
possible freezes when running on X-server or does it make sense to propagate to
the X-people or distributions that they add this to their X-startup script:
#!/bin/bash
for x in /proc/acpi/video/*/DOS do
echo 0 >$x
done
Advantage:
- Then we would stay compatible with the spec.
- Display switching would work without X.
Disadvantage:
- If zeroing is forgotten when X is started machine freezes when pushing
the key...
Hmm or could the freezes of framebuffer and radeonhd driver possibly be solved,
fglrx also works... I expect the freezes more or less come from SMM code
popping in, confusing the driver from the back, not much one can do about?
Comments?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
