24.11.2015 01:33, Gabriele Mazzotta пишет: > I'll try to write a summary that should explain why dell-rbtn exists > and what are the current problems. > > There are several mechanisms to control radio devices, so let's > consider different categories/cases. > > A) The function keys of new Dell laptops do nothing on their own, but > when pressed, the BIOS sends a notification to an ACPI device > (DELLABCE/DELRBTN). One of the tasks of dell-rbtn is to catch those > notifications and send an input event to userspace. Without dell-rbtn, > the function keys of these laptops wouldn't work. > > B) There are then some other laptops which support two different > mechanisms to control radio devices: the one here above (A) and > "the old one", i.e. the BIOS does everything. (These are probably > laptops that were released during the transition Windows 7 -> 8). These > laptops can switch between the two modes through an ACPI method call. > What we do with dell-rbtn is to make them behave like (A) since we > can't tell apart laptops of (A) and (B) and we need to know how each > laptop behaves. The function key of these laptops work perfectly > without dell-rbtn. > > C) There are then some other laptops for which it's required to use an > i8042 filter to detect keypresses and do some SMI calls to toggle > the state of radio devices. This filter is created by dell-laptop and > has been there since a long time. > > D) This category is something in between (C) and (A) and exists only > because of dell-rbtn. Some of the laptops of category (C) also have a > DELLABCE/DELLRBTN device. I'm pretty confident that my Dell Latitude falls into this category. What happens here apparently is - user presses hotkey on keyboard - hotkey is handled by BIOS to toggle radio - BIOS sends notification to OS via ACPI that something changed and OS must query current radio state Adding debug print do dell-laptop and dell-rbtn [43345.599909] dell-laptop: got keyboard event [43345.704558] dell-rbtn DELLABCE:00: Received event (0x80) So ACPI event comes rather later after key press. This makes those notifications at wake up not spurious at all - they are actually pretty logical, and serve to make OS ascertain current status of radio kill switch. But I am pretty much confident that those events do NOT mean to be used as request to toggle kill switch state. > When dell-rbtn is loaded, the i8042 filter is > removed and dell-rbtn starts listening for ACPI notification. We do > this instead because the i8042 filter doesn't work properly on some > laptops. > > And here is the actual bug. dell-rbtn handles category D as if it were category A. For category D it should *not* send input event, but rather hook and notify dell-laptop to query current kill switch state (because at least on my system there is no way to do it via ACPI RBTN). So the actual problem is to differentiate between categories A and D. Is it possible to do based on ACPI name (DELRBTN vs DELLABCE) or may be on return value of CRBT? If not we really need black/white list here based on DMI or something. And BTW these input events are consumed by kernel in filter installed by net/rfkill/input.c, so they are not really user space. > The problem reported in [1] is that some laptops of (A) and (B) send a > notification on resume and some others don't. [2] should fix this > problem, but we need to make sure that the extra notification is always > caught before the resume of dell-rbtn. If dell-rbtn did the right thing for my laptop, those notifications were harmless. > This seems to be what happens > here on my laptop, but Andrei says otherwise. So we need to figure out > if [2] doesn't fix the problem because it's not guaranteed that ACPI > notifications sent while the system is resuming are received by device > drivers before they are resumed (assumption that I made for the first > patch and that dropped with the updated one I sent in this thread) or > because Andrei's problem is something different. > Are you sure the laptops in bugzilla are actually of type A and not of type D? That would match what I observe here. > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=106031 > [2] > http://lkml.kernel.org/r/1448115375-7315-1-git-send-email-gabriele.mzt@xxxxxxxxx > -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
