On Fri, 2009-08-21 at 18:00 +0800, Stefan Bader wrote: > Zhang Rui wrote: > > On Thu, 2009-08-20 at 17:14 +0800, Stefan Bader wrote: > >> Hardware: Acer 6920G (from a bug report) > >> > >> Another case of a broken BIOS. In this case there are several definitions for > >> video bus devices but only one has _DOS and _DOD defined. All other definitions > >> only have _DOD. > > > > I have seen such kind of BIOS too. > > > >> In the past (2.6.27) _ADR was not evaluated to make sure of using a present > >> video device, but with that bug brightness could be changed. > >> > >> Now the video bus having _DOS and _DOD is detected as not being present. The > >> other definitions are not considered because they are lacking the _DOS method. > >> Using the attached patch, would cause the detection code to consider the other > >> definitions and has been tested to enable backlight control. > >> > > > >> Would this be an acceptable approach? > > > > I think so. I generated a similar patch before, but didn't sent it out > > for some reason. > > My suggestion is that we should also print out a warning message if _DOS > > is missed, what do you think? > > Some indication about the problem can't hurt. Probably not in > acpi_is_video_device as that would trigger for even unused devices. > So I added a warning to acpi_video_bus_check for the case when _DOS is missing. how about using printk(KERN_WARNING FW_BUG "blabla")? thanks, rui > The case of _DOS being present but _DOD not might also be worth a warning but > (though the check in acpi_is_video_device prevented this) would have been > accepted by the current code. > -Stefan > > > thanks, > > rui > > > >> From the ACPI spec it rather sounds like > >> _DOD and _DOS must be present for a device for display switching and _DOS would > >> indicate possible backlight control as well. So the question might not be so > >> much is it the right thing than is it safe enough to allow more compatibility > >> with broken implementations without causing other problems... > >> > >> -Stefan > >> > > > > -- 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
