Re: [PATCH] RFKILL - Add support for input key to control wireless radio

Re: [PATCH] RFKILL - Add support for input key to control wireless radio

[Dmitry Torokhov]

Hi ivo,

On 8/27/06, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> Hi,
>
> This driver has previously be send to the netdev list for inclusion
> in the wireless-dev tree. But before it can be applied there this
> patch needs  an stamp of approoval from the Input layer maintainer.
>
> Modern (and even older) laptops often have a key to enable or disable
> the radio of a wireless device (WIFI, IRDA, Bluetooth, etc).
> It is however not always the case that the button controls the hardware
> directly. The rfkill driver will provide a uniform interface for hardware
> drivers to hook the button on and to provide a single method to report
> the state of the button to userspace.
>
> For each button a input device is created, after which rfkill will start polling
> for the button state. The polling will only occur if the button requires polling,
> but rfkill also provide a handler for the hardware driver to report the button
> status to rfkill. Once the status of any button has changed (detected either
> by polling or by notification from hardware driver) it will go through all
> registered hardware and will enable/disable the radio of the device if the
> input device has not been opened by the user. If the input device has been
> openend by the user the radio will not be touched and the event will be send
> to userspace to allow userspace to deal with the situation.
>

I am not sure if this is a correct approach, kernel should not assume
that the reason why input device was opened is to control the state of
the transmitter. For example one could be happy with hardware toggling
the state but still want to have for example a GKrellm showing state
of the transmitter.

Also please explain how userspace would control the state of
transmitter once KEY_RFKILL is received - there seems to be only
kernel->userspace link, but not userspace->kernel.

I would rather see you implemented a transmitter control framework
that would export couple of sysfs attributes. One attribute would
enable/disable controlling transmitter state automatically by the
driver and another  would allow controlling transmitter from
userspace. Then input device would always deliver events to userspace
(btw, it probably shoudl be switch, not a key event) and it would be
up to userspace program to explicitely take control over.

-- 
Dmitry

Re: [PATCH] RFKILL - Add support for input key to control wireless radio

[Ivo van Doorn]

Hi,

> > This driver has previously be send to the netdev list for inclusion
> > in the wireless-dev tree. But before it can be applied there this
> > patch needs  an stamp of approoval from the Input layer maintainer.
> >
> > Modern (and even older) laptops often have a key to enable or disable
> > the radio of a wireless device (WIFI, IRDA, Bluetooth, etc).
> > It is however not always the case that the button controls the hardware
> > directly. The rfkill driver will provide a uniform interface for hardware
> > drivers to hook the button on and to provide a single method to report
> > the state of the button to userspace.
> >
> > For each button a input device is created, after which rfkill will start polling
> > for the button state. The polling will only occur if the button requires polling,
> > but rfkill also provide a handler for the hardware driver to report the button
> > status to rfkill. Once the status of any button has changed (detected either
> > by polling or by notification from hardware driver) it will go through all
> > registered hardware and will enable/disable the radio of the device if the
> > input device has not been opened by the user. If the input device has been
> > openend by the user the radio will not be touched and the event will be send
> > to userspace to allow userspace to deal with the situation.
> >
> 
> I am not sure if this is a correct approach, kernel should not assume
> that the reason why input device was opened is to control the state of
> the transmitter. For example one could be happy with hardware toggling
> the state but still want to have for example a GKrellm showing state
> of the transmitter.

Valid point, but when the radio is disabled a wireless interface should
report a txpower of 0. I don't know if this is also the case for bluetooth or irda..

> Also please explain how userspace would control the state of
> transmitter once KEY_RFKILL is received - there seems to be only
> kernel->userspace link, but not userspace->kernel.

Plain ifconfig actually, the rfkill is intentionally a simple kernel->userspace
notification. There are already various ways a interface can be disabled and
adding more would in my opinion not be a good thing.
The reason for a hardware key event is to do something additionally besides
simply turning down the radio of the (registered interfaces) because he might
have additional interfaces to be shutdown, or there has to be done something
with the interface before the radio is switched off.

> I would rather see you implemented a transmitter control framework
> that would export couple of sysfs attributes. One attribute would
> enable/disable controlling transmitter state automatically by the
> driver and another  would allow controlling transmitter from
> userspace. Then input device would always deliver events to userspace
> (btw, it probably shoudl be switch, not a key event) and it would be
> up to userspace program to explicitely take control over.

This can indeed be done, would it not also make the input device redundant?
Since userspace could also just poll a sysfs entry, and I on the netdev list the
input device seemed to be prefered over sysfs polling.

Ivo

Re: [PATCH] RFKILL - Add support for input key to control wireless radio

[Dmitry Torokhov]

