Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
Since Windows 8 requirement asks below, I see a trend that OEM is moving wireless to HW-control to SW-control. That's also why some new systems never trigger hard-blocks. I was also told that there may be no "HW-GPIO" (my translation -> no hard-block) to control wireless in some of future systems. I do not have any details but will share / submit patches if this is going to impact Linux kernel. System.Client.RadioManagement.HardwareButton If a PC has a physical (hardware) button switch on a PC that turns wireless radios on and off, it must be software controllable and interact appropriately with the Radio Management UI I don't see the kernel parameter as a workaround, either. I agree with Gabriele that it is giving users an second option to choose how to use the hardware they purchased. On Wed, May 6, 2015 at 5:23 AM, Gabriele Mazzotta wrote: > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: >> On Thursday 30 April 2015 14:06:27 Alex Hung wrote: >> > Method ABRT is to be used by driver to disable BIOS handling of radio >> > button. So the changes in behaviours observed by Gabriele is expected. >> > I have seen other systems behave the same way. >> > >> >> Right, that after that ARBT call operating system get full control over >> radio devices and ACPI/BIOS will not automatically enable/disable them. >> I think this is OK. >> >> But for that we need also support for manually enable/disable radio >> devices and code for this support is missing. Or do DELLABCE/RBTN acpi >> devices somehow support enabling/disabling it via system/kernel request? >> >> > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block >> > whether ABRT(1) is called or not. Thus keycode are the only option on >> > those machines. >> > >> >> Key is ok, but we *must* have ability to hard block it via some >> ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should >> be able to enable/disable their radio devices (bluetooth for powersave) > > Does it really matter in the end? As I understand it, radio devices are > off either way. > >> > The idea to have an option (kernel parameter) for calling ABRT is >> > great. I can help verify on more machines. Is Gabriele's patch above a >> > final version that I should test? >> > >> >> No, I do not think so. This looks like hack or pure design. Kernel >> option could be there, but just for buggy BIOSes (and future changed >> design). >> >> But now it looks like for correct work is specifying that param >> required -- which is bad. >> >> Alex, can you ask Dell people how should system turn off e.g bluetooth >> or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is >> expected to turn off/on blueooth (and wifi) devices? >> >> I think that without this information (and working driver for it) we >> should not enable ARTB(1) or including this driver into kernel tree as >> it will break some existing machines... > > I disagree. If we skip ARBT(1), userspace will get confused on laptops > like mine as it would receive two events: an rfkill event (because of > the BIOS shutting down radios) and a keypress (because of Alex's patch). > If we call ARBT(1), userspace will only receive the keypress and > userspace will correctly handle the devices. > > That's why I suggested the use of a kernel parameter. It was just a way > to allow users to choose one mode over another when they know they're > both available. It's not something users are required to do. > > I believe that in the end what really matters is that when function > keys are pressed something happens, be it the BIOS turning off radio > devices or the kernel telling userspace to do it, but not both. > >> Darren, I do not know what is better, but it looks like that some dell >> machines working fine now and some not (since begining). And after >> loading this driver some machines are fixed, but some which worked are >> broken... What do you think as maintainer? -- Cheers, Alex Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Tuesday 05 May 2015 22:55:46 Darren Hart wrote: > On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote: > > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > > > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > > > Method ABRT is to be used by driver to disable BIOS handling of radio > > > > button. So the changes in behaviours observed by Gabriele is expected. > > > > I have seen other systems behave the same way. > > > > > > > > > > Right, that after that ARBT call operating system get full control over > > > radio devices and ACPI/BIOS will not automatically enable/disable them. > > > I think this is OK. > > > > > > But for that we need also support for manually enable/disable radio > > > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > > > devices somehow support enabling/disabling it via system/kernel request? > > > > > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > > > whether ABRT(1) is called or not. Thus keycode are the only option on > > > > those machines. > > > > > > > > > > Key is ok, but we *must* have ability to hard block it via some > > > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > > > be able to enable/disable their radio devices (bluetooth for powersave) > > > > Does it really matter in the end? As I understand it, radio devices are > > off either way. > > As a point of reference for consideration, we recently dropped the Thinkpad > hardware mute button because it seriously complicated everything in what > appears > to be a similar sort of situation. By eliminating the hardware mute and > relying > purely on software mute, we were able to provide a much more consistently > functional driver. > > Also note that this driver provided a "software_mute" module parameter to > allow > the user to control this. > > I believe this provides some relevant precedent for your consideration. I > don't > want to add parameters casually, but it could be one is warranted here. > Yes, this driver transfter hardware function (implemented in EC ACPI firmware) into software kernel solution. But my point was that software solution must be able to call all those "functions" which was called previously by ACPI/firmware. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
Since Windows 8 requirement asks below, I see a trend that OEM is moving wireless to HW-control to SW-control. That's also why some new systems never trigger hard-blocks. I was also told that there may be no HW-GPIO (my translation - no hard-block) to control wireless in some of future systems. I do not have any details but will share / submit patches if this is going to impact Linux kernel. System.Client.RadioManagement.HardwareButton If a PC has a physical (hardware) button switch on a PC that turns wireless radios on and off, it must be software controllable and interact appropriately with the Radio Management UI I don't see the kernel parameter as a workaround, either. I agree with Gabriele that it is giving users an second option to choose how to use the hardware they purchased. On Wed, May 6, 2015 at 5:23 AM, Gabriele Mazzotta gabriele@gmail.com wrote: On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) Does it really matter in the end? As I understand it, radio devices are off either way. The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... I disagree. If we skip ARBT(1), userspace will get confused on laptops like mine as it would receive two events: an rfkill event (because of the BIOS shutting down radios) and a keypress (because of Alex's patch). If we call ARBT(1), userspace will only receive the keypress and userspace will correctly handle the devices. That's why I suggested the use of a kernel parameter. It was just a way to allow users to choose one mode over another when they know they're both available. It's not something users are required to do. I believe that in the end what really matters is that when function keys are pressed something happens, be it the BIOS turning off radio devices or the kernel telling userspace to do it, but not both. Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? -- Cheers, Alex Hung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Tuesday 05 May 2015 22:55:46 Darren Hart wrote: On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote: On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) Does it really matter in the end? As I understand it, radio devices are off either way. As a point of reference for consideration, we recently dropped the Thinkpad hardware mute button because it seriously complicated everything in what appears to be a similar sort of situation. By eliminating the hardware mute and relying purely on software mute, we were able to provide a much more consistently functional driver. Also note that this driver provided a software_mute module parameter to allow the user to control this. I believe this provides some relevant precedent for your consideration. I don't want to add parameters casually, but it could be one is warranted here. Yes, this driver transfter hardware function (implemented in EC ACPI firmware) into software kernel solution. But my point was that software solution must be able to call all those functions which was called previously by ACPI/firmware. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote: > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > > Method ABRT is to be used by driver to disable BIOS handling of radio > > > button. So the changes in behaviours observed by Gabriele is expected. > > > I have seen other systems behave the same way. > > > > > > > Right, that after that ARBT call operating system get full control over > > radio devices and ACPI/BIOS will not automatically enable/disable them. > > I think this is OK. > > > > But for that we need also support for manually enable/disable radio > > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > > devices somehow support enabling/disabling it via system/kernel request? > > > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > > whether ABRT(1) is called or not. Thus keycode are the only option on > > > those machines. > > > > > > > Key is ok, but we *must* have ability to hard block it via some > > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > > be able to enable/disable their radio devices (bluetooth for powersave) > > Does it really matter in the end? As I understand it, radio devices are > off either way. As a point of reference for consideration, we recently dropped the Thinkpad hardware mute button because it seriously complicated everything in what appears to be a similar sort of situation. By eliminating the hardware mute and relying purely on software mute, we were able to provide a much more consistently functional driver. Also note that this driver provided a "software_mute" module parameter to allow the user to control this. I believe this provides some relevant precedent for your consideration. I don't want to add parameters casually, but it could be one is warranted here. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > Method ABRT is to be used by driver to disable BIOS handling of radio > > button. So the changes in behaviours observed by Gabriele is expected. > > I have seen other systems behave the same way. > > > > Right, that after that ARBT call operating system get full control over > radio devices and ACPI/BIOS will not automatically enable/disable them. > I think this is OK. > > But for that we need also support for manually enable/disable radio > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > devices somehow support enabling/disabling it via system/kernel request? > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > whether ABRT(1) is called or not. Thus keycode are the only option on > > those machines. > > > > Key is ok, but we *must* have ability to hard block it via some > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > be able to enable/disable their radio devices (bluetooth for powersave) Does it really matter in the end? As I understand it, radio devices are off either way. > > The idea to have an option (kernel parameter) for calling ABRT is > > great. I can help verify on more machines. Is Gabriele's patch above a > > final version that I should test? > > > > No, I do not think so. This looks like hack or pure design. Kernel > option could be there, but just for buggy BIOSes (and future changed > design). > > But now it looks like for correct work is specifying that param > required -- which is bad. > > Alex, can you ask Dell people how should system turn off e.g bluetooth > or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is > expected to turn off/on blueooth (and wifi) devices? > > I think that without this information (and working driver for it) we > should not enable ARTB(1) or including this driver into kernel tree as > it will break some existing machines... I disagree. If we skip ARBT(1), userspace will get confused on laptops like mine as it would receive two events: an rfkill event (because of the BIOS shutting down radios) and a keypress (because of Alex's patch). If we call ARBT(1), userspace will only receive the keypress and userspace will correctly handle the devices. That's why I suggested the use of a kernel parameter. It was just a way to allow users to choose one mode over another when they know they're both available. It's not something users are required to do. I believe that in the end what really matters is that when function keys are pressed something happens, be it the BIOS turning off radio devices or the kernel telling userspace to do it, but not both. > Darren, I do not know what is better, but it looks like that some dell > machines working fine now and some not (since begining). And after > loading this driver some machines are fixed, but some which worked are > broken... What do you think as maintainer? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thu, Apr 30, 2015 at 09:44:29AM +0200, Pali Rohár wrote: > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > Method ABRT is to be used by driver to disable BIOS handling of radio > > button. So the changes in behaviours observed by Gabriele is expected. > > I have seen other systems behave the same way. > > > > Right, that after that ARBT call operating system get full control over > radio devices and ACPI/BIOS will not automatically enable/disable them. > I think this is OK. > > But for that we need also support for manually enable/disable radio > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > devices somehow support enabling/disabling it via system/kernel request? > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > whether ABRT(1) is called or not. Thus keycode are the only option on > > those machines. > > > > Key is ok, but we *must* have ability to hard block it via some > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > be able to enable/disable their radio devices (bluetooth for powersave) > > > The idea to have an option (kernel parameter) for calling ABRT is > > great. I can help verify on more machines. Is Gabriele's patch above a > > final version that I should test? > > > > No, I do not think so. This looks like hack or pure design. Kernel > option could be there, but just for buggy BIOSes (and future changed > design). > > But now it looks like for correct work is specifying that param > required -- which is bad. > > Alex, can you ask Dell people how should system turn off e.g bluetooth > or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is > expected to turn off/on blueooth (and wifi) devices? > > I think that without this information (and working driver for it) we > should not enable ARTB(1) or including this driver into kernel tree as > it will break some existing machines... > > Darren, I do not know what is better, but it looks like that some dell > machines working fine now and some not (since begining). And after > loading this driver some machines are fixed, but some which worked are > broken... What do you think as maintainer? We work with a challenging space that forces us to consider doing abnormal things to support product firmware, I do understand that I try to support it. I agree with your statement above, the kernel parameter, if used at all, should be used in special cases as a workaround, not as the normal case. While I'm happy to take incremental improvements, even if they aren't 100% perfect, we can't fix some laptops by breaking others. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote: On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) Does it really matter in the end? As I understand it, radio devices are off either way. As a point of reference for consideration, we recently dropped the Thinkpad hardware mute button because it seriously complicated everything in what appears to be a similar sort of situation. By eliminating the hardware mute and relying purely on software mute, we were able to provide a much more consistently functional driver. Also note that this driver provided a software_mute module parameter to allow the user to control this. I believe this provides some relevant precedent for your consideration. I don't want to add parameters casually, but it could be one is warranted here. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thu, Apr 30, 2015 at 09:44:29AM +0200, Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? We work with a challenging space that forces us to consider doing abnormal things to support product firmware, I do understand that I try to support it. I agree with your statement above, the kernel parameter, if used at all, should be used in special cases as a workaround, not as the normal case. While I'm happy to take incremental improvements, even if they aren't 100% perfect, we can't fix some laptops by breaking others. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) Does it really matter in the end? As I understand it, radio devices are off either way. The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... I disagree. If we skip ARBT(1), userspace will get confused on laptops like mine as it would receive two events: an rfkill event (because of the BIOS shutting down radios) and a keypress (because of Alex's patch). If we call ARBT(1), userspace will only receive the keypress and userspace will correctly handle the devices. That's why I suggested the use of a kernel parameter. It was just a way to allow users to choose one mode over another when they know they're both available. It's not something users are required to do. I believe that in the end what really matters is that when function keys are pressed something happens, be it the BIOS turning off radio devices or the kernel telling userspace to do it, but not both. Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Saturday 02 May 2015 15:51:50 Gabriele Mazzotta wrote: > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > > Method ABRT is to be used by driver to disable BIOS > > > handling of radio button. So the changes in behaviours > > > observed by Gabriele is expected. I have seen other > > > systems behave the same way. > > > > Right, that after that ARBT call operating system get full > > control over radio devices and ACPI/BIOS will not > > automatically enable/disable them. I think this is OK. > > > > But for that we need also support for manually > > enable/disable radio devices and code for this support is > > missing. Or do DELLABCE/RBTN acpi devices somehow support > > enabling/disabling it via system/kernel request? > > > > > I do also see firmware only sends Notify(RBTN, 0x80) and > > > no hard block whether ABRT(1) is called or not. Thus > > > keycode are the only option on those machines. > > > > Key is ok, but we *must* have ability to hard block it via > > some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no > > go as users should be able to enable/disable their radio > > devices (bluetooth for powersave) > > > > > The idea to have an option (kernel parameter) for calling > > > ABRT is great. I can help verify on more machines. Is > > > Gabriele's patch above a final version that I should > > > test? > > > > No, I do not think so. This looks like hack or pure design. > > Kernel option could be there, but just for buggy BIOSes > > (and future changed design). > > > > But now it looks like for correct work is specifying that > > param required -- which is bad. > > > > Alex, can you ask Dell people how should system turn off e.g > > bluetooth or wifi device if ARTB(1) is called and > > system/kernel (instead ACPI) is expected to turn off/on > > blueooth (and wifi) devices? > > I completely forgot that libsmbios comes with > smbios-wireless-ctl. It allows me to control the hardware > slider. > > > I think that without this information (and working driver > > for it) we should not enable ARTB(1) or including this > > driver into kernel tree as it will break some existing > > machines... > > Alex, could you test smbios-wireless-ctl and see what it says > about the laptops with no hardware slider? For instance on > mine it says: > > Radio Status for WLAN: > WLAN enabled at boot > WLAN supported > WLAN enabled > WLAN installed > WLAN boot-time wireless switch setting not present > WLAN runtime switch control currently enabled > Status Code: 0 > > You can find the utility here: > http://linux.dell.com/git/libsmbios.git > > The code to check for the presence of an hardware slider is > even already implemented in dell-laptop and works on my > laptop, it says the slider is present. > > > Pali, you have a Latitude, right? Is "whitelisted" true when > you load dell-laptop? I'm asking because when I load > dell-laptop with force_rfkill, my function key stops working. > Radio devices get disabled the moment dell-laptop is loaded > and I must use smbios-wireless-ctl to re-enable them. Once I > re-enabled them, the function keys starts working again. > I don't know exactly what happens on your laptop, but I was > wondering if dell-laptop is messing things up on your laptop > too. Hi, on my Latitude E6440 machine dell-laptop (with rfkill) working fine. There is no problem with it. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > Method ABRT is to be used by driver to disable BIOS handling of radio > > button. So the changes in behaviours observed by Gabriele is expected. > > I have seen other systems behave the same way. > > > > Right, that after that ARBT call operating system get full control over > radio devices and ACPI/BIOS will not automatically enable/disable them. > I think this is OK. > > But for that we need also support for manually enable/disable radio > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > devices somehow support enabling/disabling it via system/kernel request? > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > whether ABRT(1) is called or not. Thus keycode are the only option on > > those machines. > > > > Key is ok, but we *must* have ability to hard block it via some > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > be able to enable/disable their radio devices (bluetooth for powersave) > > > The idea to have an option (kernel parameter) for calling ABRT is > > great. I can help verify on more machines. Is Gabriele's patch above a > > final version that I should test? > > > > No, I do not think so. This looks like hack or pure design. Kernel > option could be there, but just for buggy BIOSes (and future changed > design). > > But now it looks like for correct work is specifying that param > required -- which is bad. > > Alex, can you ask Dell people how should system turn off e.g bluetooth > or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is > expected to turn off/on blueooth (and wifi) devices? I completely forgot that libsmbios comes with smbios-wireless-ctl. It allows me to control the hardware slider. > I think that without this information (and working driver for it) we > should not enable ARTB(1) or including this driver into kernel tree as > it will break some existing machines... Alex, could you test smbios-wireless-ctl and see what it says about the laptops with no hardware slider? For instance on mine it says: Radio Status for WLAN: WLAN enabled at boot WLAN supported WLAN enabled WLAN installed WLAN boot-time wireless switch setting not present WLAN runtime switch control currently enabled Status Code: 0 You can find the utility here: http://linux.dell.com/git/libsmbios.git The code to check for the presence of an hardware slider is even already implemented in dell-laptop and works on my laptop, it says the slider is present. Pali, you have a Latitude, right? Is "whitelisted" true when you load dell-laptop? I'm asking because when I load dell-laptop with force_rfkill, my function key stops working. Radio devices get disabled the moment dell-laptop is loaded and I must use smbios-wireless-ctl to re-enable them. Once I re-enabled them, the function keys starts working again. I don't know exactly what happens on your laptop, but I was wondering if dell-laptop is messing things up on your laptop too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I completely forgot that libsmbios comes with smbios-wireless-ctl. It allows me to control the hardware slider. I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Alex, could you test smbios-wireless-ctl and see what it says about the laptops with no hardware slider? For instance on mine it says: Radio Status for WLAN: WLAN enabled at boot WLAN supported WLAN enabled WLAN installed WLAN boot-time wireless switch setting not present WLAN runtime switch control currently enabled Status Code: 0 You can find the utility here: http://linux.dell.com/git/libsmbios.git The code to check for the presence of an hardware slider is even already implemented in dell-laptop and works on my laptop, it says the slider is present. Pali, you have a Latitude, right? Is whitelisted true when you load dell-laptop? I'm asking because when I load dell-laptop with force_rfkill, my function key stops working. Radio devices get disabled the moment dell-laptop is loaded and I must use smbios-wireless-ctl to re-enable them. Once I re-enabled them, the function keys starts working again. I don't know exactly what happens on your laptop, but I was wondering if dell-laptop is messing things up on your laptop too. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Saturday 02 May 2015 15:51:50 Gabriele Mazzotta wrote: On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I completely forgot that libsmbios comes with smbios-wireless-ctl. It allows me to control the hardware slider. I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Alex, could you test smbios-wireless-ctl and see what it says about the laptops with no hardware slider? For instance on mine it says: Radio Status for WLAN: WLAN enabled at boot WLAN supported WLAN enabled WLAN installed WLAN boot-time wireless switch setting not present WLAN runtime switch control currently enabled Status Code: 0 You can find the utility here: http://linux.dell.com/git/libsmbios.git The code to check for the presence of an hardware slider is even already implemented in dell-laptop and works on my laptop, it says the slider is present. Pali, you have a Latitude, right? Is whitelisted true when you load dell-laptop? I'm asking because when I load dell-laptop with force_rfkill, my function key stops working. Radio devices get disabled the moment dell-laptop is loaded and I must use smbios-wireless-ctl to re-enable them. Once I re-enabled them, the function keys starts working again. I don't know exactly what happens on your laptop, but I was wondering if dell-laptop is messing things up on your laptop too. Hi, on my Latitude E6440 machine dell-laptop (with rfkill) working fine. There is no problem with it. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > Method ABRT is to be used by driver to disable BIOS handling of radio > button. So the changes in behaviours observed by Gabriele is expected. > I have seen other systems behave the same way. > Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > whether ABRT(1) is called or not. Thus keycode are the only option on > those machines. > Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) > The idea to have an option (kernel parameter) for calling ABRT is > great. I can help verify on more machines. Is Gabriele's patch above a > final version that I should test? > No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? On Thu, Apr 30, 2015 at 2:59 AM, Pali Rohár wrote: > On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote: >> On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: >> > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: >> > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: >> > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta >> > > > wrote: >> > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: >> > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta >> > > > > > wrote: >> > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár >> > > > > > > wrote: >> > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele >> > > > > > > > Mazzotta wrote: >> > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár >> > > > > > > > > wrote: >> > > > > > > > > > This is an ACPI driver for Dell laptops >> > > > > > > > > > which receive HW switch events. It exports >> > > > > > > > > > rfkill device dell-rbtn which provide >> > > > > > > > > > correct hard rfkill state. >> > > > > > > > > > >> > > > > > > > > > Alex Hung added code for supporting Dell >> > > > > > > > > > laptops which have toggle button instead HW >> > > > > > > > > > slider switch. On these laptops toggle >> > > > > > > > > > button event is reported by new input >> > > > > > > > > > device (instead rfkill) as they do not have >> > > > > > > > > > hw radio switch. >> > > > > > > > > > >> > > > > > > > > > It looks like those are two different >> > > > > > > > > > functions (rfkill, input device), but Dell >> > > > > > > > > > BIOS exports them via same ACPI device and >> > > > > > > > > > uses same ACPI functions. So code is in one >> > > > > > > > > > kernel driver. >> > > > > > > > > >> > > > > > > > > I made a patch some time ago that I've just >> > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over >> > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to >> > > > > > > > > have the hardware switch is that the BIOS >> > > > > > > > > doesn't alter the soft state of the devices. >> > > > > > > > > This comes in handy when the function key >> > > > > > > > > controls multiple radio devices. >> > > > > > > > >> > > > > > > > Now I'm thinking... is't this bug in wifi kernel >> > > > > > > > driver (which exports phy rfkill)? Or problem >> > > > > > > > somewhere else (userspace or kernel)? >> > > > > > > >> > > > > > > What is the presumed bug you are referring to? The >> > > > > > > fact that the soft state doesn't change? >> > > > > > >> > > > > > Can you remind me whats the problem on your laptop? >> > > > > >> > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my >> > > > > laptop acts as if it returned 2 or 3, so we have to >> > > > > call ARBT. >> > > > > >> > > > > As said before, there's no way to know when a platform >> > > > > whose CRBT method returns 0 or 1 also has the >> > > > > hardware switch, so to be sure that all the platforms >> > > > > have working function keys, some of them (such as >> > > > > mine) have to give up on the hardware switch. >> > > > >> > > > Ok, and what happens when you load this v2 version? What >> > > > stopped working on your laptop? >> > > > >> > > > Alex, can you help? Code for toggle laptop version is >> > > > originally yours. >> > > >> > > When I press the Fn key, a _Qxx EC method is executed. The >> > > code path of this method depends on a variable set by >> > > ARBT. >> > > >> > > When you call ARBT with 1 as argument, the variable is set >> > > to 1 and the _Qxx method does nothing but sending a >> > > notification (0x80) to RBTN whenever the function key is >> > > pressed. >> > > >> > > When you call ARBT with 0 as argument, the variable is set >> > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_ >> > > toggle the state of the radio devices whenever the >> > > function key is pressed. >> > > >> > > So in the end nothing _really_ breaks. >> > >> > So in linux kernel is missing code for toggling state of >> > radio devices? And you can do that only by ACPI when ARBT >> > is called with 0, right? >> >> Yes. >> >> With Alex's code the kernel sends keypresses to userspace and >> userspace takes care of toggling the state of radio devices. > > Alex, can you ask Dell for documentation how to enable/disable > radio devices? Because when ARBT is set to 1, then system must > take care of it but, linux does not support it yet... > > -- > Pali Rohár > pali.ro...@gmail.com -- Cheers, Alex Hung -- To
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 14:06:27 Alex Hung wrote: Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? On Thu, Apr 30, 2015 at 2:59 AM, Pali Rohár pali.ro...@gmail.com wrote: On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. So in linux kernel is missing code for toggling state of radio devices? And you can do that only by ACPI when ARBT is called with 0, right? Yes. With Alex's code the kernel sends keypresses to userspace and userspace takes care of toggling the state of radio devices. Alex, can you ask Dell for documentation how to enable/disable radio devices? Because when ARBT is set to 1, then system must take care of it but, linux does not support it yet... -- Pali Rohár pali.ro...@gmail.com -- Cheers, Alex Hung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote: > On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: > > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: > > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: > > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta > > > > wrote: > > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta > > > > > > wrote: > > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár > > > > > > > wrote: > > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele > > > > > > > > Mazzotta wrote: > > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár > > > > > > > > > wrote: > > > > > > > > > > This is an ACPI driver for Dell laptops > > > > > > > > > > which receive HW switch events. It exports > > > > > > > > > > rfkill device dell-rbtn which provide > > > > > > > > > > correct hard rfkill state. > > > > > > > > > > > > > > > > > > > > Alex Hung added code for supporting Dell > > > > > > > > > > laptops which have toggle button instead HW > > > > > > > > > > slider switch. On these laptops toggle > > > > > > > > > > button event is reported by new input > > > > > > > > > > device (instead rfkill) as they do not have > > > > > > > > > > hw radio switch. > > > > > > > > > > > > > > > > > > > > It looks like those are two different > > > > > > > > > > functions (rfkill, input device), but Dell > > > > > > > > > > BIOS exports them via same ACPI device and > > > > > > > > > > uses same ACPI functions. So code is in one > > > > > > > > > > kernel driver. > > > > > > > > > > > > > > > > > > I made a patch some time ago that I've just > > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over > > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to > > > > > > > > > have the hardware switch is that the BIOS > > > > > > > > > doesn't alter the soft state of the devices. > > > > > > > > > This comes in handy when the function key > > > > > > > > > controls multiple radio devices. > > > > > > > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel > > > > > > > > driver (which exports phy rfkill)? Or problem > > > > > > > > somewhere else (userspace or kernel)? > > > > > > > > > > > > > > What is the presumed bug you are referring to? The > > > > > > > fact that the soft state doesn't change? > > > > > > > > > > > > Can you remind me whats the problem on your laptop? > > > > > > > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my > > > > > laptop acts as if it returned 2 or 3, so we have to > > > > > call ARBT. > > > > > > > > > > As said before, there's no way to know when a platform > > > > > whose CRBT method returns 0 or 1 also has the > > > > > hardware switch, so to be sure that all the platforms > > > > > have working function keys, some of them (such as > > > > > mine) have to give up on the hardware switch. > > > > > > > > Ok, and what happens when you load this v2 version? What > > > > stopped working on your laptop? > > > > > > > > Alex, can you help? Code for toggle laptop version is > > > > originally yours. > > > > > > When I press the Fn key, a _Qxx EC method is executed. The > > > code path of this method depends on a variable set by > > > ARBT. > > > > > > When you call ARBT with 1 as argument, the variable is set > > > to 1 and the _Qxx method does nothing but sending a > > > notification (0x80) to RBTN whenever the function key is > > > pressed. > > > > > > When you call ARBT with 0 as argument, the variable is set > > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_ > > > toggle the state of the radio devices whenever the > > > function key is pressed. > > > > > > So in the end nothing _really_ breaks. > > > > So in linux kernel is missing code for toggling state of > > radio devices? And you can do that only by ACPI when ARBT > > is called with 0, right? > > Yes. > > With Alex's code the kernel sends keypresses to userspace and > userspace takes care of toggling the state of radio devices. Alex, can you ask Dell for documentation how to enable/disable radio devices? Because when ARBT is set to 1, then system must take care of it but, linux does not support it yet... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > > > > > > This is an ACPI driver for Dell laptops which receive HW > > > > > > > > > switch events. > > > > > > > > > It exports rfkill device dell-rbtn which provide correct hard > > > > > > > > > rfkill state. > > > > > > > > > > > > > > > > > > Alex Hung added code for supporting Dell laptops which have > > > > > > > > > toggle button > > > > > > > > > instead HW slider switch. On these laptops toggle button > > > > > > > > > event is reported > > > > > > > > > by new input device (instead rfkill) as they do not have hw > > > > > > > > > radio switch. > > > > > > > > > > > > > > > > > > It looks like those are two different functions (rfkill, > > > > > > > > > input device), but > > > > > > > > > Dell BIOS exports them via same ACPI device and uses same > > > > > > > > > ACPI functions. > > > > > > > > > So code is in one kernel driver. > > > > > > > > > > > > > > > > I made a patch some time ago that I've just adapted. It allows > > > > > > > > to > > > > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd > > > > > > > > like to > > > > > > > > have the hardware switch is that the BIOS doesn't alter the > > > > > > > > soft state > > > > > > > > of the devices. This comes in handy when the function key > > > > > > > > controls > > > > > > > > multiple radio devices. > > > > > > > > > > > > > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which > > > > > > > exports > > > > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > > > > > > > > > > > What is the presumed bug you are referring to? The fact that the > > > > > > soft state > > > > > > doesn't change? > > > > > > > > > > Can you remind me whats the problem on your laptop? > > > > > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if > > > > it returned 2 or 3, so we have to call ARBT. > > > > > > > > As said before, there's no way to know when a platform whose CRBT > > > > method returns 0 or 1 also has the hardware switch, so to be sure that > > > > all the platforms have working function keys, some of them (such as > > > > mine) have to give up on the hardware switch. > > > > > > Ok, and what happens when you load this v2 version? What stopped working > > > on your laptop? > > > > > > Alex, can you help? Code for toggle laptop version is originally yours. > > > > When I press the Fn key, a _Qxx EC method is executed. The code path > > of this method depends on a variable set by ARBT. > > > > When you call ARBT with 1 as argument, the variable is set to 1 and the > > _Qxx method does nothing but sending a notification (0x80) to RBTN > > whenever the function key is pressed. > > > > When you call ARBT with 0 as argument, the variable is set to 0 and > > the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the > > radio devices whenever the function key is pressed. > > > > So in the end nothing _really_ breaks. > > So in linux kernel is missing code for toggling state of radio devices? > And you can do that only by ACPI when ARBT is called with 0, right? Yes. With Alex's code the kernel sends keypresses to userspace and userspace takes care of toggling the state of radio devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > > > > > This is an ACPI driver for Dell laptops which receive HW switch > > > > > > > > events. > > > > > > > > It exports rfkill device dell-rbtn which provide correct hard > > > > > > > > rfkill state. > > > > > > > > > > > > > > > > Alex Hung added code for supporting Dell laptops which have > > > > > > > > toggle button > > > > > > > > instead HW slider switch. On these laptops toggle button event > > > > > > > > is reported > > > > > > > > by new input device (instead rfkill) as they do not have hw > > > > > > > > radio switch. > > > > > > > > > > > > > > > > It looks like those are two different functions (rfkill, input > > > > > > > > device), but > > > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI > > > > > > > > functions. > > > > > > > > So code is in one kernel driver. > > > > > > > > > > > > > > I made a patch some time ago that I've just adapted. It allows to > > > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like > > > > > > > to > > > > > > > have the hardware switch is that the BIOS doesn't alter the soft > > > > > > > state > > > > > > > of the devices. This comes in handy when the function key controls > > > > > > > multiple radio devices. > > > > > > > > > > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which > > > > > > exports > > > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > > > > > > > > > What is the presumed bug you are referring to? The fact that the soft > > > > > state > > > > > doesn't change? > > > > > > > > Can you remind me whats the problem on your laptop? > > > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if > > > it returned 2 or 3, so we have to call ARBT. > > > > > > As said before, there's no way to know when a platform whose CRBT > > > method returns 0 or 1 also has the hardware switch, so to be sure that > > > all the platforms have working function keys, some of them (such as > > > mine) have to give up on the hardware switch. > > > > Ok, and what happens when you load this v2 version? What stopped working > > on your laptop? > > > > Alex, can you help? Code for toggle laptop version is originally yours. > > When I press the Fn key, a _Qxx EC method is executed. The code path > of this method depends on a variable set by ARBT. > > When you call ARBT with 1 as argument, the variable is set to 1 and the > _Qxx method does nothing but sending a notification (0x80) to RBTN > whenever the function key is pressed. > > When you call ARBT with 0 as argument, the variable is set to 0 and > the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the > radio devices whenever the function key is pressed. > > So in the end nothing _really_ breaks. So in linux kernel is missing code for toggling state of radio devices? And you can do that only by ACPI when ARBT is called with 0, right? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > > > > This is an ACPI driver for Dell laptops which receive HW switch > > > > > > > events. > > > > > > > It exports rfkill device dell-rbtn which provide correct hard > > > > > > > rfkill state. > > > > > > > > > > > > > > Alex Hung added code for supporting Dell laptops which have > > > > > > > toggle button > > > > > > > instead HW slider switch. On these laptops toggle button event is > > > > > > > reported > > > > > > > by new input device (instead rfkill) as they do not have hw radio > > > > > > > switch. > > > > > > > > > > > > > > It looks like those are two different functions (rfkill, input > > > > > > > device), but > > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI > > > > > > > functions. > > > > > > > So code is in one kernel driver. > > > > > > > > > > > > I made a patch some time ago that I've just adapted. It allows to > > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > > > > > > have the hardware switch is that the BIOS doesn't alter the soft > > > > > > state > > > > > > of the devices. This comes in handy when the function key controls > > > > > > multiple radio devices. > > > > > > > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports > > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > > > > > > > What is the presumed bug you are referring to? The fact that the soft > > > > state > > > > doesn't change? > > > > > > Can you remind me whats the problem on your laptop? > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if > > it returned 2 or 3, so we have to call ARBT. > > > > As said before, there's no way to know when a platform whose CRBT > > method returns 0 or 1 also has the hardware switch, so to be sure that > > all the platforms have working function keys, some of them (such as > > mine) have to give up on the hardware switch. > > Ok, and what happens when you load this v2 version? What stopped working > on your laptop? > > Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > > > This is an ACPI driver for Dell laptops which receive HW switch > > > > > > events. > > > > > > It exports rfkill device dell-rbtn which provide correct hard > > > > > > rfkill state. > > > > > > > > > > > > Alex Hung added code for supporting Dell laptops which have toggle > > > > > > button > > > > > > instead HW slider switch. On these laptops toggle button event is > > > > > > reported > > > > > > by new input device (instead rfkill) as they do not have hw radio > > > > > > switch. > > > > > > > > > > > > It looks like those are two different functions (rfkill, input > > > > > > device), but > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI > > > > > > functions. > > > > > > So code is in one kernel driver. > > > > > > > > > > I made a patch some time ago that I've just adapted. It allows to > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > > > > > have the hardware switch is that the BIOS doesn't alter the soft state > > > > > of the devices. This comes in handy when the function key controls > > > > > multiple radio devices. > > > > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > > > > > What is the presumed bug you are referring to? The fact that the soft > > > state > > > doesn't change? > > > > Can you remind me whats the problem on your laptop? > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if > it returned 2 or 3, so we have to call ARBT. > > As said before, there's no way to know when a platform whose CRBT > method returns 0 or 1 also has the hardware switch, so to be sure that > all the platforms have working function keys, some of them (such as > mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > > This is an ACPI driver for Dell laptops which receive HW switch > > > > > events. > > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill > > > > > state. > > > > > > > > > > Alex Hung added code for supporting Dell laptops which have toggle > > > > > button > > > > > instead HW slider switch. On these laptops toggle button event is > > > > > reported > > > > > by new input device (instead rfkill) as they do not have hw radio > > > > > switch. > > > > > > > > > > It looks like those are two different functions (rfkill, input > > > > > device), but > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI > > > > > functions. > > > > > So code is in one kernel driver. > > > > > > > > I made a patch some time ago that I've just adapted. It allows to > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > > > > have the hardware switch is that the BIOS doesn't alter the soft state > > > > of the devices. This comes in handy when the function key controls > > > > multiple radio devices. > > > > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports > > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > > > What is the presumed bug you are referring to? The fact that the soft state > > doesn't change? > > Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > > This is an ACPI driver for Dell laptops which receive HW switch events. > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill > > > > state. > > > > > > > > Alex Hung added code for supporting Dell laptops which have toggle > > > > button > > > > instead HW slider switch. On these laptops toggle button event is > > > > reported > > > > by new input device (instead rfkill) as they do not have hw radio > > > > switch. > > > > > > > > It looks like those are two different functions (rfkill, input device), > > > > but > > > > Dell BIOS exports them via same ACPI device and uses same ACPI > > > > functions. > > > > So code is in one kernel driver. > > > > > > I made a patch some time ago that I've just adapted. It allows to > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > > > have the hardware switch is that the BIOS doesn't alter the soft state > > > of the devices. This comes in handy when the function key controls > > > multiple radio devices. > > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports > > phy rfkill)? Or problem somewhere else (userspace or kernel)? > > What is the presumed bug you are referring to? The fact that the soft state > doesn't change? Can you remind me whats the problem on your laptop? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > > This is an ACPI driver for Dell laptops which receive HW switch events. > > > It exports rfkill device dell-rbtn which provide correct hard rfkill > > > state. > > > > > > Alex Hung added code for supporting Dell laptops which have toggle button > > > instead HW slider switch. On these laptops toggle button event is reported > > > by new input device (instead rfkill) as they do not have hw radio switch. > > > > > > It looks like those are two different functions (rfkill, input device), > > > but > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions. > > > So code is in one kernel driver. > > > > I made a patch some time ago that I've just adapted. It allows to > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > > have the hardware switch is that the BIOS doesn't alter the soft state > > of the devices. This comes in handy when the function key controls > > multiple radio devices. > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports > phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: > > This is an ACPI driver for Dell laptops which receive HW switch events. > > It exports rfkill device dell-rbtn which provide correct hard rfkill state. > > > > Alex Hung added code for supporting Dell laptops which have toggle button > > instead HW slider switch. On these laptops toggle button event is reported > > by new input device (instead rfkill) as they do not have hw radio switch. > > > > It looks like those are two different functions (rfkill, input device), but > > Dell BIOS exports them via same ACPI device and uses same ACPI functions. > > So code is in one kernel driver. > > I made a patch some time ago that I've just adapted. It allows to > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to > have the hardware switch is that the BIOS doesn't alter the soft state > of the devices. This comes in handy when the function key controls > multiple radio devices. > Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> This is an ACPI driver for Dell laptops which receive HW switch events.
> It exports rfkill device dell-rbtn which provide correct hard rfkill state.
>
> Alex Hung added code for supporting Dell laptops which have toggle button
> instead HW slider switch. On these laptops toggle button event is reported
> by new input device (instead rfkill) as they do not have hw radio switch.
>
> It looks like those are two different functions (rfkill, input device), but
> Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> So code is in one kernel driver.
I made a patch some time ago that I've just adapted. It allows to
prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
have the hardware switch is that the BIOS doesn't alter the soft state
of the devices. This comes in handy when the function key controls
multiple radio devices.
Here below the simple patch. Maybe I could improve it and allow a
dynamic switch between RBTN_TOGGLE and RBTN_SLIDER.
>From 35d39a4ad079489147b4ce22651c5e4e18856cf0 Mon Sep 17 00:00:00 2001
From: Gabriele Mazzotta
Date: Wed, 29 Apr 2015 12:24:52 +0200
Subject: [PATCH] dell-rbtn: Add module param to force the radio hardware
switch
dell-rbtn determines whether the BIOS controls the radio devices when
function keys are pressed by calling the ACPI method CRBT. As long as
the ACPI method ARBT is called with 1 as argument, we are sure that
what is returned by CRBT holds.
This patch adds the possibility to pass a parameter that will make
dell-rbtn ignore the value returned by CRBT and call ARBT with 0 as
argument. This will allow users to have the BIOS control the radio
devices. Since there is no way to know when this is possible, it's
up to the user to force the mode. This guarantees the correct
functionality of the driver except when the user forces the mode.
---
drivers/platform/x86/dell-rbtn.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 07dfd8f..8f8d62b 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -30,6 +30,8 @@ struct rbtn_data {
struct input_dev *input_dev;
};
+static bool force_hw_switch;
+module_param(force_hw_switch, bool, S_IRUGO);
/*
* acpi functions
@@ -44,6 +46,9 @@ static enum rbtn_type rbtn_check(struct acpi_device *device)
if (ACPI_FAILURE(status))
return RBTN_UNKNOWN;
+ if (force_hw_switch)
+ return RBTN_SLIDER;
+
switch (output) {
case 0:
case 1:
@@ -321,7 +326,7 @@ static int rbtn_add(struct acpi_device *device)
return -EINVAL;
}
- ret = rbtn_radio_enable(device, true);
+ ret = rbtn_radio_enable(device, !force_hw_switch);
if (ret < 0) {
dev_err(>dev, "Cannot enable device\n");
return ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
This is an ACPI driver for Dell laptops which receive HW switch events.
It exports rfkill device dell-rbtn which provide correct hard rfkill state.
Alex Hung added code for supporting Dell laptops which have toggle button
instead HW slider switch. On these laptops toggle button event is reported
by new input device (instead rfkill) as they do not have hw radio switch.
It looks like those are two different functions (rfkill, input device), but
Dell BIOS exports them via same ACPI device and uses same ACPI functions.
So code is in one kernel driver.
I made a patch some time ago that I've just adapted. It allows to
prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
have the hardware switch is that the BIOS doesn't alter the soft state
of the devices. This comes in handy when the function key controls
multiple radio devices.
Here below the simple patch. Maybe I could improve it and allow a
dynamic switch between RBTN_TOGGLE and RBTN_SLIDER.
From 35d39a4ad079489147b4ce22651c5e4e18856cf0 Mon Sep 17 00:00:00 2001
From: Gabriele Mazzotta gabriele@gmail.com
Date: Wed, 29 Apr 2015 12:24:52 +0200
Subject: [PATCH] dell-rbtn: Add module param to force the radio hardware
switch
dell-rbtn determines whether the BIOS controls the radio devices when
function keys are pressed by calling the ACPI method CRBT. As long as
the ACPI method ARBT is called with 1 as argument, we are sure that
what is returned by CRBT holds.
This patch adds the possibility to pass a parameter that will make
dell-rbtn ignore the value returned by CRBT and call ARBT with 0 as
argument. This will allow users to have the BIOS control the radio
devices. Since there is no way to know when this is possible, it's
up to the user to force the mode. This guarantees the correct
functionality of the driver except when the user forces the mode.
---
drivers/platform/x86/dell-rbtn.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 07dfd8f..8f8d62b 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -30,6 +30,8 @@ struct rbtn_data {
struct input_dev *input_dev;
};
+static bool force_hw_switch;
+module_param(force_hw_switch, bool, S_IRUGO);
/*
* acpi functions
@@ -44,6 +46,9 @@ static enum rbtn_type rbtn_check(struct acpi_device *device)
if (ACPI_FAILURE(status))
return RBTN_UNKNOWN;
+ if (force_hw_switch)
+ return RBTN_SLIDER;
+
switch (output) {
case 0:
case 1:
@@ -321,7 +326,7 @@ static int rbtn_add(struct acpi_device *device)
return -EINVAL;
}
- ret = rbtn_radio_enable(device, true);
+ ret = rbtn_radio_enable(device, !force_hw_switch);
if (ret 0) {
dev_err(device-dev, Cannot enable device\n);
return ret;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. So in linux kernel is missing code for toggling state of radio devices? And you can do that only by ACPI when ARBT is called with 0, right? Yes. With Alex's code the kernel sends keypresses to userspace and userspace takes care of toggling the state of radio devices. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. So in linux kernel is missing code for toggling state of radio devices? And you can do that only by ACPI when ARBT is called with 0, right? Yes. With Alex's code the kernel sends keypresses to userspace and userspace takes care of toggling the state of radio devices. Alex, can you ask Dell for documentation how to enable/disable radio devices? Because when ARBT is set to 1, then system must take care of it but, linux does not support it yet... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. When I press the Fn key, a _Qxx EC method is executed. The code path of this method depends on a variable set by ARBT. When you call ARBT with 1 as argument, the variable is set to 1 and the _Qxx method does nothing but sending a notification (0x80) to RBTN whenever the function key is pressed. When you call ARBT with 0 as argument, the variable is set to 0 and the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the radio devices whenever the function key is pressed. So in the end nothing _really_ breaks. So in linux kernel is missing code for toggling state of radio devices? And you can do that only by ACPI when ARBT is called with 0, right? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? Can you remind me whats the problem on your laptop? CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if it returned 2 or 3, so we have to call ARBT. As said before, there's no way to know when a platform whose CRBT method returns 0 or 1 also has the hardware switch, so to be sure that all the platforms have working function keys, some of them (such as mine) have to give up on the hardware switch. Ok, and what happens when you load this v2 version? What stopped working on your laptop? Alex, can you help? Code for toggle laptop version is originally yours. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote: On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote: On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote: This is an ACPI driver for Dell laptops which receive HW switch events. It exports rfkill device dell-rbtn which provide correct hard rfkill state. Alex Hung added code for supporting Dell laptops which have toggle button instead HW slider switch. On these laptops toggle button event is reported by new input device (instead rfkill) as they do not have hw radio switch. It looks like those are two different functions (rfkill, input device), but Dell BIOS exports them via same ACPI device and uses same ACPI functions. So code is in one kernel driver. I made a patch some time ago that I've just adapted. It allows to prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to have the hardware switch is that the BIOS doesn't alter the soft state of the devices. This comes in handy when the function key controls multiple radio devices. Now I'm thinking... is't this bug in wifi kernel driver (which exports phy rfkill)? Or problem somewhere else (userspace or kernel)? What is the presumed bug you are referring to? The fact that the soft state doesn't change? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
