On 24/11/2015 05:06, Andrei Borzenkov wrote:
24.11.2015 01:33, Gabriele Mazzotta пишет:
[...snip...]
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. 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.
I hope this was clear enough.
Andrei, as I wrote here above, dell-rbtn _should_ make dell-laptop
remove the i8042 filter.
No. In dell_rbtn_notifier_register() it checks for RBTN of type SLIDER
using rbtn_inc_count(). If no SLIDER is found it returns ENODEV and
dell-laptop proceeds with i8042 hook.
[ 16.685944] dell_laptop: Using i8042 filter function for receiving
events
But that does *not* stop dell-rbtn from actually running and sending
input events:
I think I see the problem now. Your case (RBTN_TOGGLE +
Latitude/Precision) wasn't taken into account. I think my laptop and
yours behave in the same way, but since mine is an XPS, dell-laptop
doesn't create the rfkill + filter for it. dell-laptop does this only
for Latitude and Precision laptops.
/*
* acpi driver functions
*/
static int rbtn_add(struct acpi_device *device)
{
...
case RBTN_TOGGLE:
ret = rbtn_input_init(rbtn_data);
break;
So as I said, we now have both of them handling the same key press.
Also using dell-laptop (3.13 kernel) and dell-laptop + dell-rbtn (4.2
kernel with your patch to ignore events during suspend) I see different
reaction to key press:
3.13
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
6: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Press rfkill button
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: yes
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: yes
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
4.2
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
Press rfkill button
0: dell-wifi: Wireless LAN
Soft blocked: yes
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: yes
I am not sure whether keyboard key should be treated as hard or soft
(i.e. I do not know how to verify that radio is switched off without OS
running), but I still expect the same behavior in both cases.
Unfortunately this is expected. Looking at your DSDT it seems that the
function key of your laptop is not intended to hard block radio devices.
Also, I can see that a notification is sent on resume.
Could you also provide your acpidump so that
I can see it?
Attached (I thought about adding to bugzilla, but as we are not sure
whether it is the same bug, I send it here).
I have old Dell XPS M1303 with both slider and button type of rfkill,
I'll try to see what happens there.
I think the BIOS is sending a notification on resume also on your
laptop, but I could be wrong. The followings should be the ACPI method
calls that happen on resume:
_WAK -> RWAK -> EV2 -> \_SB.RBTN.NRBT (this one notifies RBTN)
So you have two problems: the extra notification + i8042 filter.
P.S. it seems that RBTN is exposed if _OSI claims sufficiently recent
Windows is present; I tried booting with acpi_osi=! acpi_osi=Linux and
got no RBTN device at all. I wonder how Windows handles it.
Windows 8 has changed the way radio function keys work. They are now
stateless buttons that inform the OS when they are pressed. It's up to
the OS handle the state of radio devices.
This is the reason why you see a different output using the rfkill +
dell-rbtn. We are handling radio devices as Windows does, mostly
because it's the only way to handle the function key of some laptops.
Your laptop should actually be one of those, but since it's a Latitude,
dell-laptop gets in the way. I also have issues when I load dell-laptop
(RBTN_TOGGLE here) with the force_rfkill param (mine is an XPS).
Pali, what should we do for the case Latitude/Precision + RBTN_TOGGLE?
[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
