Hi Matthew,
On Wed, Jul 02, 2008 at 11:19:19AM +0100, Matthew Garrett wrote:
> On Wed, Jul 02, 2008 at 05:00:44PM +0800, Harald Welte wrote:
>
> > * in order to fully support the backlight interface and get rid of the
> > clumsy separation of 'ac' (with power supply) and 'dc' (battery only)
> > brightness settings, the driver would need to receive a notification
> > whenever the ACPI power supply status changes. I know how to get to
> > that notification in userspace, but in kernelspace I'm not so sure.
> > Is there a notifier chain to which I can attach?
>
> I don't think so, but it ought to be easy enough to glue into the
> power_supply class. The easiest thing for the moment is probably just to
> write values to both the ac and dc classes and let userspace handle the
> transition. If they're both in sync, it doesn't matter which you read
> back from.
mh, ok, that actually makes a lot of sense. Will do that.
> > +/* This is transitional definition */
> > +#ifndef KEY_BATT
> > +# define KEY_BATT 227
> > +#endif
>
> Shouldn't be needed in-tree.
true.
> > + const int key_map[] = {
> > + /* 0 */ -1,
> > + /* 1 */ KEY_BRIGHTNESSDOWN,
> > + /* 2 */ KEY_BRIGHTNESSUP,
> > + /* 3 */ KEY_DISPLAYTOGGLE,
> > + /* 4 */ KEY_MUTE,
> > + /* 5 */ KEY_VOLUMEDOWN,
> > + /* 6 */ KEY_VOLUMEUP,
> > + /* 7 */ KEY_SLEEP,
> > + /* 8 */ -1, /* Change CPU boost: do nothing */
> > + /* 9 */ KEY_BATT,
> > + /* 10 */ KEY_SUSPEND,
> > + };
>
> Hm. Does this mean that the keymap isn't changable at runtime?
i wasn't aware that those kind of keymaps could be changeable at
runtime. Will read up on my homework ;)
> > + if (acpi_pcc_hotkey_get_key(hotkey)) {
> > + /* generate event like '"pcc HKEY 00000080 00000084"'
> > + * when Fn+F4 pressed */
>
> Probably better not to add further events to /proc now - we'd like to
> deprecate the interface.
ok. I just kept all the exsting interfaces of the pcc_acpi driver
(/proc based) and added the new backlight API to it.
> And shouldn't be adding any new files to /proc. Anything that can't be
> expressed via the existing generic sysfs classes should be an attribute
> on a sysfs platform device.
that's what I generally know from other drivers (and how I do it in
other kernel code). But I wasn't sure what the policy with regard to
this was for ACPI.
Thanks for your quick feedback, will re-post after all issues have been
adressed.
--
- Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Attachment:
signature.asc
Description: Digital signature
