On Wed, Jun 1, 2016 at 9:51 AM, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote: > Hi, > > [cut] >> > We could have a parameter (say "send_lid_open_on_resume" or >> > "use_bios_lid_value") in acpi/button.c which would allow people to >> > choose if they want the "new" behavior or the old one. And we could >> > also add some DMI matching for the messed up laptops/tablets where >> we >> > force one or the other quirk. When we agree that user space now >> > behaves gently with us, we could then remove entirely the quirk and >> > the dmi matching. >> > >> > How does that sound? >> [Lv Zheng] >> The choices are in my first revision. >> I could restore it back and re-send this series. >> Also I need to update PATCH 02 to eliminate wrong IS_ERR_VALUE(). > [Lv Zheng] > I forgot to mention. > IMO, if the issue is because of uncertain gaps, not a confirmed BIOS bug, or a confirmed gap that has to be solved in a spirit of compromise, we should not add quirks. > We could just provide boot parameters for users to choose. > Because the quirk table could grow bigger and bigger, exceeding our control. > > So I probably would just implement the parameter part, without adding the DMI entries. > Works for me. I think in Fedora, we might default to keep the current behavior, but document that some tablets need the parameter to be set. As soon as systemd changes its policy, we can change the default value. As for the Surface3, I think the LID state and irq is just not enough robust to be used through the ACPI node PNP0C0D. I get all the information from the touchscreen ACPI Node and the WMI, so I think there might be a way to remove the standard ACPI LID and use our own, or simply override the ACPI call by a different one (through the WMI). It's a shame logind only expects one LID event node :). Cheers, Benjamin -- 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
