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
