Re: [ibm-acpi-devel] bluetooth off state not remembered accross reboots?
On Sat, 2009-12-05 at 18:12 -0200, Henrique de Moraes Holschuh wrote: > On Sat, 05 Dec 2009, Kevin Locke wrote: >> Rfkill pretends that the master switch was set in its current position >> at startup by using an EV_SW event on devices that support them. So > > Actually, no, rfkill doesn't pretend anything. > > The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi) > *push* EV_SW events to rfkill with the current state. Except that it is also sent internally in rfkill when the input device is registered by rfkill_start at input.c:252 (without any request from the individual driver afaict - other than support for EV_SW), which is where the problem is happening. > Fixing this is possible, but quite troublesome (we need to register an input > device signature permanently in the rfkill core, and remember it across > input device attach/detach, and do the right thing if it attaches twice > because there are two such devices in the system, etc). > > In the most common use case (modules are loaded at boot and left alone after > that) it causes no problem, so I don't think it will get fixed anytime soon. So states being preserved across reboots is not considered part of the common use case? I can live with that, although it is frustrating. >> The reason that master_switch_mode=1 is broken is that when a new >> input device is registered, the rfkill_handler specifies rfkill_start >> to be called for the new handle, which schedules an >> rfkill_restore_states to be called before rfkill_eop is ever called. >> So the 0-initialized (unblocked) save state is loaded for all devices. > > master_switch_mode=1 should set it to whatever the default state is (there's > a module parameter to set that, I use "1" since I want radios blocked by > default) if no epo ever happened (i.e. it doesn't have a state to go back > to), or maybe do nothing at all if epo never happened before. Note: I > didn't check what it is doing right now. If it is broken, I think a patch > fixing this would be accepted by the rfkill maintainer. Yep, it's a 1-liner fix. I'll work on it. Kevin -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] bluetooth off state not remembered accross reboots?
On Sat, 05 Dec 2009, Kevin Locke wrote: > Rfkill pretends that the master switch was set in its current position > at startup by using an EV_SW event on devices that support them. So Actually, no, rfkill doesn't pretend anything. The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi) *push* EV_SW events to rfkill with the current state. The input layer does level-to-edge conversion, but that cannot be done at driver load (we don't know the previous state), so in practice, you will tell the rfkill core that the rfkill switch has just been enabled/disabled when any such module loads. This is why you see rfkill EV_SW SW_RFKILL_ALL-related activity when you rmmod and then modprobe thinkpad-acpi back again. Fixing this is possible, but quite troublesome (we need to register an input device signature permanently in the rfkill core, and remember it across input device attach/detach, and do the right thing if it attaches twice because there are two such devices in the system, etc). In the most common use case (modules are loaded at boot and left alone after that) it causes no problem, so I don't think it will get fixed anytime soon. But if it is pestering you enough to write the code, you could ask the rfkill maintainer if he would accept such a patch (feel free to have me in the Cc). > when master_switch_mode=0 everything gets set to blocked, when > master_switch_mode=2 everything gets set to unblocked. This is by > design (and 2 is the default). The problem is that > master_switch_mode=1 does not behave well at all and default_state is > ignored. > The reason that master_switch_mode=1 is broken is that when a new > input device is registered, the rfkill_handler specifies rfkill_start > to be called for the new handle, which schedules an > rfkill_restore_states to be called before rfkill_eop is ever called. > So the 0-initialized (unblocked) save state is loaded for all devices. master_switch_mode=1 should set it to whatever the default state is (there's a module parameter to set that, I use "1" since I want radios blocked by default) if no epo ever happened (i.e. it doesn't have a state to go back to), or maybe do nothing at all if epo never happened before. Note: I didn't check what it is doing right now. If it is broken, I think a patch fixing this would be accepted by the rfkill maintainer. > initialized). However, this doesn't provide a way for thinkpad_acpi > to inform rfkill what the default state of each type should really be. We inform the core about the default state for the rfkill devices managed by thinkpad-acpi. It used to take that information from the first device of a given type that registers itself to be also the default for that type. I don't know if it still does that. > So, unless I am overlooking something, I think rfkill needs a new API > call to set the default state for each type of radio that tpacpi could > use before this bug can be fixed. It used to have one. If it still does have one, it is a bug that we're not using it. However, it now knows when a device is of the "persistent" type, and it could well set the global state for a type to the state of the first device of that type that gets registered *if* that device is "persistent". After it happens for the first type (or if the first device of a given type that registers itself is not persistent), the oportunity is gone and whatever device that registers itself is to be brought to the same state of the other devices of the same type (unless hardware blocked, etc). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] bluetooth off state not remembered accross reboots?
On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote: > Ok, so it is the rfkill-input stuff (that is now part of the rfkill core) > that is showing the problem (the bug might be elsewhere). We need to track > the state of the rfkill input device to know what's broken, then. OK. I think I have a pretty good understanding of what is going on now. Rfkill pretends that the master switch was set in its current position at startup by using an EV_SW event on devices that support them. So when master_switch_mode=0 everything gets set to blocked, when master_switch_mode=2 everything gets set to unblocked. This is by design (and 2 is the default). The problem is that master_switch_mode=1 does not behave well at all and default_state is ignored. The reason that master_switch_mode=1 is broken is that when a new input device is registered, the rfkill_handler specifies rfkill_start to be called for the new handle, which schedules an rfkill_restore_states to be called before rfkill_eop is ever called. So the 0-initialized (unblocked) save state is loaded for all devices. default_state can be fixed by initializing the saved state to the default state in rfkill_init (currently only the current state is initialized). However, this doesn't provide a way for thinkpad_acpi to inform rfkill what the default state of each type should really be. So, unless I am overlooking something, I think rfkill needs a new API call to set the default state for each type of radio that tpacpi could use before this bug can be fixed. If this analysis seems correct, I can try taking this up with the rfkill maintainers. -- Cheers, | ke...@kevinlocke.name | JIM: kevin...@jabber.org Kevin| http://kevinlocke.name | IRC: kevinoid on freenode -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
