> > So basicly 1 input device for every single wireless driver that implements
> > the RF-Kill button?
>
> Yes.
>
> > Is there any particular reason for not using 1 input device shared by all?
>
> Yes.
>
> In the unlikely case where there are two devices which implement a
> rfkill button in the
On Fri, Jun 23, 2006 at 08:51:33PM +0200, Ivo van Doorn wrote:
> > > This is of course not possible for all hardware, but it gives the most
> > > flexibility while keeping the possibility to switch of the radio without
> > > userspace support.
> >
> > Let me elaborate a little bit on the possibl
On Thursday 22 June 2006 17:55, Jiri Benc wrote:
> On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > With this approach more buttons can be registered,
> > it includes the optional field to report an update of the key status
> > to the driver that registered it, and it supports for non-p
Hi,
> > On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > > With this approach more buttons can be registered,
> > > it includes the optional field to report an update of the key status
> > > to the driver that registered it, and it supports for non-polling keys.
> >
> > I think this i
On Thu, Jun 22, 2006 at 05:55:46PM +0200, Jiri Benc wrote:
> On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > With this approach more buttons can be registered,
> > it includes the optional field to report an update of the key status
> > to the driver that registered it, and it support
On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> With this approach more buttons can be registered,
> it includes the optional field to report an update of the key status
> to the driver that registered it, and it supports for non-polling keys.
I think this is not specific to networking
> > Except for the bluetooth radio key (which should be supported by the
> > radiobtn interface as well) the other buttons have support through already
> > excisting input devices if I am correct.
>
> You are wrong for quite a bunch of laptop models. That's why I pointed you to
> the wistron_btns
On Sunday 4 June 2006 12:14, Stefan Rompf wrote:
> Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
>
> > Except for the bluetooth radio key (which should be supported by the
> > radiobtn interface as well) the other buttons have support through already
> > excisting input devices if I am corr
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
> Except for the bluetooth radio key (which should be supported by the
> radiobtn interface as well) the other buttons have support through already
> excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. Tha
On Saturday 3 June 2006 10:45, Stefan Rompf wrote:
> Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
>
> > > Or actually, I don't think the radiobtn/ won't be actually needed as
> > > prefix. The name passed to the radiobtn driver by the driver should be
> > > sufficient.
> >
> > Updated vers
Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
> > Or actually, I don't think the radiobtn/ won't be actually needed as
> > prefix. The name passed to the radiobtn driver by the driver should be
> > sufficient.
>
> Updated version,
>
> Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
I don't
> > > The first parameter of strcat() must be big enough to contain the whole
> > > string.
> >
> > Will replace it with
> > sprintf(wrqu->name, "radiobtn/", radiobtn->dev_name);
>
> Or actually, I don't think the radiobtn/ won't be actually needed as prefix.
> The name passed to the radiobtn dri
On Wednesday 31 May 2006 19:31, Ivo van Doorn wrote:
> On Tuesday 30 May 2006 23:43, Francois Romieu wrote:
> > Ivo van Doorn <[EMAIL PROTECTED]> :
> > [...]
> > > diff --git a/drivers/input/misc/radiobtn.c b/drivers/input/misc/radiobtn.c
> > > new file mode 100644
> > > index 000..8d3b84a
> >
On Tuesday 30 May 2006 23:43, Francois Romieu wrote:
> Ivo van Doorn <[EMAIL PROTECTED]> :
> [...]
> > diff --git a/drivers/input/misc/radiobtn.c b/drivers/input/misc/radiobtn.c
> > new file mode 100644
> > index 000..8d3b84a
> > --- /dev/null
> > +++ b/drivers/input/misc/radiobtn.c
> [...]
> >
Ivo van Doorn <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/input/misc/radiobtn.c b/drivers/input/misc/radiobtn.c
> new file mode 100644
> index 000..8d3b84a
> --- /dev/null
> +++ b/drivers/input/misc/radiobtn.c
[...]
> +void radiobtn_poll(unsigned long data)
static ?
[...]
> +int radiob
Hi,
I made a small update on this patch, only a small compile fix
and small bugfix.
The thing I would like to know now, is if the current approach
is the desired situation.
- Should only 1 input device be created, or multiple devices?
- Should instead of KEY_RADIO new keys be created (KEY_RADIO
Add radiobtn driver.
This driver creates an iput device for each registered button
and will poll the device frequently to check the latest status of the button.
Once the status has changed it will try to enable or disable the radio
and send an event to the input device.
Signed-off-by: Ivo van Door
17 matches
Mail list logo
