rfkill-input understanding help

rfkill-input understanding help

[Carlos Corbacho]

Dmitry, Ivo,

I'm trying to get my head around the input part of rfkill, and failing 
miserably here.

Background:

acer-wmi (in development) controls the rfkill switches for wireless and 
bluetooth on many Acer laptops.

There are two buttons which control these, one for wireless, and one for 
bluetooth. However, the wireless and bluetooth buttons on the laptop are just 
keys - they generate KEY_WLAN and KEY_BLUETOOTH, but don't toggle the 
wireless and bluetooth themselves (this is down to acer-wmi).

I'd like to set it up so that KEY_WLAN will toggle the wireless, and 
KEY_BLUETOOTH toggles bluetooth.

I've been reading through rfkill.txt and linux/rfkill.h and the various 
discussions about rfkill and quite frankly, I'm no-where near understanding 
what it is I need to do for this particular use case.

What I've done so far:

Registered two rfkill devices - one for wireless, one for bluetooth.

Problem:

The sysfs interface works just fine - but nothing is being toggled when I 
press the wireless or bluetooth buttons (which are just generating KEY_WLAN 
and KEY_BLUETOOTH).

>From my limited understanding, rfkill_input (which is enabled in my kernel) 
_should_ just be handling these keycodes (since userspace has not claimed 
these rfkill devices), and then calling the necessary toggle function - but 
AFAICT, this is not happening.

Have I misunderstood this, am I missing something, or is this particular use 
case supposed to be handled by userspace instead (i.e. a userspace tool is 
supposed to handle the keypress, then toggle the rfkill device via sysfs)?

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Ivo van Doorn]

Hi,

Sorry for the late response..

> There are two buttons which control these, one for wireless, and one for 
> bluetooth. However, the wireless and bluetooth buttons on the laptop are just 
> keys - they generate KEY_WLAN and KEY_BLUETOOTH, but don't toggle the 
> wireless and bluetooth themselves (this is down to acer-wmi).

Which makes rfkill a correct solution. :)

> Registered two rfkill devices - one for wireless, one for bluetooth.
> 
> Problem:
> 
> The sysfs interface works just fine - but nothing is being toggled when I 
> press the wireless or bluetooth buttons (which are just generating KEY_WLAN 
> and KEY_BLUETOOTH).

So using the sysfs interface you can enable and disable the radios?

> From my limited understanding, rfkill_input (which is enabled in my kernel) 
> _should_ just be handling these keycodes (since userspace has not claimed 
> these rfkill devices), and then calling the necessary toggle function - but 
> AFAICT, this is not happening.
> 
> Have I misunderstood this, am I missing something, or is this particular use 
> case supposed to be handled by userspace instead (i.e. a userspace tool is 
> supposed to handle the keypress, then toggle the rfkill device via sysfs)?

Without a code example I can't say much, but have you looked to the examples
in the drivers/net/wireless/rt2x00/ and drivers/net/wireless/b43
Those are at least 2 drivers with a working rfkill implementation for WLAN,
that should give a good example on how the code should look like.

Ivo

Re: rfkill-input understanding help

[Carlos Corbacho]

On Sunday 30 December 2007 18:59:42 Ivo van Doorn wrote:
> So using the sysfs interface you can enable and disable the radios?

A while ago it could (I'll have to resurrect the code, since I haven't touched 
it much lately since experimenting with rfkill a few weeks ago).

> Without a code example I can't say much, but have you looked to the
> examples in the drivers/net/wireless/rt2x00/ and drivers/net/wireless/b43
> Those are at least 2 drivers with a working rfkill implementation for WLAN,
> that should give a good example on how the code should look like.

I've been looking mostly at the b43 code for inspiration.

Once I beat my own code back into some sort of useable shape again, I'll send 
it along to see if you can spot where I'm missing something.

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Ivo van Doorn]

On Monday 31 December 2007, Carlos Corbacho wrote:
> On Sunday 30 December 2007 18:59:42 Ivo van Doorn wrote:
> > So using the sysfs interface you can enable and disable the radios?
> 
> A while ago it could (I'll have to resurrect the code, since I haven't touched 
> it much lately since experimenting with rfkill a few weeks ago).
> 
> > Without a code example I can't say much, but have you looked to the
> > examples in the drivers/net/wireless/rt2x00/ and drivers/net/wireless/b43
> > Those are at least 2 drivers with a working rfkill implementation for WLAN,
> > that should give a good example on how the code should look like.
> 
> I've been looking mostly at the b43 code for inspiration.

