On Thu, May 30, 2024 at 11:07:53AM +0300, Dmitry Baryshkov wrote: > 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. Yes, install an input handler matching on EV_SW/SW_LID so you will get notified when input devices capable of reporting SW_LID appear and disappear and also when SW_LID event is being generated, and handle as you wish. Something like https://chromium.googlesource.com/chromiumos/third_party/kernel/+/40e9f6a991856ee7d504ac1ccd587e435775cfc4%5E%21/#F0 In practice I think it is pretty safe to assume only 1 lid for a laptop/device. Thanks. -- Dmitry