On Monday 28 August 2006 16:15, Ivo van Doorn wrote:
> > 
> > I am not sure if this is a correct approach, kernel should not assume
> > that the reason why input device was opened is to control the state of
> > the transmitter. For example one could be happy with hardware toggling
> > the state but still want to have for example a GKrellm showing state
> > of the transmitter.
> 
> Valid point, but when the radio is disabled a wireless interface should
> report a txpower of 0. I don't know if this is also the case for bluetooth or irda..
> 

Exactly...

> > Also please explain how userspace would control the state of
> > transmitter once KEY_RFKILL is received - there seems to be only
> > kernel->userspace link, but not userspace->kernel.
> 
> Plain ifconfig actually, the rfkill is intentionally a simple kernel->userspace
> notification. There are already various ways a interface can be disabled and
> adding more would in my opinion not be a good thing.
> The reason for a hardware key event is to do something additionally besides
> simply turning down the radio of the (registered interfaces) because he might
> have additional interfaces to be shutdown, or there has to be done something
> with the interface before the radio is switched off.
> 

Well, this assumes that you have a network interface which may not be the
case. For example I could have a bluetooth keyboard or mouse instead of
network card. And you are proposing a generic solution...

> > I would rather see you implemented a transmitter control framework
> > that would export couple of sysfs attributes. One attribute would
> > enable/disable controlling transmitter state automatically by the
> > driver and another  would allow controlling transmitter from
> > userspace. Then input device would always deliver events to userspace
> > (btw, it probably shoudl be switch, not a key event) and it would be
> > up to userspace program to explicitely take control over.
> 
> This can indeed be done, would it not also make the input device redundant?
> Since userspace could also just poll a sysfs entry, and I on the netdev list the
> input device seemed to be prefered over sysfs polling.
>

Input device is good since then userspace connects to all of them and
waits for that specific event. The key (or switch) may even be generated
by another device (for example reassigning a key on my AT keyboard).
But I would probably keep RF control and input device separate instead of
mixing into one abstraction layer.

-- 
Dmitry

Re: [PATCH] RFKILL - Add support for input key to control wireless radio

[Ivo van Doorn]

Hi,

> > > I am not sure if this is a correct approach, kernel should not assume
> > > that the reason why input device was opened is to control the state of
> > > the transmitter. For example one could be happy with hardware toggling
> > > the state but still want to have for example a GKrellm showing state
> > > of the transmitter.
> > 
> > Valid point, but when the radio is disabled a wireless interface should
> > report a txpower of 0. I don't know if this is also the case for bluetooth or irda..
> > 
> 
> Exactly...
> 
> > > Also please explain how userspace would control the state of
> > > transmitter once KEY_RFKILL is received - there seems to be only
> > > kernel->userspace link, but not userspace->kernel.
> > 
> > Plain ifconfig actually, the rfkill is intentionally a simple kernel->userspace
> > notification. There are already various ways a interface can be disabled and
> > adding more would in my opinion not be a good thing.
> > The reason for a hardware key event is to do something additionally besides
> > simply turning down the radio of the (registered interfaces) because he might
> > have additional interfaces to be shutdown, or there has to be done something
> > with the interface before the radio is switched off.
> > 
> 
> Well, this assumes that you have a network interface which may not be the
> case. For example I could have a bluetooth keyboard or mouse instead of
> network card. And you are proposing a generic solution...

Correct me if I am wrong, but a IRDA and Bluetooth device will still have
userspace representation with a standard userspace tool right.
And with such a tool it would be normal to have a on/off switch for the radio
I would expect (and would find strange if such a switch is not there)
I have never used bluetooth or IRDA device so I can't talk from
experience here.

> > > I would rather see you implemented a transmitter control framework
> > > that would export couple of sysfs attributes. One attribute would
> > > enable/disable controlling transmitter state automatically by the
> > > driver and another  would allow controlling transmitter from
> > > userspace. Then input device would always deliver events to userspace
> > > (btw, it probably shoudl be switch, not a key event) and it would be
> > > up to userspace program to explicitely take control over.
> > 
> > This can indeed be done, would it not also make the input device redundant?
> > Since userspace could also just poll a sysfs entry, and I on the netdev list the
> > input device seemed to be prefered over sysfs polling.
> >
> 
> Input device is good since then userspace connects to all of them and
> waits for that specific event. The key (or switch) may even be generated
> by another device (for example reassigning a key on my AT keyboard).
> But I would probably keep RF control and input device separate instead of
> mixing into one abstraction layer.

Ok, that would make sense. I'll try to add the sysfs attributes you recommended.
I'll also have to add bluetooth/irda/bluetooth message seperation, since
at the moment pressing the wifi button for example would also
disable bluetooth devices and that is likely not desired by the users, (I already have
received objections about it, with requests to change that behaviour)

Ivo