Then make sure you update to the latest version, I believe they
had a broken rfkill version for some time. (They based it on the
rt2x00 version which for a time was also broken).
The latest version of both drivers are now working. :)

> Once I beat my own code back into some sort of useable shape again, I'll send 
> it along to see if you can spot where I'm missing something.

Ok.

Ivo

Re: rfkill-input understanding help

[Carlos Corbacho]

Well, the good news is that the code I have appears to work. But, I have 
something very strange going on with my kernel (latest ACPI git tree + 
acer-wmi on top) and rfkill-input.

Basically, if I either:

1) Build rfkill-input into the kernel

or

2) Build rfkill-input as a module, and use kmod to load it from acer-wmi

Then rfkill-input doesn't work.

If I load rfkill-input manually (or if already loaded by kmod; unload and
then reload), everything works as expected. The (in progress) code to add
rfkill support to acer-wmi is here (in case the problem is something wrong
with the code) - as you can see, it's mostly based on the b43 work.

My kernel config is here, in case I'm missing something obvious:
http://files.strangeworlds.co.uk/config-acpi-git-20080111

For reference, the patch series that this ('acpi-wmi-rfkill') is part of
(of which only 'wmi' and 'acpi-wmi' are relevant) is here:
http://files.strangeworlds.co.uk/wmi/

-Carlos
---
acer-wmi: Add rfkill support

From: Carlos Corbacho <carlos@strangeworlds.co.uk>

Add initial rfkill support for acer-wmi
---

 drivers/misc/acer-wmi.c |  215 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 214 insertions(+), 1 deletions(-)


diff --git a/drivers/misc/acer-wmi.c b/drivers/misc/acer-wmi.c
index 6150120..5f6adc0 100644
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@ -34,6 +34,9 @@
 #include <linux/platform_device.h>
 #include <linux/acpi.h>
 #include <linux/i8042.h>
+#include <linux/rfkill.h>
+#include <linux/input-polldev.h>
+#include <linux/kmod.h>
 
 #include <acpi/acpi_drivers.h>
 
