[lkml]   [2005]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6: drivers/input/power.c is never built
    On Fri, Feb 18, 2005 at 10:23:19PM +0100, Oliver Neukum wrote:

    > What is the benefit of splitting the flow of information so?

    It's split already. You get some from input (power and sleep keys on
    keyboards, sound volume keys and display brightness on some notebooks),
    some from ACPI events (power keys on notebooks and desktop cases, sound
    volume, display brightness on other notebooks), some from /proc/acpi/*
    (battery status, fan status), some from APM, from platform specific
    devices, from hotplug, from userspace daemons (UPS status).

    The question is how to unify it.

    Using power.c to simply pass power/sleep keys to the ACPI event pipe
    could get the input subsystem out of the loop at least. Maybe we could
    even pass sound keys to it.

    It's probably still the best option, though I argued for doing it the
    other way around - I want to know the pros and cons for all the possible

    > > I think that's all you need to trigger actions. You don't need the exact
    > > percentage of the battery, and you don't need the exact AC voltage at
    > > input.
    > That is very debateable. I might want a quiet mode and would be
    > interested in notifications about thermal data and fan status.
    > Regards
    > Oliver

    Vojtech Pavlik
    SuSE Labs, SuSE CR
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.021 / U:2.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site