Hi all,
I tried diving into the acpica utility to check if I can make the state reports work on some of our machines. Currently I am testing it on the lenovo x250 and the hp 840 laptops.
However, I am not sure how and if to proceed here.
The current behaviour is as following:
When the machine starts up, it produces the reports of acpi_ac and acpi_battery correctly. When I disconnect the power outlet, these reports do not get updated. instead, I do get acpi_ec report updates on some of the different events, such as connecting and disconnecting the laptop to AC. These events have different values on the different laptops.
The ec report acpica produces on the hp840:
[init -> acpi_report_rom] report 'acpica -> acpi_ec' [init -> acpi_report_rom] <acpi_ec> [init -> acpi_report_rom] <ec> [init -> acpi_report_rom] <data value="8" count="36">triggered</data> <-- this is added on a charge up event (it seems to trigger periodically when the battery is not full and AC is connected [init -> acpi_report_rom] <data value="9" count="53"/> <-- this is added on a charge down event (it seems to trigger periodically when the battery is not full) [init -> acpi_report_rom] <data value="6" count="2"/> <-- AC connect/disconnect event (this triggers once when disconnecting and once when connecting) [init -> acpi_report_rom] </ec> [init -> acpi_report_rom] </acpi_ec>
on the x250:
[init -> acpi_report_rom] report 'acpica -> acpi_ec' [init -> acpi_report_rom] <acpi_ec> [init -> acpi_report_rom] <ec> [init -> acpi_report_rom] <data value="38" count="1">triggered</data> <-- AC disconnect event (this triggers once when disconnecting) [init -> acpi_report_rom] <data value="77" count="1"/> <-- AC connect event (this triggers once when connecting) [init -> acpi_report_rom] <data value="39" count="1"/> <-- AC connect event (this also triggers once when connecting) [init -> acpi_report_rom] </ec> [init -> acpi_report_rom] </acpi_ec>
Some observations:
* The charge/discharge events do not work on the x250. * On the hp840 connecting and deconnecting share the same data value. * On both laptops, disconnecting and reconnecting the AC outlet only triggers the ec report once, and doing it again does not produce a report. Reconnecting AC a second time also seems to cause the charge events to stop being reported on the hp840. * The lid report only works on the hp840. * The power button works on the hp840 and only works on the x250 if you press it for a longer time (but not so long as to turn off the device). * Ideally, for some device, such as one of the above, we would like all of these reports to be updated correctly.
I have some questions about this:
* You mentioned in your issue about sculpt EA that the reports not getting updated are a known issue. Do you have any plans of fixing this in the future? * Do you think solutions to this issue are going to be device specific? Which parts are generally the same for different laptops? * Is the difference in handling of the events on these machines caused by the acpica C code not supporting these machines, or by the Genode code not supporting them? or both? * A workaround could be installing a timer and generating the initial reports periodically. Do you think this would be worth implementing or would fixing the problem be easier? * For device specific parts: suppose it works on your test setup, how should we proceed to make it work on other hardware?
Hello,
On 24.04.2018 15:18, Boris Mulder wrote:
Some observations:
- The charge/discharge events do not work on the x250.
- On the hp840 connecting and deconnecting share the same data value.
- On both laptops, disconnecting and reconnecting the AC outlet only triggers the ec report once, and doing it again does not produce a report. Reconnecting AC a second time also seems to cause the charge events to stop being reported on the hp840.
- The lid report only works on the hp840.
- The power button works on the hp840 and only works on the x250 if you press it for a longer time (but not so long as to turn off the device).
- Ideally, for some device, such as one of the above, we would like all of these reports to be updated correctly.
I have some questions about this:
- You mentioned in your issue about sculpt EA that the reports not getting updated are a known issue. Do you have any plans of fixing this in the future?
We have not scheduled any work to address this. It may of course happen, either due to contract work or much spare time and willingness by whomever.
- Do you think solutions to this issue are going to be device specific? Which parts are generally the same for different laptops?
I don't know for sure, but I think yes. I suspect there will be vendor specific driver necessary if you have an embedded controller providing some of your requested features. Every notebook vendor seems like to have an own specific one, for which you will have to have some driver. To get and idea, look into the Thinkpad specific driver in the Linux kernel.
- Is the difference in handling of the events on these machines caused by the acpica C code not supporting these machines, or by the Genode code not supporting them? or both?
We did not invested much time in getting it fully running on any Thinkpad at all - so we have no answer. Neither we can tell something about HP notebooks. The best experience we had with a FUJI notebook model for a customer.
- A workaround could be installing a timer and generating the initial reports periodically. Do you think this would be worth implementing or would fixing the problem be easier?
Ideally, understanding the root cause and fixing it is the sane way. But if there is no time nor money for it, such quirk may help you of course.
- For device specific parts: suppose it works on your test setup, how should we proceed to make it work on other hardware?
I would try to re-read the ACPI specification and compare it against the implementation in the kernel. (How to react/interact on ACPI events called GPEs). Check that the events you expect are actually happening and visible to the kernel. If it does not look good, compare it to good traces, e.g. in the Linux kernel. (create traces, compare traces) Check the interplay between kernel and acpica library respectively our self-written acpica application. Are all events visible in the kernel also recognized by the acpica application ? Another step is to get hands on vendor specific documentation or implementation. Some vendors follow more closely the "ACPI-Defined Devices" (see ACPI spec) way, which our self-written acpica application effectively tries to support. Other vendor like to implement more functionality into their own embedded controller (EC) instead, as you have seen already. For such EC you will have to have an EC driver.
We are happy about any contributions and volunteers it that direction.
Cheers,
-
Alexander Boettcher -
Boris Mulder