On Thu, 30 May 2024 at 07:41, Limonciello, Mario <mario.limonciello@xxxxxxx> wrote: > > > >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if > >> someone needs this to work on non-ACPI system they get to figure out > >> how to abstract it better. acpi_lid_open() does seem to return != 0 > >> when ACPI is not supported, so at least it would err on the side > >> of enabling everything. > > > > Thanks. I was going to comment, but you got it first. I think a proper > > implementation should check for SW_LID input device instead of simply > > using acpi_lid_open(). This will handle the issue for other, > > non-ACPI-based laptops. > > > > Can you suggest how this would actually work? AFAICT the only way to > discover if input devices support SW_LID would be to iterate all the > input devices in the kernel and look for whether ->swbit has SW_LID set. > > This then turns into a dependency problem of whether any myriad of > drivers have started to report SW_LID. It's also a state machine > problem because other drivers can be unloaded at will. > > And then what do you if more than one sets SW_LID? It might be easier to handle this in the input subsystem. For example by using a refcount-like variable which handles all the LIDs and counts if all of them are closed. Or if any of the LIDs is closed. > > IOW - a lot of complexity for a non-ACPI system. Does such a problem > exist in non-ACPI systems? There are non-ACPI laptops. For example Chromebooks. Or Lenovo X13s, Lenovo Yoga C630, Lenovo Flex5G, etc. We are expecting more to come in the next few months. And I don't see why they won't have the same problem. -- With best wishes Dmitry
