> > > > > Would it be possible to ask the vendor to remove INT0002 device from the > > firmware? > > Even if all vendors would issue BIOs updates for this for all models > (which they won't) then we still cannot count on users installing those > BIOS updates. Because of this relying on a BIOS update is almost never the > right answer. > > (Note I guess there might be some extreme circumstans / some corner case where > things are so broken that we will tell users to just upgrade their BIOS) It wasn't clear to me if this inquiry was for release or pre-release hardware. If it's pre-release hardware this is actually quite preferable in my opinion. > > >> 2. Deal with non functional /sys/class/backlight/acpi_video[0-7] devices > >> showing up on BYT/CHT based media-boxes / hdmi-sticks. These devices do > >> not have a LCD panel, so there will be no "native" backlight driver causing > >> drivers/acpi/video-detect.c to select acpi_backlight_video as backlight- > type. > >> drivers/acpi/acpi-video.c tries to avoid registering non-functional > >> /sys/class/backlight/acpi_video devices in cases like this, but that > depends > >> on a DMI chassis-type check (to avoid suppressing the backlight interface > >> on laptops where we likely do want it) and many of these media-boxes / > >> hdmi-sticks are derived from BYT/CHT tablet designs and often the DMI > >> chassis type still says "Tablet". Actual Cherry Trail devices with a LCD > >> panel always use the native intel_backlight interface, but I guess some > >> Braswell based devices might use the acpi_video interface. > > > > Maybe a function to look at specifically the DMI chassis type of "Tablet" > and > > check for the lack of an internal LCD panel. That seems like detecting that > > combination shouldn't ever try to run this code. > > The issue is that we cannot detect the presence of a LCD panel from the > ACPI-video code. That is done by the i915 driver (on these devices) and > we really don't want any (more) dependencies between the acpi-video code > and the i915 code as those are very hard to manage wrt things like the > probing order. Also the ACPI-video code is supposed to be platform and > even architecture independent. > > Regards, > > Hans
