Hi,
On 19-11-2019 13:57, Mika Westerberg wrote:
On Tue, Nov 19, 2019 at 02:44:11PM +0200, Andy Shevchenko wrote:
On Tue, Nov 19, 2019 at 12:12:35PM +0100, Hans de Goede wrote:
On 19-11-2019 09:26, Mika Westerberg wrote:
On Mon, Nov 18, 2019 at 04:35:56PM +0100, Hans de Goede wrote:
Working around this is not impossible, but it will be quite ugly and given
the age of the machine IMHO not worth it. I've also found out that I need a
DSDT override to be able to control the LCD backlight, this is controlled by
the 1st PWM controller in the SoC LPSS block, which is normally enumerated
through ACPI but the entire Device (PWM1) {} block is missing from the
DSDT :| Adding it from similar hardware fixes things and makes the backlight
controllable. TL;DR: it seems that this is one of the rare cased where
people who want to run Linux will need to do a manual DSDT override :|
If it's missing it's easy to inject entire block from EFI variable or using
ConfigFS (see meta-acpi project [1] for details).
When they do that override they can also fix the _LID method and
then re-enable LID functionality on the kernel commandline overriding
this DMI quirk.
Yes, if you override entire DSDT it can be fixed for many bugs at once.
I will probably do a blog post on this (some people have asked me
to do some blogposts about how to analyze DSDT-s, this will be a nice
example) and add a link to the DSDT override to the blogpost, I believe
that this is the best we can do for users of this device.
Perhaps above mentioned project somehow can be extended to keep DSDT ASL code
for overriding? Mika?
[1]: https://github.com/westeri/meta-acpi/
No objections.
Maybe we should have a mechanism in the kernel that allows you to have
ACPI table quirks like this for multiple different systems (based on DMI
indentifiers perhaps) inside a single initrd and the kernel then loads
tables only matching the running system. That would allow distros to
ship these for broken systems.
I would love to have something like this, but I'm afraid that the distros
cannot just distribute modified DSDT's. I know we ask people to upload
acpidump's to bugzilla, etc. all the time. But one can reasonably argue
that that is fair-use (IANAL, TINLA). OTOH for something to be distributed
by distros we are going to need something a lot less handwavy wrt
re-dsitribution of these files, which AFAIK is impossible to get.
I had a discussion about this a while ago at my local hackerspace (*),
and someone there suggested to distribute patch files and have some
scripts which automatically generate an overlay by doing acpidump +
acpixtract + iasl -d + apply-patch + iasl -ta. This would then automatically
run at boot so that the next boot will have a fixed DSDT. Which is an
interesting concept if anyone is willing to work on it ...
Regards,
Hans
*) While working on fixing something which needed a DSDT override IIRC
