Re: [PATCH RFC]rfkill - Hardware button support for Wireless cards
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:
+ For each registered hardware button an input device will be created.
+ If this input device has been opened by the user, rfkill will send a
+ signal to userspace instead of the hardware about the new button
+ status. This will allow userpace to perform the correct steps
+ in order to bring down all interfaces.
+ if (rfkill-input_dev-users) {
+ input_report_key(rfkill-input_dev,
+ KEY_RFKILL, new_status);
+ input_sync(rfkill-input_dev);
Shouldn't there be a continue to avoid calling enable/disable_radio()?
True, totally overlooked that part. Will fix this immediately.
+ }
Stefan
PS: This rfkill stuff is really caught between two stools. Sending a netlink
event for the device with an additional TLV for radio button status seems as
valid as sending an input event...
Hmm not sure about this one. Personally I would think that support for
a button would belong more to the input layer. Even when the button
would only be usefull for networking.
ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC]rfkill - Hardware button support for Wireless cards
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, just one thing I'm missing:
+ For each registered hardware button an input device will be created.
+ If this input device has been opened by the user, rfkill will send a
+ signal to userspace instead of the hardware about the new button
+ status. This will allow userpace to perform the correct steps
+ in order to bring down all interfaces.
+ if (rfkill-input_dev-users) {
+ input_report_key(rfkill-input_dev,
+ KEY_RFKILL, new_status);
+ input_sync(rfkill-input_dev);
Shouldn't there be a continue to avoid calling enable/disable_radio()?
+ }
Stefan
PS: This rfkill stuff is really caught between two stools. Sending a netlink
event for the device with an additional TLV for radio button status seems as
valid as sending an input event...
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC]rfkill - Hardware button support for Wireless cards
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 which I would like to know if this is the acceptable approach.
This rfkill driver looks a bit like the previous version I had send,
but this version does pay attention if the input device has been opened
and if an event should be send to userspace in that case.
I was however unsure about where the KEY_RFKILL should be added
in linux/input.h. I again placed this driver in drivers/input/misc but perhaps
this should go into drivers/net instead?
I hope I am on the right track. :)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 4bad588..837021a 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS)+= wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC)+= hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..da576e5
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,209 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/timer.h
+#include linux/rfkill.h
+
+#include asm/atomic.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF button support);
+MODULE_LICENSE(GPL);
+
+/*
+ * List of all registered buttons.
+ */
+static struct list_head rfkill_list;
+static spinlock_t rfkill_list_lock;
+
+/*
+ * Polling timer, poll_delay and use count.
+ */
+static struct timer_list poll_timer;
+static atomic_t poll_required;
+
+static void rfkill_toggle_radio(int new_status)
+{
+ struct list_head *entry;
+ struct rfkill *rfkill;
+
+ /*
+* Go through the list of all radio's to toggle the radio state.
+*/
+ list_for_each(entry, rfkill_list) {
+ rfkill = list_entry(entry, struct rfkill, entry);
+
+ rfkill-current_status = new_status;
+
+ /*
+ * If the input_device has been opened
+ * all radio events should be send to user space.
+ */
+ if (rfkill-input_dev-users) {
+ input_report_key(rfkill-input_dev,
+ KEY_RFKILL, new_status);
+ input_sync(rfkill-input_dev);
+ }
+
+ /*
+ * If the hardware does not toggle the radio status automaticly,
+ * we should take care of it.
+ */
+ if (new_status rfkill-enable_radio)
+ rfkill-enable_radio(rfkill-data);
+ else if (!new_status rfkill-disable_radio)
+ rfkill-disable_radio(rfkill
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 supports for non-polling keys. I think this is not specific to networking anymore, so it should go to lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov. Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed) and he suggests this solution: - driver is responsible for turning on/off radio when the input device is not opened; - when something opens the input device, it receives input events and gets responsible to turn on/off the radio (by ioctl or putting the network interfaces up/down). 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 possible implementation: 1) 802.11 card drivers will implement an input device for each card in the system that has a user-controlled RF-Kill button or switch. 2) 802.11 card drivers will implement an interface to enable/disable the radio, be it through a call, ioctl, or whatever, that is accessible from both the kernel and userspace. 3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL on machines where RF-Kill keys are reported using ACPI events or keyboard scancodes. 3) A rfkill.ko input handler module will be implemented, that listens to the SW_RFKILL and KEY_RFKILL events from all devices in the system, and will enable/disable radios on all 802.11 devices in the system. The above will make the RF-Kill button work under all real scenarios as user expects - it will enable/disable the radio. In the case where a user has an additional PCMCIA card, both the radios will be disabled by presing the RF-Kill button, which is arguably what the user expects. Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this mechanism. 4) When userspace wants to take over the control over RF-Kill, and start additional services based on that, it can open the input devices to get the state of the buttons/switches, AND it can issue the EVIOCGRAB ioctl() to prevent the rfkill.ko and any other handlers from getting the events. This allows simple implementation of dbus notifications and NetworkManager-style configuration of network interfaces. -- Vojtech Pavlik Director SuSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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-polling keys. I think this is not specific to networking anymore, so it should go to lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov. Thanks, I am currently discussing the driver with developers from button drivers like acerhk and acpi_acer. If I am sending the driver to the lkml will depend on their reaction and input for the driver. No use sending drivers to lkml when no other driver will want to use it. ;) Ivo pgprPwcMR31XL.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 is not specific to networking anymore, so it should go to lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov. Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed) and he suggests this solution: - driver is responsible for turning on/off radio when the input device is not opened; - when something opens the input device, it receives input events and gets responsible to turn on/off the radio (by ioctl or putting the network interfaces up/down). 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 possible implementation: 1) 802.11 card drivers will implement an input device for each card in the system that has a user-controlled RF-Kill button or switch. So basicly 1 input device for every single wireless driver that implements the RF-Kill button? Is there any particular reason for not using 1 input device shared by all? 2) 802.11 card drivers will implement an interface to enable/disable the radio, be it through a call, ioctl, or whatever, that is accessible from both the kernel and userspace. Userspace could switch off the radio by using the txpower ioctl of ifdown/ifup. Or should an approach call be implemented? 3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL on machines where RF-Kill keys are reported using ACPI events or keyboard scancodes. Why both an input and ACPI event? With ACPI restricted to x86 only, wouldn't a more generic approach be desired? 3) A rfkill.ko input handler module will be implemented, that listens to the SW_RFKILL and KEY_RFKILL events from all devices in the system, and will enable/disable radios on all 802.11 devices in the system. The above will make the RF-Kill button work under all real scenarios as user expects - it will enable/disable the radio. In the case where a user has an additional PCMCIA card, both the radios will be disabled by presing the RF-Kill button, which is arguably what the user expects. Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this mechanism. 4) When userspace wants to take over the control over RF-Kill, and start additional services based on that, it can open the input devices to get the state of the buttons/switches, AND it can issue the EVIOCGRAB ioctl() to prevent the rfkill.ko and any other handlers from getting the events. This allows simple implementation of dbus notifications and NetworkManager-style configuration of network interfaces. pgp7erjTTJ8GP.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 system, the input core doesn't have a way how to express the state of these two different buttons with the same meaning (and hence the same code - KEY_RFKILL) in a single input device. You'd have to assign a range of codes to the shared device, which goes agains the design of the Linux inpu layer. Anyway, for the most common case, where you have a single RF-Kill key in the whole system, there will not be any difference to using the shared device. What do you consider the benefits of using a shared input device? Well it is a matter of preference, especially on how this rfkill.ko would be implemented. When the user has 2 buttons, should all radios (wifi, bluetooth etc) be switched off by pressing each individual key or just 1 key to switch off everything. But now that I am further thinking about this, (and looking on how my laptop currently works with 1 wifi button and 1 bluetooth button) perhaps multiple input devices would indeed be best. userspace can decide if more interfaces should be attached to the button or not. And this would be the preferred situation. Userspace could switch off the radio by using the txpower ioctl of ifdown/ifup. Or should an approach call be implemented? I'm an input guy, the details of how to disable the radio I'll leave up to you - the WiFi folks on netdev. :) You may want to consider that the radio chip usually synthesizes a frequency that it mixes with the incoming signal to frequency-shift it to a low frequency which then can be demodulated. Because of that, even the receiver, when working, can affect devices nearby. This is why FM radio receivers are not allowed on airplanes. Hardware RF-Kill disables both RX and TX, by stopping the radio chip. Setting TX power to an extremely low value might not be the same. On the other hand, you may define in the API that setting TX power to zero also disables the receiver. ok, no need for new ioctl calls in that case I believe. Using the txpower the radio can be switched on and off, without giving a low or 0 as value. But the decision to use ifup and ifdown or iwconfig txpower on/off could be done later, since it can handled in user space. 3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL on machines where RF-Kill keys are reported using ACPI events or keyboard scancodes. Why both an input and ACPI event? With ACPI restricted to x86 only, wouldn't a more generic approach be desired? I was talking about the ACPI EC sending us an event. This is how are ACPI buttons implemented in certain notebooks. I definitely don't want to use the acpi events as received by acpid now as the interface. Sorry for the confusion. ah ok. :) 3) A rfkill.ko input handler module will be implemented, that listens to the SW_RFKILL and KEY_RFKILL events from all devices in the system, and will enable/disable radios on all 802.11 devices in the system. The above will make the RF-Kill button work under all real scenarios as user expects - it will enable/disable the radio. In the case where a user has an additional PCMCIA card, both the radios will be disabled by presing the RF-Kill button, which is arguably what the user expects. Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this mechanism. 4) When userspace wants to take over the control over RF-Kill, and start additional services based on that, it can open the input devices to get the state of the buttons/switches, AND it can issue the EVIOCGRAB ioctl() to prevent the rfkill.ko and any other handlers from getting the events. This allows simple implementation of dbus notifications and NetworkManager-style configuration of network interfaces. pgpO8KLnVKMo8.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 anymore, so it should go to lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov. Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed) and he suggests this solution: - driver is responsible for turning on/off radio when the input device is not opened; - when something opens the input device, it receives input events and gets responsible to turn on/off the radio (by ioctl or putting the network interfaces up/down). 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. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 driver. Alternatively, look at the acerhk driver
(http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
number of additional buttons that need to be handled by a special driver, all
sent to userspace, and just one of them to trigger the wireless card. Other
models just handle the button in ACPI and generate an additional ACPI event.
Looking at the RT2400-driver, I see what you want to accomplish: Take the
view
of the WLAN card on the hardware controlled button enable/disable and
generate events on it. However, in many cases it is another driver (see
above) that sets or clears this state, and this should be the instance to
send the input event.
Note that I do not have objections against the driver being included in the
kernel - it just does not qualify as generic radiobutton support, but I know
it's hard to find a good name ;-)
Looking at the code only: There should be an additional non-polling interface
for drivers that can generate events on the own.
Sorry for the late reply, but I have been quite busy with other things lately.
I have created an updated patch, that is more generic than the previous.
I have also renamed it to laptopkey.
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.
By default all events will go over the default input device, but a driver
can choose to create additional input devices.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 4bad588..097ae8c 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,12 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config LAPTOPKEY
+ tristate Laptop keys support
+ help
+Say Y here if you have laptop with additional keys like hardware
+wireless or bluetooth radio control, or other (programmable) keys.
+This driver will create an input device to which other hardware
+drivers can register their keys to.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e691fab 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_LAPTOPKEY)+= laptopkey.o
diff --git a/drivers/input/misc/laptopkey.c b/drivers/input/misc/laptopkey.c
new file mode 100644
index 000..7731554
--- /dev/null
+++ b/drivers/input/misc/laptopkey.c
@@ -0,0 +1,231 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/laptopkey.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(Laptop keys support);
+MODULE_LICENSE(GPL);
+
+/*
+ * Default laptop_key_device structure.
+ */
+static struct laptop_key_device default_keydev = {
+ .dev_name = laptopbtn,
+ .delay = 100,
+};
+
+void laptopkey_key_event(struct laptop_key *key, int status)
+{
+ /*
+* Check if the hardware needs to be informed of
+* the status change.
+*/
+ if (key-key_event)
+ key-key_event(key-data, status);
+
+ /*
+* Send input event to userspace.
+*/
+ input_report_key(key-keydev-input_dev, key-key, status);
+ input_sync(key-keydev-input_dev);
+
+}
+
+static void laptopkey_poll(unsigned long data)
+{
+ struct laptop_key_device *keydev = (struct laptop_key_device *)data;
+
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 version, Signed-off-by Ivo van Doorn [EMAIL PROTECTED] I don't like the patch in it's current form. Many notebooks have a number of additional keys that need to be queried/polled using the same interface, but just one button is to control the radio, the rest are multimedia keys that just need to be forwarded to userspace. Or maybe a bluetooth key. 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. This radiobtn driver is there to poll the device frequently about the radio state only since that is one of the few buttons that is not sending anything to userspace at the moment. Ivo pgpX6cEmYlayM.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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. That's why I pointed you to the wistron_btns driver. Alternatively, look at the acerhk driver (http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a number of additional buttons that need to be handled by a special driver, all sent to userspace, and just one of them to trigger the wireless card. Other models just handle the button in ACPI and generate an additional ACPI event. Looking at the RT2400-driver, I see what you want to accomplish: Take the view of the WLAN card on the hardware controlled button enable/disable and generate events on it. However, in many cases it is another driver (see above) that sets or clears this state, and this should be the instance to send the input event. Note that I do not have objections against the driver being included in the kernel - it just does not qualify as generic radiobutton support, but I know it's hard to find a good name ;-) Looking at the code only: There should be an additional non-polling interface for drivers that can generate events on the own. Stefan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 correct. You are wrong for quite a bunch of laptop models. That's why I pointed you to the wistron_btns driver. Alternatively, look at the acerhk driver (http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a number of additional buttons that need to be handled by a special driver, all sent to userspace, and just one of them to trigger the wireless card. Other models just handle the button in ACPI and generate an additional ACPI event. Ok, indeed a valid point. Would it be better when the radio_button structure contains a list of button structures each with its own poll function and current state. And the radiobtn will loop through the list after each poll_delay time calling all poll functions. That way drivers can specify themselves which buttons need to be polled. By renaming enable_radio and disable_radio in the radiobtn structure it could be made more generic for sending a certain event to the device and not only an instruction for the radio. Looking at the RT2400-driver, I see what you want to accomplish: Take the view of the WLAN card on the hardware controlled button enable/disable and generate events on it. However, in many cases it is another driver (see above) that sets or clears this state, and this should be the instance to send the input event. Note that I do not have objections against the driver being included in the kernel - it just does not qualify as generic radiobutton support, but I know it's hard to find a good name ;-) Thats true. :) Now lets see how this thing can be made a but more generic. ;) Looking at the code only: There should be an additional non-polling interface for drivers that can generate events on the own. Welll if the enable_radio and disable_radio are being renamed to a more generic send_event for sending an event to the driver or something, something similar can be done for the other way around I think, another handler to send an event from driver to radiobtn. But should such an event also trigger a call back to the driver, or should only the input event be triggered? Ivo pgpgdSv0yliKV.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 like the patch in it's current form. Many notebooks have a number of additional keys that need to be queried/polled using the same interface, but just one button is to control the radio, the rest are multimedia keys that just need to be forwarded to userspace. Or maybe a bluetooth key. Some systems require suspend/resume support, others remember state of the wireless button automatically. For a perfect example, look at drivers/input/misc/wistron_btns.c. So you should create an extra laptop buttons interface. Though it may be hard to assure that this generalization layer between input system and hardware is still a win for the driver developer. Stefan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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
[...]
+void radiobtn_poll(unsigned long data)
static ?
Good point. Will fix this immediately.
[...]
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
+* Check if all mandatory fields have been set.
+*/
+ if (radiobtn-poll_delay == 0 || radiobtn-button_poll == NULL)
+ return -EINVAL;
+
+ /*
+* Allocate, initialize and register input device.
+*/
+ radiobtn-input_dev = input_allocate_device();
+ if (!radiobtn-input_dev) {
+ printk(KERN_ERR Failed to allocate input device %s.\n,
+ radiobtn-dev_name);
+ return -ENOMEM;
+ }
+
+ radiobtn-input_dev-name = Radio button;
+ radiobtn-input_dev-phys = strcat(radiobtn/, radiobtn-dev_name);
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);
Thanks.
Ivo
pgp9nZql2WkSp.pgp
Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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
--- /dev/null
+++ b/drivers/input/misc/radiobtn.c
[...]
+void radiobtn_poll(unsigned long data)
static ?
Good point. Will fix this immediately.
[...]
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
+ * Check if all mandatory fields have been set.
+ */
+ if (radiobtn-poll_delay == 0 || radiobtn-button_poll == NULL)
+ return -EINVAL;
+
+ /*
+ * Allocate, initialize and register input device.
+ */
+ radiobtn-input_dev = input_allocate_device();
+ if (!radiobtn-input_dev) {
+ printk(KERN_ERR Failed to allocate input device %s.\n,
+ radiobtn-dev_name);
+ return -ENOMEM;
+ }
+
+ radiobtn-input_dev-name = Radio button;
+ radiobtn-input_dev-phys = strcat(radiobtn/, radiobtn-dev_name);
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 driver by the driver should be sufficient.
Ivo
pgpUN2rhDtxmR.pgp
Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
+ * Check if all mandatory fields have been set.
+ */
+ if (radiobtn-poll_delay == 0 || radiobtn-button_poll == NULL)
+ return -EINVAL;
+
+ /*
+ * Allocate, initialize and register input device.
+ */
+ radiobtn-input_dev = input_allocate_device();
+ if (!radiobtn-input_dev) {
+ printk(KERN_ERR Failed to allocate input device %s.\n,
+ radiobtn-dev_name);
+ return -ENOMEM;
+ }
+
+ radiobtn-input_dev-name = Radio button;
+ radiobtn-input_dev-phys = strcat(radiobtn/, radiobtn-dev_name);
The first parameter of strcat() must be big enough to contain the whole
string.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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_WIFI
and KEY_RADIO_BLUETOOTH for example) or should instead input_event
be used and instead of 1, other values be passed to indicate the device which
has triggered the event?
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 4bad588..212caad 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,14 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RADIOBTN
+ tristate Hardware radio button support
+ help
+ Say Y here if you have an integrated WiFi or Bluetooth device
+ which contains an hardware button for enabling or disabling the radio.
+ When this driver is used, this driver will make sure the radio will
+ be correctly enabled and disabled when needed. It will then also
+ use the created input device to signal user space of this event
+ which allows userspace to take additional actions.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..9af3d98 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RADIOBTN) += radiobtn.o
\ No newline at end of file
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
@@ -0,0 +1,163 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Radio hardware button support
+ Poll frequently all registered hardware for hardware button status,
+ if changed enabled or disable the radio of that hardware device.
+ Send signal to input device to inform userspace about the new status.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/input.h
+#include linux/radiobtn.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(Radio hardware button support);
+MODULE_LICENSE(GPL);
+
+void radiobtn_poll(unsigned long data)
+{
+ struct radio_button *radiobtn = (struct radio_button*)data;
+ int state;
+
+ /*
+* Poll for the new state.
+* Check if the state has changed.
+*/
+ state = !!radiobtn-button_poll(radiobtn-data);
+ if (state != radiobtn-current_state) {
+ radiobtn-current_state = state;
+
+ /*
+* Enable or disable the radio when this
+* should be done in software.
+*/
+ if (state radiobtn-enable_radio)
+ radiobtn-enable_radio(radiobtn-data);
+ else if (!state radiobtn-disable_radio)
+ radiobtn-disable_radio(radiobtn-data);
+
+ /*
+* Report key event.
+*/
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 1);
+ input_sync(radiobtn-input_dev);
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 0);
+ input_sync(radiobtn-input_dev);
+ }
+
+ /*
+* Check if polling has been disabled.
+*/
+ if (radiobtn-poll_delay != 0) {
+ radiobtn-poll_timer.expires =
+ jiffies + msecs_to_jiffies(radiobtn-poll_delay);
+ add_timer(radiobtn-poll_timer);
+ }
+}
+
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
+* Check if all mandatory fields have been set.
+*/
+ if (radiobtn-poll_delay == 0 ||
[RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev/drivers/input/misc/Kconfig
wireless-dev-radiobtn/drivers/input/misc/Kconfig
--- wireless-dev/drivers/input/misc/Kconfig 2006-04-27 00:52:53.0
+0200
+++ wireless-dev-radiobtn/drivers/input/misc/Kconfig2006-05-25
16:29:23.0 +0200
@@ -79,4 +79,13 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RADIOBTN
+ tristate Hardware radio button support
+ help
+ Say Y here if you have an integrated WiFi or Bluetooth device
+ which contains an hardware button for enabling or disabling the radio.
+ When this driver is used, this driver will make sure the radio will
+ be correctly enabled and disabled when needed. It will then also
+ use the created input device to signal user space of this event
+ which allows userspace to take additional actions.
endif
diff -uprN wireless-dev/drivers/input/misc/Makefile
wireless-dev-radiobtn/drivers/input/misc/Makefile
--- wireless-dev/drivers/input/misc/Makefile2006-04-27 00:52:53.0
+0200
+++ wireless-dev-radiobtn/drivers/input/misc/Makefile 2006-05-25
16:25:43.0 +0200
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RADIOBTN) += radiobtn.o
diff -uprN wireless-dev/drivers/input/misc/radiobtn.c
wireless-dev-radiobtn/drivers/input/misc/radiobtn.c
--- wireless-dev/drivers/input/misc/radiobtn.c 1970-01-01 01:00:00.0
+0100
+++ wireless-dev-radiobtn/drivers/input/misc/radiobtn.c 2006-05-25
16:23:59.0 +0200
@@ -0,0 +1,158 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Radio hardware button support
+ Poll frequently all registered hardware for hardware button status,
+ if changed enabled or disable the radio of that hardware device.
+ Send signal to input device to inform userspace about the new status.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/input.h
+#include linux/radiobtn.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(Radio hardware button support);
+MODULE_LICENSE(GPL);
+
+void radiobtn_poll(unsigned long data)
+{
+ struct radio_button *radiobtn = (struct radio_button*)data;
+ int state;
+
+ /*
+* Poll for the new state.
+* Check if the state has changed.
+*/
+ state = !!radiobtn-button_poll(radiobtn-data);
+ if (state != radiobtn-current_state) {
+ radiobtn-current_state = state;
+
+ /*
+* Enable or disable the radio when this
+* should be done in software.
+*/
+ if (state radiobtn-enable_radio)
+ radiobtn-enable_radio(radiobtn-data);
+ else if (!state radiobtn-disable_radio)
+ radiobtn-disable_radio(radiobtn-data);
+
+ /*
+* Report key event.
+*/
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 1);
+ input_sync(radiobtn-input_dev);
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 0);
+ input_sync(radiobtn-input_dev);
+ }
+
+ /*
+* Check if polling has been disabled.
+*/
+ if (radiobtn-poll_delay != 0) {
+ radiobtn-poll_timer.expires =
+ jiffies + msecs_to_jiffies(radiobtn-poll_delay);
+ add_timer(radiobtn-poll_timer);
+ }
+}
+
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
[RFC PATCH 0/2] Hardware button support for Wireless cards
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 enable or disable the radio (if this command needs to be issued from software) and it will send a signal to the input device created for the button. At the moment a input device will be created for each registered button, not sure if this is the desired situation, but thats why this is a RFC patch. ;) I am also not sure where to place this driver so at the moment I have placed it in /drivers/input/misc The second patch is an example of the implementation in rt2x00. That is just an example since that already contained a similar approach with hardware button support. All hints/tips/comments are welcome. :) Ivo pgpqLMMvLVd8o.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
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 - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Not sure actually. the approach rt2x00 takes is sending an event ACPI_TYPE_EVENT with as argument a 0 or 1 depending on the new state of the button. But I don't know if there is another event that would be more suitable for a hardware button. pgp49L2gsD2N8.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
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 so when this event is fired they bring down all the wireless interfaces. Using ACPI events for this purpose seems wrong: - ACPI is not available on all architectures supported by Linux, therefore it cannot be an universal solution; - even if ACPI is available, it may be turned off for some reason. In fact, many people consider the separate /proc/acpi/event interface for ACPI events to be a mistake, and there is some movement to make ACPI use the input layer instead: http://lkml.org/lkml/2006/4/19/275 There is even a KEY_RADIO defined in linux/input.h (however, it was probably intended to be used for a remote control key, like TV/VCR/CD/Tape/... defined near it, so I'm not sure whether it would be the proper event to use here). pgpSYqPPUc94E.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
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 pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. 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 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 so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? 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 application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. 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 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 so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? The rt2x00 device itself does nothing when the button is pressed, it only updates certain fields in a register to indicate the button is pressed. The driver should read from the EEPROM if a hardware button is available, after that it should poll the register to see if the button has been pressed, and it is up to the driver what to do. WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. 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 the radio. It could be that the user wants something to be done before the radio is being disabled. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? 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 application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) This idea sounds good, but is ACPI the thing to be used. Escpially since ACPI is a bit architectures dependent. And the solution should be supported on various architectures. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) system-wide would not be a good idea, we need something to determine which driver exactly has triggered the event. Some laptops have several hardware buttons 1 for Bluetooth and 1 for Wifi for example. So we could just pass the name the driver has created for that button to userspace. At least that is a similar approach to ACPI where the class, bid and name fields are all names set by the driver. pgpdHFhb9PNpa.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
[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 this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. This is actually quite nice for testing roaming setups. You can roam in and out of range by toggling the button. The other laptop in the house has a physical _switch_, which implies that it too cuts off the radio in hardware (though I haven't investigated this, so I'm only speculating). 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. What is the purpose of these switches anyway? Power saving? Or is it for situations like an airplane or hospital where you want to be sure your wireless won't cause any interference? If the latter, than that also argues for always shutting off the radio immediately. Jason - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. 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 toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) Yes, I agree this needs to happen in user space partly because it's policy even though I can only come up with crack reasons on why you wouldn't want to turn off the radio when the button is pressed. However, I suppose we need to do it in user space for some laptops anyway since I'm not sure the RF Kill Switch button and the networking hardware may be related; see below. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers Right, this would be nice. This is sorta like the mess that is hotkeys on laptops. We sorta deal with those in HAL but it's a lot of ugly code to present a sane abstract interface to user space. 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) No, I'm not really sure we need to know exactly what device this is triggered for and I'm not even sure that the kernel can figure this out anyway: the RF Kill buttons may be implemented as a USB HID device for example which may have little relation to the hardware. Another example is where the user is using a USB or PC Card Wifi adapter instead of the built-in Wifi. We want to turn off the radio on the USB or PC Card in these cases too. So what we need from user space is basically just an event saying RF Kill button pressed perhaps with some detail such as 'bluetooth' or 'wifi' depending on the graphics of the button (no, I'm not kidding). It would also be nice with some way to query state, e.g. is the button pressed or not if the hardware supports this. So, I think perhaps it may make sense to model this as an input device. Then we can simply query this input device from user space (in HAL) and emit the right events and provide an interface to query whether the button is pressed or not [1]. Specifically, on startup, NetworkManager would just ask HAL whether the button is pressed or not (if the hardware supports it) and do the right thing, e.g. selectively suspend all networking devices with a radio via the power/state file in sysfs which will turn off the radio. When the user presses the button, NetworkManager enables / disables the device [2] and so on. Hope this helps. David [1] : we do the same thing for other buttons in HAL; e.g. the power button on some Powerbooks. [2] : this raises another problem. What happens to class devices when a bus device is turned off (e.g. selective suspend). For example, does the class device /sys/class/net/eth0 go away when I put the physical to sleep via the /sys/class/net/eth0/device/power/state file? Maybe off topic, but what happens in general? For example what happens when I selectively suspend a USB harddisk enclosure, does /sys/block/sda go away? If it doesn't, does '# touch /dev/sda' wake it up? (it probably shouldn't)... This kind of stuff needs to be precisely defined, yes? Is it already defined? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 the dscape stack that the radio has been disabled. 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 On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. 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 toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users 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? Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users 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? Hm, actually, We don't know what the bit means. Could be some completely different meaning. That is what I am trying to find out. But it seems to have something to do with the power control of the chip. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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. FWIW, I think this position makes the most sense... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
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 control? I assume it disables the radio without any help from the driver, because it definitely turns off my radio, but the bcm43xx driver i'm using (in 2.6.17-rc4) currently doesn't pay any attention to those registers afaik. Correct, my laptop with an integrated BCM43xx chip works this was as well. I can use the button to enable and disable the device (led is switching on and off) without a bcm43xx driver installed. Hardware detection just picks it up when I enable the device with the button as new device. So the hardware button works directly with the hardware. pgpfqFfVjvAF7.pgp Description: PGP signature
RE: Hardware button support for Wireless cards
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 able to trust on the rfkill to really kill the radio regardless of whether the user space mechanism is in place or not, i.e., I see this as a function that can be used to disable radio in environments were use of wireless devices is not allowed for some reason. Sending an event to user space would be a good additional indication that the radio was disabled. If user space wants to do something first, I would think that doing this with full software control (i.e., not depending on any particular hardware button and just having a UI mechanism for triggering this) would allow more consistent behavior. Sounds like this is the popular option - I agree that immediate radio-off is the safe way to go here as at least the driver can guarantee that the radio is disabled no matter the userspace config. Does someone want to put their hand up and specify the userspace interface here and now so we all keep to a standard ? Working as an input device as David suggested seems to give us the most flexibility. Regards, Mark Wallis E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
