Hi, I just wanted to ask whether there is something I could do about this? Should I ask in another mailing list or sth? Regards jhs 2013/9/24 Jonathan Woithe <jwoithe@xxxxxxxxxx>: > 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
