On Thu, 2008-03-13 at 00:06 +0800, Thomas Renninger wrote: > On Wed, 2008-03-12 at 10:53 +0800, Zhang, Rui wrote: > > On Wed, 2008-03-12 at 09:21 +0800, Thomas Renninger wrote: > > > > > > On Wed, 2008-03-12 at 01:21 +0100, Thomas Renninger wrote: > > > > On Fri, 2008-01-25 at 14:47 +0800, Zhang Rui wrote: > > > > > From: Zhang Rui <rui.zhang@xxxxxxxxx> > > > > > > > > > > Display switching via ACPI control methods are known to work > on > > > > > none platform AFAIK. > > > > > And graphics people want to control the display switching all > by > > > > > themselves. > > > > > Prevent ACPI from handling display switch hotkey events in > this > > > > > patch. > > > > > > > > I expect this one has to be reverted. > > > > I can double check tomorrow, but I am pretty sure I have a > Compaq > > > > and also saw more and I expect there are a lot more that work > pretty > > > > fine with Display Output Switching (_DOS) set to be handled by > BIOS and > > > > not graphics driver. > > > > > > > > As said, I can double check, but this would be a regression. > > > > > > > > IMO the logic should be: > > > > - Let the BIOS handle the switching (also works without X) > > > > - If a graphics driver gets active which can do the switching, > it > > > > can take over control by: > > > > echo 0 >/proc/acpi/video/*/DOS > > > > > > > > > > I mixed this up with the default value for _DOS: > > > git commit a21101c46ca5b4320e31408853cdcbf7cb1ce4ed > > > > > > Again, IMO the logic should be: > > > - Let the BIOS handle the switching (also works without X) > > > - If a graphics driver gets active which can do the switching, it > can > > > take over control by: > > > echo 0 >/proc/acpi/video/*/DOS > > That's what I thought at the beginning, > > and the bug > > http://bugzilla.kernel.org/show_bug.cgi?id=6001 > > suggested me to set _DOS to 0 by default. > Yep. I think _DOS set to 0 by default is wrong and in the bug machines > were stated where this causes problems now. > > > > Also the bug which above commit claims to fix has an interesting > > > add-on > > > comment (after the bug got closed): > > > ---------------- > > > My HP 6710B also crashes when DOS=0, DOS=1,2 or 3 works just fine > > > though. > > which version of kernel are you using? > > I get this problem before, but it can not be reproduced in the > kernel > > later than 2.6.23. > > > > > This has an GM965 intel chipset. What does the ACPI spec say about > values > > > other then 0 or 1 ? > > nothing interesting. > > And many laptops don't follow the ACPI spec on this. :( > > > > It seems that the change that was done from 1 to 0 causes some > quit bad > > > regressions on some laptops, while fixing others. Otoh all > reporters > > > say that > > > DOS=2 works.. > > > ---------------- > > well, DOS=2 doesn't work either... > > there is no solution that can work for all laptops. > Above was not from myself, but copied out from the bug. > The guy(s) complained that DOS=0 now breaks their machines... > I try to find some time to look at this a bit deeper and will then > comment in the bug (can take some time...). > IMO recent HPs can/should be taken as a reference as they tend to > stick > to the ACPI spec closely. > As said, it was late and I mixed up patches, the patch to switch _DOS > default value to 0 was already in 2.6.24? Yes. > I don't know now how much was tried already. > A) To switch DOS to 0 when e.g. intel graphics driver gets active > (should be done by the graphics driver package or if X is started if > the > driver is aware of the hotkey and can do the switching). > B) Otherwise (e.g. if framebuffer or graphics driver which do not > switch > the display) it should stay to be BIOS handled. > This is the correct way IMO this should get handled. Well, I agree. If the patch causes regressions, we should revert it. And I saw several bugs on this. thanks, rui > Puhh, this needs a lot testing (different graphics drivers, different > machines,...) and implementation to switch to DOS=0 in graphics > drivers... -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
