On Sat, Oct 22, 2022 at 01:41:23PM +0200, Mark Kettenis wrote:
> > I continue my fight with ACPI on Lenovo IdeaPad 3 14ITL05, now, when
> > battery status problem has been resolved[1] next target is backlight
> > brightness keys.
>
> Well it hasn't been resolved yet. The firmware is clearly broken, and
> we still have to find a workaround that doesn't break other
> machines...
If I replace
sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root, ecdt->ec_id);
with
sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root, "\\_SB.PC00.LPCB.EC0");
(Firmware has "\_SB.PC00.LPCB.H_EC", and that's what I meant by
"explicitly specified correct EC_ID")
in this code:
430 /* Check if this is ECDT initialization */
431 if (ecdt) {
432 /* Get GPE, Data and Control segments */
433 sc->sc_gpe = ecdt->gpe_bit;
434
435 if (ecdt->ec_control.address_space_id == GAS_SYSTEM_IOSPACE)
436 sc->sc_cmd_bt = sc->sc_acpi->sc_iot;
437 else
438 sc->sc_cmd_bt = sc->sc_acpi->sc_memt;
439 sc->sc_ec_sc = ecdt->ec_control.address;
440
441 if (ecdt->ec_data.address_space_id == GAS_SYSTEM_IOSPACE)
442 sc->sc_data_bt = sc->sc_acpi->sc_iot;
443 else
444 sc->sc_data_bt = sc->sc_acpi->sc_memt;
445 sc->sc_ec_data = ecdt->ec_data.address;
446
447 /* Get devnode from header */
448 sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
449 ecdt->ec_id);
450
451 goto ecdtdone;
452 }
I can see battery status, so only firmware has to be patched, no other
modifications to OpenBSD are necessary, ECDT attach will work,
brightness problem looks like a different one.
Lenovo guy told that he will "inform needed departments" regarding wrong
EC_ID.
> > With the inlined patch and explicitly specified correct EC_ID in the
> > code I'm able to control brightness with functional keys. The patch
> > moves _INI methods evaluation "immediately before" table-defined device
> > attach, before the patch it was "immediately after".
> >
> > Only reference which I found in the spec is [2], and it doesn't make it
> > clear when _INI should be eval'ed: "This control method is located under
> > a device object and is run only when OSPM loads a description table."
> > Another reference in the same chapter: "_INI - Device initialization
> > method that is run shortly after ACPI has been enabled." Term "shortly"
> > isn't very precise description of when to run _INI either.
>
> Welcome to ACPI. More than 1000 pages of documentation and still
> woefully underspecified.
>
> Your interpretation doesn't make a lot of sense to me. The whole
> purpose of the tables is to have certain things (such as access to PCI
> config space or accessing the Embedded Controller) work before running
> any of the AML methods.
>
> > I understand that this isn't very grown up engineering attitude "I do
> > this and everything works", but currently I lack explanation why this
> > approach helps. If anyone has ideas how to investigate this further - I
> > will be appreciated.
>
> Identifying which of the "table-driven" device attachments is the
> culprit here might help.
Thank you, I'll give it a shot on a workweek.