@@ -710,6 +713,213 @@ static void __init acer_commandline_init(void)
 }
 
 /*
+ * RF Kill devices
+ */
+struct acer_rfkill {
+	struct rfkill *wireless;
+	u32 wcap;
+	struct rfkill *bluetooth;
+	u32 bcap;
+};
+
+static struct acer_rfkill acer_rfk;
+
+struct acer_input {
+	struct input_polled_dev *wireless;
+	struct input_polled_dev *bluetooth;
+};
+
+static struct acer_input acer_poll;
+
+static void acer_rfkill_poll(struct input_polled_dev *poll_dev)
+{
+	struct rfkill *rfk = poll_dev->private;
+	u32 cap = *((u32 *) rfk->data);
+	u32 enabled, keycode, *state;
+
+	get_u32(&enabled, cap);
+
+	switch (cap) {
+	case ACER_CAP_WIRELESS:
+		keycode = KEY_WLAN;
+		state = &interface->data.wireless;
+		break;
+	case ACER_CAP_BLUETOOTH:
+		keycode = KEY_BLUETOOTH;
+		state = &interface->data.bluetooth;
+		break;
+	default:
+		return;
+	}
+
+	if (unlikely(enabled != *state)) {
+		printk(ACER_INFO "Radio state changed\n");
+		*state = enabled;
+		input_report_key(poll_dev->input, keycode, 1);
+		input_report_key(poll_dev->input, keycode, 0);
+	}
+}
+
+static int acer_rfkill_toggle(void *data, enum rfkill_state rfk_state)
+{
+	u32 cap = *((u32 *) data);
+	u32 *state;
+
+	printk(ACER_INFO "Setting cap for %u\n", cap);
+
+	switch (cap) {
+	case ACER_CAP_WIRELESS:
+		state = &interface->data.wireless;
+		break;
+	case ACER_CAP_BLUETOOTH:
+		state = &interface->data.bluetooth;
+		break;
+	default:
+		return -ENODEV;
+	}
+
+	switch (rfk_state) {
+	case RFKILL_STATE_ON:
+		printk(ACER_INFO "Turning on\n");
+		set_u32(1, cap);
+		*state = 1;
+		break;
+	case RFKILL_STATE_OFF:
+		printk(ACER_INFO "Turning off\n");
+		set_u32(0, cap);
+		*state = 0;
+		break;
+	}
+
+	return 0;
+}
+
+static int acer_rfkill_init_device(struct device **dev, struct rfkill **rfk_dev,
+struct input_polled_dev **rfk_poll_dev, u32 cap, u32 type, char *name)
+{
+	int err;
+	u32 *data;
+	u32 keycode = 0;
+	struct rfkill *rfk;
+	struct input_polled_dev *rfk_poll;
+
+	printk(ACER_INFO "Allocating rfkill device\n");
+	rfk = rfkill_allocate(*dev, type);
+	if (!rfk_dev)
+		goto error;
+
+	rfk->name = name;
+	rfk->state = RFKILL_STATE_ON;
+	rfk->toggle_radio = acer_rfkill_toggle;
+	data = kzalloc(sizeof(u32), GFP_KERNEL);
+	if (!data)
+		goto error_free_rfk;
+
+	*data = cap;
+	rfk->data = data;
+
+	printk(ACER_INFO "Allocating polled device\n");
+	rfk_poll = input_allocate_polled_device();
+	if (!rfk_poll)
+		goto error_free_rfk;
+
+	rfk_poll->private = rfk;
+	rfk_poll->poll = acer_rfkill_poll;
+	rfk_poll->poll_interval = 1000;
+
+	rfk_poll->input->name = rfk->name;
+	rfk_poll->input->id.bustype = BUS_HOST;
+	rfk_poll->input->evbit[0] = BIT(EV_KEY);
+
+	switch (cap) {
+	case ACER_CAP_WIRELESS:
+		keycode = KEY_WLAN;
+		break;
+	case ACER_CAP_BLUETOOTH:
+		keycode = KEY_BLUETOOTH;
+		break;
+	}
+	set_bit(keycode, rfk_poll->input->keybit);
+
+	printk(ACER_INFO "Registering rfkill device\n");
+	err = rfkill_register(rfk);
+	if (err)
+		goto error_free_polldev;
+
+	err = input_register_polled_device(rfk_poll);
+	if (err)
+		goto error_unreg_rfk;
+
+	*rfk_dev = rfk;
+	*rfk_poll_dev = rfk_poll;
+
+	return 0;
+
+error_unreg_rfk:
+	rfkill_unregister(*rfk_dev);
+error_free_polldev:
+	input_free_polled_device(*rfk_poll_dev);
+error_free_rfk:
+	kfree(data);
+	rfkill_free(*rfk_dev);
+error:
+	return -ENODEV;
+}
+
+static int acer_rfkill_init(struct device *dev)
+{
+	int err;
+
+	printk(ACER_INFO "Initialising RFKILL devices\n");
+
+	if (has_cap(ACER_CAP_WIRELESS)) {
+		err = acer_rfkill_init_device(&dev, &acer_rfk.wireless,
+			&acer_poll.wireless, ACER_CAP_WIRELESS,
+			RFKILL_TYPE_WLAN, "acer-wireless");
+		if (err)
+			return -ENODEV;
+	}
+
+	if (has_cap(ACER_CAP_BLUETOOTH)) {
+		err = acer_rfkill_init_device(&dev, &acer_rfk.bluetooth,
+			&acer_poll.bluetooth, ACER_CAP_BLUETOOTH,
+			RFKILL_TYPE_BLUETOOTH, "acer-bluetooth");
+		if (err)
+			return -ENODEV;
+	}
+
+#ifdef CONFIG_RFKILL_INPUT_MODULE
+	/* acer-wmi RF-kill isn't useful without the rfkill-input subsystem.
+	 * Try to load the module. */
+	err = request_module("rfkill-input");
+	if (err)
+		printk(ACER_INFO "Failed to load the rfkill-input module. "
+			"The built-in radio LED will not work.\n");
+#endif /* CONFIG_RFKILL_INPUT */
+
+	return 0;
+}
+
+static void acer_rfkill_exit_device(struct rfkill *rfk_dev,
+struct input_polled_dev *rfk_poll_dev)
+{
+	input_unregister_polled_device(rfk_poll_dev);
+	rfkill_unregister(rfk_dev);
+	input_free_polled_device(rfk_poll_dev);
+	kfree(rfk_dev->data);
+	rfkill_free(rfk_dev);
+}
+
+static void acer_rfkill_exit(void)
+{
+	if (has_cap(ACER_CAP_WIRELESS))
+		acer_rfkill_exit_device(acer_rfk.wireless, acer_poll.wireless);
+
+	if (has_cap(ACER_CAP_BLUETOOTH))
+		acer_rfkill_exit_device(acer_rfk.bluetooth, acer_poll.bluetooth);
+}
+
+/*
  * LED device (Mail LED only, no other LEDs known yet)
  */
 static void mail_led_set(struct led_classdev *led_cdev,
@@ -842,7 +1052,8 @@ static int __devinit acer_platform_probe(struct platform_device *device)
 		acer_led_init(&device->dev);
 	if (has_cap(ACER_CAP_BRIGHTNESS))
 		acer_backlight_init(&device->dev);
-	return 0;
+
+	return acer_rfkill_init(&device->dev);
 }
 
 static int acer_platform_remove(struct platform_device *device)
