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? 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. Puhh, this needs a lot testing (different graphics drivers, different machines,...) and implementation to switch to DOS=0 in graphics drivers... Thanks, Thomas -- 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
