Hi,
> I have been quite busy lately, hence the reason for this late continuance
> of the Hardware button support for Wireless cards discussion.
> I have CC'ed the people who discussed this in earlier threads.
no problem. Look good, just one thing I'm missing:
> +
Am Sonntag, 9. Juli 2006 17:49 schrieb Ivo Van Doorn:
> I have been quite busy lately, hence the reason for this late continuance
> of the Hardware button support for Wireless cards discussion.
> I have CC'ed the people who discussed this in earlier threads.
no problem. Look good,
Hi,
I have been quite busy lately, hence the reason for this late continuance
of the Hardware button support for Wireless cards discussion.
I have CC'ed the people who discussed this in earlier threads.
With the suggestions made by Vojtech Pavlik I have created the rfkill driver,
for wh
> > 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
Use radiobtn interface for radio hardware button support in rt2x00
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev-radiobtn/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev/drivers/net/wireless/d80211/rt2
Hi,
As discussed previously on this list hardware button support
for wireless cards and Bluetooth devices could use a seperate
generalized driver.
I have made a first attempt to do this with the suggestions from the
discussion. This means that in all cases the hardware will be requested
to
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
On Tue, May 16, 2006, Jouni Malinen wrote:
> Some hardware designs disable the radio in hardware, some
> don't.. In other words, the behavior would not be consistent
> between hardware designs unless the radio would be disabled
> unconditionally in software-processed case. I would like to
> be
On Monday 15 May 2006 21:46, Jason Lunz wrote:
> On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> > When those bits get set in the register, is the radio already disabled?
> > ie, for the bcm43xx chip, is it really force-disabled by the button, or
> > does the driver have some contro
On Mon, May 15, 2006 at 03:27:54PM +, Jason Lunz wrote:
> So if there's any desire for consistency of wireless button support,
> then I think the software-controlled ones should always shut off the
> radio, and optionally inform userspace or the wireless stack using some
> event mechanism.
FW
On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?
I assume it disables the radio without any help fro
On Monday 15 May 2006 21:12, you wrote:
> > There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> > some "Radio is hardware-disabled" state. We currently don't use that flag
> > correctly in the driver. Could you please assist me on testing if your
> > switch
> > actually toggl
On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote:
> On Monday 15 May 2006 17:27, you wrote:
> > [EMAIL PROTECTED] said:
> > > Some people are saying that instead of throwing and ACPI event we should
> > > be
> > > either use hotplug or internally just disable the radio and somehow inform
>
On Mon, May 15, 2006 at 05:12:20PM +0200, Ivo van Doorn wrote:
> Well I would think it is cleaner to inform userspace that the button is
> pressed
> and let userspace sort out what exactly should happen.
> But I doubt it will be a good idea when the driver is sending and event _and_
> disabled th
On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote:
> Ideally, here's what would happen: the driver/card/whatever generates
> an ACPI event, which is noticed by HAL. HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus. Any interested a
On Monday 15 May 2006 17:27, you wrote:
> [EMAIL PROTECTED] said:
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> >
> > What are pe
[EMAIL PROTECTED] said:
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling t
On Monday 15 May 2006 16:37, Dan Williams wrote:
> On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> > Hi everyone,
> >
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> Hi everyone,
>
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
>
On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote:
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
>
> B. should we be firing an ACPI event and getting the distro's to add scripts
On Monday 15 May 2006 15:25, Jiri Benc wrote:
> On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do wha
On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - includ
Hi everyone,
During our development of the rt2x00 wireless driver we have come across an
interesting issue that we want to get comment on from the netdev-community.
Some laptops with our Ralink cards build-in also include a hardware button
that is meant to enable/disable the wireless card. We are
38 matches
Mail list logo