@@ -851,6 +1062,8 @@ static int acer_platform_remove(struct platform_device *device)
 		acer_led_exit();
 	if (has_cap(ACER_CAP_BRIGHTNESS))
 		acer_backlight_exit();
+
+	acer_rfkill_exit();
 	return 0;
 }
 

Re: rfkill-input understanding help

[Ivo van Doorn]

On Friday 11 January 2008, Carlos Corbacho wrote:
> Well, the good news is that the code I have appears to work. But, I have 
> something very strange going on with my kernel (latest ACPI git tree + 
> acer-wmi on top) and rfkill-input.
> 
> Basically, if I either:
> 
> 1) Build rfkill-input into the kernel
> 
> or
> 
> 2) Build rfkill-input as a module, and use kmod to load it from acer-wmi
> 
> Then rfkill-input doesn't work.
> 
> If I load rfkill-input manually (or if already loaded by kmod; unload and
> then reload), everything works as expected. The (in progress) code to add
> rfkill support to acer-wmi is here (in case the problem is something wrong
> with the code) - as you can see, it's mostly based on the b43 work.
> 
> My kernel config is here, in case I'm missing something obvious:
> http://files.strangeworlds.co.uk/config-acpi-git-20080111

Does it help when you run
	request_module("rfkill-input");
_before_ calling acer_rfkill_init_device() ?

Perhaps the rfkill-input needs to be registered before input
devices are being registered. But I am not sure, Dmitry propably
knows more about possible ordering requirements for input
device and input trigger registration.

Ivo

Re: rfkill-input understanding help

[Dmitry Torokhov]

On Jan 11, 2008 2:08 PM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
>
> Perhaps the rfkill-input needs to be registered before input
> devices are being registered. But I am not sure, Dmitry propably
> knows more about possible ordering requirements for input
> device and input trigger registration.
>

No, it is ok for rfkill-input handler to be installed later, but of
course it will miss any events that happen before.

-- 
Dmitry

Re: rfkill-input understanding help

[Carlos Corbacho]

On Friday 11 January 2008 20:34:09 Dmitry Torokhov wrote:
> On Jan 11, 2008 2:08 PM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > Perhaps the rfkill-input needs to be registered before input
> > devices are being registered. But I am not sure, Dmitry propably
> > knows more about possible ordering requirements for input
> > device and input trigger registration.
>
> No, it is ok for rfkill-input handler to be installed later, but of
> course it will miss any events that happen before.

Unfortunately, moving the load order of rfkill-input doesn't solve my acer-wmi 
problems:

1) If I build rfkill-input in, it does nothing (since the load order code is 
obviously only for the module) - KEY_WLAN and KEY_BLUETOOTH are just ignored 
by it.

2) If I build rfkill-input as a module, it won't work when autoloaded. If I 
unload then reload it, it will:

i) If b43 is not loaded, it will just toggle both states. (the software only 
toggle also changes to start toggling both states after reloading 
rfkill-input).

ii) If b43 is loaded, after one or two KEY_WLAN or KEY_BLUETOOTH presses, I  
end up in a vicious cycle of rfkill non-stop changing the states of both the 
bluetooth and wireless rapidly, until I unload either b43 or acer-wmi and get 
the same result as (i) (I can also stop this nasty loop by commenting out the 
input_report_key lines in b43 - so this probably isn't a b43 specific issue, 
it's just an example of a problem).

Of course, if I completely ignore rfkill-input, I can happily toggle my 
wireless and bluetooth devices via their respective 'state' files to my 
hearts content, and they work fine. But after loading rfkill-input (as 
described above), even the 'state' file toggle causes the nasty 
toggle-all-devices-and-loop-endlessly.

So I suppose the real question is: what exactly is going on with rfkill-input 
on my laptop?

Is there anywhere in particular I can shove some printk's or some such to find 
out if, and where, rfkill-input may be going wrong (I'm assuming the failing 
to run properly on the first load is the real issue, and the rest of it is 
just a side effect of something having gone wrong)?

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Carlos Corbacho]

