On 9/4/07, Ivo van Doorn <ivdoorn@xxxxxxxxx> wrote:
> On Tuesday 04 September 2007, dragoran wrote:
> > On 9/4/07, Ivo van Doorn <ivdoorn@xxxxxxxxx> wrote:
> > > On Tuesday 04 September 2007, dragoran wrote:
> > > > >+static ssize_t show_rf_kill(struct device *d,
> > > > >+ struct device_attribute *attr, char *buf)
> > > > >+{
> > > > >+ /*
> > > > >+ * 0 - RF kill not enabled
> > > > >+ * 1 - SW based RF kill active (sysfs)
> > > > >+ * 2 - HW based RF kill active
> > > > >+ * 3 - Both HW and SW based RF kill active
> > > > >
> > > > >that as well, along with all the other sysfs bits. Also, how about using
> > > > >the generic rfkill infrastructure Ivo did?
> > > >
> > > > is the generic rfkill interface already stable and merged into the linus tree?
> > >
> > > Yes. It currently is only missing users.
> >
> > ok thats great ;) is the (userspace) interface defined somewhere? or
> > should I read the code to understand how it works? (would like to add
> > support to hal)
>
> There isn't a documentation file for it, so best thing to do would be looking at the code.
> basically hal only needs to check the sysfs files:
>
> name -> Name of device/interface
> type -> wlan, bluetooth, irda
> state -> Current device state. 0: Off, 1: On
> claim -> 0: Kernel handles events, 1: Userspace handles events
>
> "name" and "type" are read-only
> "claim" and "state" are read/writable
>
> Note that there is a bug in 2.6.22 which causes the "state" file to be read-only,
> this has been fixed in 2.6.23-rc.
ok that isn't complicated what is the claim used for?
does It has to be set to userspace to be able to toggle the status via software?
> > shouldn't the new interface send events so that polling isn't required?
>
> Not really, rfkill was intended for a generic interface, which would make
> the rfkill buttons work with or without intervention of userspace. So polling
> is required unless the hardware generates interrupts when the button is called.
ok
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
