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

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

2015-10-22 9:49 GMT+02:00 Darren Hart <dvhart@infradead.org>:
> On Wed, Oct 21, 2015 at 08:53:36PM +0200, Gabriele Mazzotta wrote:
>> 2015-10-21 13:42 GMT+02:00 Gabriele Mazzotta <gabriele.mzt@gmail.com>:
>> > 2015-10-21 13:12 GMT+02:00 Darren Hart <dvhart@infradead.org>:
>> >> On Wed, Oct 21, 2015 at 01:00:59PM +0200, Pali Rohár wrote:
>> >>> On Wednesday 21 October 2015 11:19:54 Pali Rohár wrote:
>> >>> > On Wednesday 21 October 2015 10:57:24 Darren Hart wrote:
>> >>> > > On Sun, Oct 18, 2015 at 09:34:56AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
>> >>> > > > https://bugzilla.kernel.org/show_bug.cgi?id=106031
>> >>> > > >
>> >>> > > > --- Comment #2 from Britt Yazel <bwyazel@gmail.com> ---
>> >>> > > > Confirmed. Blacklisting the dell_rbtn module solves this issue
>> >>> > >
>> >>> > > Pali,
>> >>> > >
>> >>> > > Can you take a look at this bug report regarding a 4.2 regression for rfkill
>> >>> > > after the introduction of the dell-rbtn driver please.
>> >>> > >
>> >>> >
>> >>> > Hi! This looks strange. Driver dell_rbnt is just receiver of BIOS/ACPI
>> >>> > events. It receive hotkey or slide switch event and translate it into
>> >>> > either linux input keypress or rfkill block event. But dell_rbnt driver
>> >>> > itself cannot set or change wireless rfkill or airplane mode.
>> >>> >
>> >>> > So my opinion is that BIOS/ACPI could send such event, dell_rbnt then
>> >>> > propagate it into userspace and some application process it and do
>> >>> > something...
>> >>> >
>> >>>
>> >>> CCing Gabriele, owner of XPS machine too. Have you seen similar problems
>> >>> with dell_rbtn as described in above bug report?
>> >
>> > I'll look into this ASAP. I haven't been using dell_rbtn not to disable
>> > the hardware switch, but I didn't notice anything strange the last time
>> > I tested it.
>>
>> I went back to see the old thread about dell-rbtn and apparently I was
>> aware of this problem [1]. So yes, I confirm the bug.
>>
>> We are assuming that RBTN receives notifications only when a button
>> function keys are pressed, but this is true only for some laptops, while
>> others, such as my XPS13, send a notification also on resume [2].
>> This makes things a bit more complicated.
>>
>> CCed Alex since he might be interested in this.
>>
>> [1] https://marc.info/?l=linux-kernel&m=141927583032180
>> [2] https://marc.info/?l=linux-kernel&m=141941243829713
>>
>
> Am I correct in my understanding that there is no EC state associated with the
> RFKILL for the TOGGLE type?

As far as I know, yes.

> Is there any point in sending the event upon resume? If not, perhaps we could
> set a flag on suspend and then ignore the event on resume and then clear the
> flag. This would have to be only for the affected latops though, which is
> certainly not ideal.

The problem is that we don't know which are the affected laptops. I
suspect they are those that support both the methods to disable radio
devices (software and hardware), i.e. those with a working ARBT method,
such as mine.

So this solution wouldn't really work properly, unless we define some
time constraints, which makes the solution even worse.

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.

> --
> Darren Hart
> Intel Open Source Technology Center