On Sat, 13 Dec 2008, Matthew Garrett wrote: > On Sat, Dec 13, 2008 at 11:28:57AM -0200, Henrique de Moraes Holschuh wrote: > > > Len, I would still like to export the 3 values learned about in this > > > event to userspace. Is it alright for me to create 3 read-only files on > > > the platform device? (docked, lid, radios) > > > It would if anything simplify the code. > > > > FWIW, I think this is also the way to go. It is much easier for > > userspace to deal with sysfs attributes. HAL can deal with more > > complex stuff, but shell script writers often don't know how to, nor > > care to, deal with HAL. > > I feel like I'm missing something here, but surely what we're talking > about is simply a single rfkill device that affects all radios and as > such should have a new RFKILL_TYPE_ALL type associated with it? I'd read > this as there being a software control that affected all radios. If > there's no software control at all then I agree that providing an rfkill > class here isn't appropriate. There isn't a "type all" rfkill class. I have patches that export the rfkill core global states, and one of the global states looks like an "all switch" indeed (the Emergency Power Off global state). I did try an "one rfkill class for each type, and a master rfkill class" approach a few months ago, and it didn't fly. I think I even deleted it because it was too ugly to see the light of the day, or something. I will post what I have soon. I am not happy with it, but it might be interesting to see if someone can come up with a better approach. -- "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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
