Re: [Bug 106031] Regression in 4.2.x: in airplane mode each time I open my laptop lid

[Gabriele Mazzotta <gabriele.mzt@gmail.com>]

On 22/10/2015 15:02, Darren Hart wrote:
> On Thu, Oct 22, 2015 at 12:54:33PM +0200, Gabriele Mazzotta wrote:
>> On 22/10/2015 12:50, Pali Rohár wrote:
>>> On Thursday 22 October 2015 12:44:08 Gabriele Mazzotta wrote:
>>>> On 22/10/2015 10:51, Pali Rohár wrote:
>>>>> On Thursday 22 October 2015 10:26:47 Gabriele Mazzotta wrote:
>>>>>> I'll see if I can find a batter way to deal with this problem,
>>>>>> dell-laptop can detect the presence of an hardware switch.
>>>>>
>>>>> dell-rbtn.ko has acpi method CRBT which returns if notebook has hw switch or
>>>>> toggle key.
>>>>>
>>>>> And rfkill implementation in dell-laptop.ko does not work correctly on
>>>>> XPS machines. And because userspace implementation of smbios works fine,
>>>>> I think that problem is in kernel driver rather in BIOS/firmware...
>>>>
>>>> I was thinking about something such as the following, which should favor
>>>> the hardware slider when available. This should work if my assumption is
>>>> correct, that is the laptops with a working RBTN method are the ones
>>>> having problems.
>>>>
>>>
>>> Hm... wait! There are machines with HW slider and type is RBTN_TOGGLE?
>>>
>>> I thought that all machines with HW slider has type RBTN_SLIDER and
>>> others have RBTN_TOGGLE.
>>
>> Yes, this is the problem I've been talking about ever since the work
>> on this driver started. AFAIK we don't know how to detect these laptops
>> (my XPS13 is one of them).
>
> Where is the radio hw slider on this machine?

It's the F2 key. Depending on the value passed to the RBTN, it acts as
hw slider or sw toggle. Currently dell-rbtn makes all the laptops with
both the hw slider and sw toggle use the sw toggle. In this way we are
sure that whenever CRBT returns either 1 or 0, we are using the sw
mechanism to disable the radios.

The problem is that the CRBT method of these laptops supporting both
the methods return 1 or 0 as the laptops that only have the sw toggle.
That's why we are calling RBTN to force the sw toggle.

> This patch would effectively ignore Fn-F2 (radio toggle) key on this machine
> then - correct? I don't think that is desirable either.

No, this patch would force the hw slider when it's available instead
of blindly forcing the sw toggle. When the hw slider is in use,
everything is handled by the BIOS, so userspace/kernel don't have to
do anything.

> Seems to me the desired behavior would be to restore the radio state on resume.
> Consider the following table:
>
> SW: Switch state
> SS: State at suspend
> SR: State after resume
>   0: WiFi Enabled
>   1: WiFi Disabled
>
> State SW SS SR
> --------------
> a      0  0  0
> b      0  1  1   (switch is enabled, but toggle key disabled wifi)
> c      1  0  N/A (invalid state)
> d      1  1  1
>
> State "a" is where we are failing currently I believe?

dell-rbtn is simply listening to the ACPI notifications sent to
DELLABCE. These notifications are sent by the BIOS, both when users
press the function key and when it wants. In my case, the BIOS sends a
notification on resume (dell-rbtn sees this notification and sends an
input event to userspace), but the BIOS of some other laptops don't do
this.

Basically, dell-rbtn makes some laptop toggles the state of WiFi on
resume, but not all of them.

In my case:
if WiFi is ON on suspend, it's turned OFF on resume.
if WiFi is OFF on suspend, it's turned ON on resume.

Reading what Alex wrote some time ago [1], I guessed that the laptops 
that are misbehaving are those that can choose between sw toggle and hw
toggle.

> Do we know if DELRBTN and DELLABCE are always a TOGGLE or a SLIDER respectively?
> I'm wondering if these should be separate drivers.

I'm reading the acpidumps Alex provided some time ago [2] (and mine):
* XPS13 9333: DELLABCE, by default (without calling RBTN) SLIDER.
* Latitude E5440: DELLABCE, SLIDER
* Inspiron 7447: DELLABCE, TOGGLE
* Pali's laptop: DELLRBTN, SLIDER (correct?).

[1] https://marc.info/?l=linux-kernel&m=141941243829713
[2] http://people.canonical.com/~alexhung/dell-acpidump/