On Wed, 2007-04-11 at 20:17 -0500, Michael E Brown wrote: > On Wed, Apr 11, 2007 at 07:50:00PM -0400, Dan Williams wrote: > > On Wed, 2007-04-11 at 17:28 -0500, Michael E Brown wrote: > > > Dell systems can use dellWirelessCtl -> userspace binary to control > > > wireless kill switch. This binary is in libsmbios-bins, currently in > > > Fedora 7 and Fedora Extras for FC6. > > > > > > David Zeuthen recently committed support into HAL to interface with > > > dellWirelessCtl, so Dell laptops should soon work ok. Contact David if > > > you have a Dell laptop of recent vintage (dellWirelessCtl -i to see if > > > it works on your box) and it doesnt 'just work'. > > > > There is a standard kernel interface for killswitches that is getting > > close to complete. There's a disgusting number of kill switch > > implementations [1] that it has to support, but it appears to do the > > job. Eventually, all vendor-specific stuff needs to be ported to use > > it, which shouldn't be too hard. HAL then needs to be hooked up to > > that, and NetworkManager will just use the generic HAL interfaces to > > deal with rfkill. > > > Why do we need a kernel interface for this? Why not libkillswitch.so.1 > and /usr/lib/killswitch-plugins/? Then, you could write > libsysfskillswitch.so.1 and drop it into the plugins directory, and I > could write libdellkillswitch.so.1 and drop it into the plugins > directory. > > I dont see the utility of having a kernel driver for this when 99.9% of > the code I need to implement my killswitch control for Dell laptops is It's userspace for _your_ laptop. But on lots of other laptops, it needs kernel support because the wireless driver, for example, gets in interrupt from the card or has to _poll_ a register. This stuff has _got_ to be standardized, and that means that some pieces are in the kernel because some hardware needs it their, even if not your hardware. Furthermore, we don't want to have 10 different 'iwpriv' commands for each driver, like the ipw driver has one now. There has got to be a standard kernel interface to control the radio. > userspace. I only need the 'dcdbas' driver to run the SMI call to > enable/disable. The rest of the code I need, reading the smbios table to > get the Dell proprietary tables structures which tell me the index io > port for the SMI and the magic value for the SMI all happily resides in > userspace. (The dcdbas driver is a driver to run SMIs) > > > [1] Including: > > - Button triggers ACPI events from BIOS > > dell kill switch might do this, I dont know. Again; some vendors do it one way, others do it another. Even laptops from the same vendor implement rf kill differently depending on which wlan chipset they use. > > - Button is just another input layer (ie vendor-specific keyboard) > > button > > this is part of how the Dell one works (I see keypress events when you > toggle it) > > > - Button wired directly to baseband processor antenna path > > and it does this for wireless > > - Button toggles GPIO which sends signal to driver which kills RF > > - Button is a dual-state toggle rather than an up/down button > > - Button toggles USB power to module, drops off USB bus like hot-unplug > > and it does this for bluetooth > > And the other thing about the Dell killswitch, you can set it in > software to control any combination of WLAN, WWAN, and Bluetooth. Ie. I > can tell BIOS that kill switch *only* enables/disables bluetooth. Well this is more interesting then; because it shows up as an input layer event and also hard-kills the radio. This is yet another permutation that the standard stuff has to deal with. The point here is that this is not just userspace, it needs driver support too. And there must be a standard kernel API that works for all cards and drivers so that userspace programs don't have to code for 10 different rfkill solutions. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
