On Feb 23, 2016 4:01 AM, "Pali Rohár" <pali.rohar@xxxxxxxxx> wrote:
>
> On Wednesday 17 February 2016 07:07:28 Mario Limonciello wrote:
> >
> >
> > On 02/17/2016 05:16 AM, Pali Rohár wrote:
> > > On Monday 15 February 2016 08:32:37 Andy Lutomirski wrote:
> > >> On the XPS 13 9350, the dell-rbtn mechanism has a new device id, and
> > >> the DSDT turns it off if a new enough _OSI is supported. Add a
> > >> comment about why we don't bother supporting it.
> > >>
> > >> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
> > >> ---
> > >> drivers/platform/x86/dell-rbtn.c | 15 +++++++++++++++
> > >> 1 file changed, 15 insertions(+)
> > >>
> > >> diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
> > >> index cd410e392550..b51a2008d782 100644
> > >> --- a/drivers/platform/x86/dell-rbtn.c
> > >> +++ b/drivers/platform/x86/dell-rbtn.c
> > >> @@ -217,6 +217,21 @@ static void rbtn_notify(struct acpi_device *device, u32 event);
> > >> static const struct acpi_device_id rbtn_ids[] = {
> > >> { "DELRBTN", 0 },
> > >> { "DELLABCE", 0 },
> > >> +
> > >> + /*
> > >> + * This driver can also handle the "DELLABC6" device that
> > >> + * appears on the XPS 13 9350, but that device is disabled
> > >> + * by the DSDT unless booted with acpi_osi="!Windows 2012"
> > >> + * acpi_osi="!Windows 2013". Even if we boot that and bind
> > >> + * the driver, we seem to have inconsistent behavior in
> > >> + * which NetworkManager can get out of sync with the rfkill
> > >> + * state.
> > > Do you know reason for such behaviour? It is because event is send
> > > duplicated (by dell-rbtn and also by intel-hid)?
> > DELLABC6 is a custom interface that was created solely to have airplane
> > mode support for Windows 7.
> > For Windows 10 the proper interface is to use that which is handled by
> > intel-hid. A OEM airplane mode driver is not used.
> >
> > Since the kernel doesn't identify as Windows 7 it would be incorrect to
> > do attempt to use that interface.
>
> Ok, I understand. But what user can is to tell linux kernel to identify
> as Windows 7.
>
> And I would like to know reason for that inconsistent behaviour. It is
> because of bug in NetworkManager or because of some hidden bug in
> dell-rbnt.c or in rfkill kernel subsystem? If it is in kernel there is
> really big change that it can occur also on other machines which uses
> dell-rbtn and so we should fix it.
>
> Andy, can you look at it and try identify where is the problem?
I think it's straightforward. If we identify as Windows 7 and enable
this driver then, when we press the wireless button, dell-rbtn
switches its state *and* NetworkManager gets KEY_RFKILL from intel-hid
and changes its state. Then you can tell NetworkManager to turn wifi
on using the menu, at which point dell-rbtn is off but NM's software
state is on. Then you press the button again, turning on dell-rbtn
but turning NM off again. The result is that the last button press
direct work as expected.
I haven't verified that this is actually what happens, but it's
certainly the case that a button that triggers a state toggle should
only change the state by *one* mechanism.
Presumably this works on Windows 7 because either there is no
equivalent of intel-hid or because the DSDT turns it off -- I haven't
checked which is the case.
--Andy
--
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