On Saturday 12 January 2008 00:32:40 Carlos Corbacho wrote:
> On Friday 11 January 2008 20:34:09 Dmitry Torokhov wrote:
> > On Jan 11, 2008 2:08 PM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > > Perhaps the rfkill-input needs to be registered before input
> > > devices are being registered. But I am not sure, Dmitry propably
> > > knows more about possible ordering requirements for input
> > > device and input trigger registration.
> >
> > No, it is ok for rfkill-input handler to be installed later, but of
> > course it will miss any events that happen before.
>
> Unfortunately, moving the load order of rfkill-input doesn't solve my
> acer-wmi problems:

Some experimentation shows that something is going wrong in input.c - 
rfkill_connect() is not being executed on the first load of rfkill-input.

Shoving some printk's into input.c shows that it fails in 
input_match_handler() on:

	id = input_match_device(handler->id_table, dev);
	if (!id)
		return -ENODEV;

This test always fails for every call of input_match_handler() in 
input_register_handler().

Unloading and reloading rfkill-input then somehow causes this test to not 
fail, and rfkill-input is then properly registered...

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Carlos Corbacho]

Dmitry,

On Tuesday 22 January 2008 00:55:37 Carlos Corbacho wrote:
> Shoving some printk's into input.c shows that it fails in
> input_match_handler() on:
>
> 	id = input_match_device(handler->id_table, dev);
> 	if (!id)
> 		return -ENODEV;
>
> This test always fails for every call of input_match_handler() in
> input_register_handler().
>
> Unloading and reloading rfkill-input then somehow causes this test to not
> fail, and rfkill-input is then properly registered...

Any thoughts at all on how to diagnose why rfkill-input is not able to find a 
device to attach to the first time it loads (or more specifically, why 
input_match_device() fails to return a match the first time around), because 
I'm still scratching my head on this four months later...

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Carlos Corbacho]

On Saturday 12 April 2008 18:21:31 Carlos Corbacho wrote:
> Any thoughts at all on how to diagnose why rfkill-input is not able to find
> a device to attach to the first time it loads (or more specifically, why
> input_match_device() fails to return a match the first time around),
> because I'm still scratching my head on this four months later...

I think I've found the problem here.

rfkill-input isn't being attached to a device because it's looking for 
KEY_WLAN. The problem is that at boot time, I don't have a KEY_WLAN - the key 
isn't mapped until HAL & hal-info kick in much later.

I've tested this by blacklisting rfkill-input, waiting until HAL has loaded 
and run setkeycodes, and then loaded rfkill-input, which then works properly 
first time round.

Unfortunately, that's only a workaround, not a real solution, so we're going 
to need a better way of handling this case.

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: rfkill-input understanding help

[Dmitry Torokhov]

Hi Carols,

On Sun, Apr 13, 2008 at 12:23:12PM +0100, Carlos Corbacho wrote:
> On Saturday 12 April 2008 18:21:31 Carlos Corbacho wrote:
> > Any thoughts at all on how to diagnose why rfkill-input is not able to find
> > a device to attach to the first time it loads (or more specifically, why
> > input_match_device() fails to return a match the first time around),
> > because I'm still scratching my head on this four months later...
> 
> I think I've found the problem here.
> 
> rfkill-input isn't being attached to a device because it's looking for 
> KEY_WLAN. The problem is that at boot time, I don't have a KEY_WLAN - the key 
> isn't mapped until HAL & hal-info kick in much later.
> 
> I've tested this by blacklisting rfkill-input, waiting until HAL has loaded 
> and run setkeycodes, and then loaded rfkill-input, which then works properly 
> first time round.
> 
> Unfortunately, that's only a workaround, not a real solution, so we're going 
> to need a better way of handling this case.
> 

Yes, setting KEY_X later, after registering input device will not
cause device/handler rescanning. We'll have to do something about
it now that we recommend using HAL to update keymaps properly.

-- 
Dmitry