On Tue, Aug 13, 2013 at 10:27:53AM +0200, Jan Hinnerk Stosch wrote: > 2013/8/12 Jonathan Woithe <jwoithe@xxxxxxxxxx>: > >> 2013/6/28 Jan Hinnerk Stosch <janhinnerk.stosch@xxxxxxxxx>: > >> > since commit "a57f7f9175b8ccbc9df83ac13860488913115de4" (bisected) the > >> > wireless key on my Fujitsu E753 is not working any more. If I boot up > >> > with parameter "acpi_osi="!Windows 2012"" it works, though. > >> > I filed an ACPI-bug > >> > (https://bugzilla.kernel.org/show_bug.cgi?id=60161), but was told > >> > (https://bugzilla.kernel.org/show_bug.cgi?id=60161#c5) that this is > >> > caused by the fujitsu_laptop driver. So I report it here. Should I > >> > file a bug anywhere or is it enough to write it to the list? > > > > Does this "wireless key" do what you expect if the fujitsu_laptop module is > > not loaded? > > > > I know nothing about the E753. Is the "wireless key" a dedicated key on the > > keyboard, a separate switch, or something entirely different? It sounds > > like it's just an enable switch. > > No, the key also does not work without fujitsu_laptop module. Ok, thanks for confirming. > The key is one of two special keys - one for ECO mode (which I have > not tested or used at all) and the wireless key which switches of all > wireless functions (WLAN and bluetooth). They are not part of the > "main" keyboard. According to the output of "rfkill list" it works > indeed as a hardware switch (Hard blocked: yes/no). I see. On some Fujitsu laptops the RF kill switch is strictly a hardware thing - it does not require any software assistance at all. This is the case on the unit I have (S7020). However, there were some models which did need software assistance, and this was added to the fujitsu-laptop driver by someone with such a machine. I've had a look at the commit you referenced, and all it seems to do is add a new _OSI string to ACPI. I am not overly familiar with how the APCI side of thing works. It seems odd that adding this string to the kernel should make fujitsu-laptop (or any other driver) behave differently. Does the presence of this new string somehow cause the FUNC_RFKILL ACPI method (called via call_fext_func()) to behave differently? If someone could explain what the new _OSI string could be doing (or point to documentation) I could try to work out what might be happening. I am a little restricted in what I can do though because I don't have fujitsu hardware that supports the software RF kill switch. My best guess is that the new OSI string activates an alternative ACPI interface which does not include the custom Fujitsu RF kill interface, or which implements a different non-standard RF kill interface which fujitsu-laptop doesn't know about. However, I don't have a great grasp of the underlying ACPI functionality and would be very happy to be corrected on this point by those more knowledgeable than I in this area. Regards jonathan -- 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
