On Sat, Feb 19, 2011 at 04:00:38PM +0000, Matthew Garrett wrote: > On Sat, Feb 19, 2011 at 09:46:54PM +0900, Mattia Dongili wrote: > > On Sat, Feb 19, 2011 at 03:06:18AM +0000, Matthew Garrett wrote: > > > Do you possibly want to catch these and make sure the kernel rfkill > > > state matches the hardware? > > > > hmmmm, to be honest I'm not entirely sure what the actual problem is. > > Maybe it's just a timing issue that is made better by avoiding the > > input/acpi event generation. For now drop this patch (there is a > > different workaround using the mask parameter). > > Delivering it to userspace can be racy - rfkill-input will try to toggle > the state as well. So I think this is the right thing to do, but you > might also want to use it to check the current hardware state and update > the state of the rfkill device. Ah, alright. This makes a lot of sense with what was seen on Thomas' laptop. Then if you are ok to keep this patch as is, I'll work on matching/flipping the rfkill device state separately. Thanks -- mattia :wq! -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
