Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn

[Ivo van Doorn <ivdoorn@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]