ambient light sensor for dell latitude

Nicolò Chieffo 84yelo3 at gmail.com
Mon Mar 16 05:46:05 PDT 2009


On Mon, Mar 16, 2009 at 12:37 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> On Mon, Mar 16, 2009 at 12:35:22PM +0100, Nicolò Chieffo wrote:
>
>> 1) I hope you can integrate the logic of the ALS enabled/disabled in
>> the kernel module.
>
> As I said, I'm really not sure there's much of a point. There's already
> a key to do it.

I intended the brightness support logic when ALS is enabled.


Anyway after having had a better look at the SMI API, it seems that
you can control the ALS, setting things called "limit"s (though I
don't know what they are. Have you got any idea?)
As I said before, there could be a benefit of having it available
through a software interface (for instance using the ALS when on a/c
but disable it on battery, in favour of having a preset lower
brightness)
Furthermore the presence of a API to get the status can be used in the
brightness applet to show if the ALS is enabled or not (since we
currently have no way to see it)

>> 2) The rfkill support seems to be limited to runtime switches. Do you
>> think that it is a bad idea to also add persistent switches? (or
>> replace runtime switches with persistent switches?)
>
> There's no real problem with doing so, but again I'm not sure what the
> benefit is.

There's 1 problema and 1 benefit:
the real problem of it is that if your w* is persistently disabled
(from the bios for example) you can't enable it using dell_laptop.
Instead the benefit of only using persistent switches is that the
status of the w* device will be remembered after a reboot


>> I've also a question about the bluetooth switch: when you enable it,
>> the bluethooth device connects it as a HID device. would it be
>> possible to automatically switch it to HCI?
>
> That's the kind of thing that should be handled by a udev script.

thanks of this information


More information about the hal mailing list