On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> On Tuesday 04 September 2007, dragoran wrote:
> > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > On Tuesday 04 September 2007, dragoran wrote:
> > > > On 9/4/07, Ivo van Doorn <[email protected]> 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?
>
> By default the kernel will act when the rfkill button is pressed, it will loop
> through all registered buttons of the same type and change the state.
> Userspace can read the "state" sysfs file to see the current status,
> but if a userspace tools wants to take control of taking action when the button is pressed,
> or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
> tell the kernel that it should back off and ignore all events.
ok thx for explaining this will talk to the nm and hal people about it
and see how they want things to work than I will create patches to
implement it.
which drivers support it now? rt2x00 and ?? or are they the only ones right now?
On Thursday 06 September 2007, Dan Williams wrote:
> On Wed, 2007-09-05 at 21:33 +0200, dragoran wrote:
> > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > On Tuesday 04 September 2007, dragoran wrote:
> > > > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > > > On Tuesday 04 September 2007, dragoran wrote:
> > > > > > On 9/4/07, Ivo van Doorn <[email protected]> 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?
> > >
> > > By default the kernel will act when the rfkill button is pressed, it will loop
> > > through all registered buttons of the same type and change the state.
> > > Userspace can read the "state" sysfs file to see the current status,
> > > but if a userspace tools wants to take control of taking action when the button is pressed,
> > > or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
> > > tell the kernel that it should back off and ignore all events.
> >
> > ok thx for explaining this will talk to the nm and hal people about it
> > and see how they want things to work than I will create patches to
> > implement it.
> > which drivers support it now? rt2x00 and ?? or are they the only ones right now?
>
> Since it's in the kernel, the next step is to get HAL aware of the
> killswitches through sysfs and not through fdi files keyed on
> Dell/Sony/etc.
>
> Ivo: how does one tell whether or not the switch needs to be polled?
> That's something that HAL will need to deal with polling/non-polling
> intelligently. I assume that either the layer or the driver
> implementing the button will know that it needs to be polled and should
> be the thing that sets the value. Ideally just an attribute in sysfs
> like "require-poll" with a value of 1 or 0 or something like that.
No, because like I explained userspace is not in control of polling,
because there should be no userspace dependency. This means that
if the device requires polling, it should register itself with the input_polldev handler.
This way the radio button will allwats work as expected, without requiring
some version of HAL..
Ivo
> > By default the kernel will act when the rfkill button is pressed, it will loop
> > through all registered buttons of the same type and change the state.
> > Userspace can read the "state" sysfs file to see the current status,
> > but if a userspace tools wants to take control of taking action when the button is pressed,
> > or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
> > tell the kernel that it should back off and ignore all events.
>
> ok thx for explaining this will talk to the nm and hal people about it
> and see how they want things to work than I will create patches to
> implement it.
> which drivers support it now? rt2x00 and ?? or are they the only ones right now?
In wireless-dev it is currently only rt2x00,
But I have heard about work in progress for:
wistron_btns
thinkpad_acpi
MSI S270
I am however not sure about their status.
Ivo
On Thu, 2007-09-06 at 18:49 +0200, Ivo van Doorn wrote:
> On Thursday 06 September 2007, Dan Williams wrote:
> > On Wed, 2007-09-05 at 21:33 +0200, dragoran wrote:
> > > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > > On Tuesday 04 September 2007, dragoran wrote:
> > > > > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > > > > On Tuesday 04 September 2007, dragoran wrote:
> > > > > > > On 9/4/07, Ivo van Doorn <[email protected]> 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?
> > > >
> > > > By default the kernel will act when the rfkill button is pressed, it will loop
> > > > through all registered buttons of the same type and change the state.
> > > > Userspace can read the "state" sysfs file to see the current status,
> > > > but if a userspace tools wants to take control of taking action when the button is pressed,
> > > > or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
> > > > tell the kernel that it should back off and ignore all events.
> > >
> > > ok thx for explaining this will talk to the nm and hal people about it
> > > and see how they want things to work than I will create patches to
> > > implement it.
> > > which drivers support it now? rt2x00 and ?? or are they the only ones right now?
> >
> > Since it's in the kernel, the next step is to get HAL aware of the
> > killswitches through sysfs and not through fdi files keyed on
> > Dell/Sony/etc.
> >
> > Ivo: how does one tell whether or not the switch needs to be polled?
> > That's something that HAL will need to deal with polling/non-polling
> > intelligently. I assume that either the layer or the driver
> > implementing the button will know that it needs to be polled and should
> > be the thing that sets the value. Ideally just an attribute in sysfs
> > like "require-poll" with a value of 1 or 0 or something like that.
>
> No, because like I explained userspace is not in control of polling,
> because there should be no userspace dependency. This means that
> if the device requires polling, it should register itself with the input_polldev handler.
> This way the radio button will allwats work as expected, without requiring
> some version of HAL..
Awesome.
Dan
On Wed, 2007-09-05 at 21:33 +0200, dragoran wrote:
> On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > On Tuesday 04 September 2007, dragoran wrote:
> > > On 9/4/07, Ivo van Doorn <[email protected]> wrote:
> > > > On Tuesday 04 September 2007, dragoran wrote:
> > > > > On 9/4/07, Ivo van Doorn <[email protected]> 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?
> >
> > By default the kernel will act when the rfkill button is pressed, it will loop
> > through all registered buttons of the same type and change the state.
> > Userspace can read the "state" sysfs file to see the current status,
> > but if a userspace tools wants to take control of taking action when the button is pressed,
> > or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
> > tell the kernel that it should back off and ignore all events.
>
> ok thx for explaining this will talk to the nm and hal people about it
> and see how they want things to work than I will create patches to
> implement it.
> which drivers support it now? rt2x00 and ?? or are they the only ones right now?
Since it's in the kernel, the next step is to get HAL aware of the
killswitches through sysfs and not through fdi files keyed on
Dell/Sony/etc.
Ivo: how does one tell whether or not the switch needs to be polled?
That's something that HAL will need to deal with polling/non-polling
intelligently. I assume that either the layer or the driver
implementing the button will know that it needs to be polled and should
be the thing that sets the value. Ideally just an attribute in sysfs
like "require-poll" with a value of 1 or 0 or something like that.
Dan