On Wed, 14 May 2008 14:21:15 +0200, "Thomas Renninger" <trenn@xxxxxxx> said: > Shouldn't the thinkpad driver do this automatically? *NO*. It belongs either to rfkill-input, or to userspace. And currently, it CANNOT be done in userspace because there isn't proper kernel support for it (see below). > If this should get routed through userspace, then probably a more > general interface than /sys/.../thinkpad_acpi/bluetooth_enable should > get used or this ends up in a vendor specific nightmare? rfkill support is being worked on, but as you probably know, the rfkill class is a barebones incomplete API, so I had to implement a LOT of missing functionality to it for it to even be worth using. I have made a lot of progress already, but it is not complete yet. The target is 2.6.27 merge window, so I will have to get the rfkill patches to LKML soon. Enough to support thinkpad-acpi (and the thinkpad-acpi glue) is finished, tested, and good... but I need to write some better documentation for rfkill, or nobody will use it right. I will speed up the submission of the initial set, which is enough to get rfkill support in thinkpad-acpi. That will get you out of the vendor-specific nightmare right away, at least as far as thinkpad-acpi is concerned. HOWEVER, properly interfacing userspace to rfkill requires the full patch set, which implements uevents and interfaces to rfkill that are required for one to get rid of rfkill-input. I will also send in those, but I bet I will have to change them a few times before they're perfect for mainline. > Is it correct that only kill switch events are directly passed to the > corresponding driver inside the kernel? I HEAVILY suggest not messing with ANYTHING related to rfkill until my changes get in mainline, or we could risk the backlight crap all again. It is sufficient to say that almost NOTHING in mainline is using rfkill correctly, so please don't try to make it work using userspace workarounds yet. Let's fix this properly before it bites us in the arse. PLEASE be patient for this. If you're interested in helping, the first bunch of patches is not more than a week away from hitting LKML, and I can explicitly CC any of you that asks me to in a reply :-) The design for the rfkill changes was debated on LKML in a somewhat long thread, if you want to get up to speed on the issues. Look for it on the last two month's archives. > WLAN/Bluetooth buttons are intended to be routed through userspace? Rfkill is somewhat more complicated than that. It ties the rfkill class, and input layer, and it is EXTREMELY easy to get it wrong. You will not be required to route input events through userspace if you use rfkill-input, so the kernel will provide basic "wireless key" support by itself (but it will be optional, so that better support can be done in userspace). You will be able to use the *generic* rfkill interface to control anything wireless-related in thinkpad-acpi. You will receive input events for the ThinkPad hardware rfkill switch (the event will be EV_SW SW_RFKILL_ALL, currently in mainline it is EV_SW SW_RADIO), and it will bring down ALL radios automatically in a way the kernel knows they're down (as opposed to what you have right now, they're down, but the kernel doesn't know it everywhere it should). And after I am done with rfkill, you will get uevents for any rfkill switches changing state, AND you will be able to implement rfkill-input in userspace should you want to, and you will be able to have network manager actually be able to control these switches without the castle of cards going down on you. THEN, people will have to FIX the drivers currently using rfkill and the input layer incorrectly (b43 is a known buggy one here), and add rfkill class support to any important drivers that still miss it (ipw2200 comes to mind)... and finally, we will have proper unified rfkill support in Linux that is even better than what you have in Microsoft Windows. All you'll need to do is to write pretty GUIs for it. > But Hal only passes them as dbus events which in turn need to be picked HAL will get the events it needs after the rfkill changes are accepted and therefore you will be able to change HAL to interface rfkill to DBUS. Right now, it cannot operate on rfkill in a sane way, so please don't even try. It would backfire on everyone later. > to another userspace/X-app) sounds rather error prone. IMO this should > also just be done in kernel (if possible)? We can certainly add a enable/disable runtime switch to rfkill-input, AND improve it so that it can drive the rfkill backends (the network drivers) properly in different ways (right now it just has enable/disable all devices of the same type). E.g., we could add "cycle through type combinations" like what the thinkpad does to Fn+F5 (none, BT, WLAN, BT+WLAN). But IMHO it is best to leave rfkill-input for very basic support, and do the more complicated stuff in userspace. I will be aiming to add support for that. Thanks for contacting me before trying to work around the current thinkpad-acpi rfkill issues in userspace. I *really* appreciate it. -- "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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
