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@xxxxxxxxxxxxxxxxxxx wrote: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=106031 > > > > > > > > --- Comment #2 from Britt Yazel <bwyazel@xxxxxxxxx> --- > > > > 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? Here's some context I've gathered. I haven't drawn any conclusions from this, but perhaps you will find it useful: >From what I can tell, the XPS 13 has a TOGGLE type rfkill button (Fn-PrtScrn): http://www.trustedreviews.com/dell-xps-13-2015-photos-11 I see in the journal that systemd is working with two rfkill devices (8 and 9), and that dell-wmi is emitting unknown key events (e00e). This key is of course not in the dell_wmi_legacy_keymap, but it would land right after 0xe00d, labeled as a BIOS error. -- Darren Hart Intel Open Source Technology Center -- 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
