lkml.org 
[lkml]   [2007]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Map volume and brightness events on thinkpads
    On 10/16/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
    >
    > On Tue, 16 Oct 2007, Dmitry Torokhov wrote:
    > >
    > > I agree that these are 2 different events. My argument is that
    > > "VOLUME_UP_NOTIFY" event is similar to "BATTERY_OUT_NOTIFY",
    > > "DOCK_UNDOCK_NOTIFY", etc, etc and should be sent not through input
    > > layer but through a generic (yet to be designed) notification
    > > mechanism. Something lighter than input. Something like uevents over
    > > netlink.
    >
    > Well, I'd argue that:
    >
    > - it's going to be the same entity that cares in both cases (ie anybody
    > who is ready to accept VOLUME_UP keypresses is also the exact same
    > party that also wants to know if VOLUME_UP happened *independently*)
    >
    > Ergo: making it a separate "generic" notification is actually totally
    > counterproductive, because it just adds complexity.

    That is a good argument. If there are no other users for this other
    transport then I agree, inventing it just for keypress notifications
    is bad idea.

    > - it really is a keypress. Yes, it's a keypress with side effects, but
    > it still tends to have a distinct source, and as such it is interesting
    > *as* a keypress.
    >
    > IOW: it should have all the same "incidental" side effects as any other
    > keypress. Example: I think it's reasonable to consider it an event as
    > far as the screen saver is concerned. In other words, it's not *just* a
    > "volume was raised" event. It's a "volume was raised, and the user
    > actually pressed a key to do so".
    >

    This is a good argument for having 2 separate types of events but not
    for which transport shoudl be used to deliver it.

    > So I do think they are keypresses, although I also suspect that like many
    > other magical keys, the "NOTIFY" version is often also totally hidden by
    > hardware/firmware interactions (ie I'm pretty sure that many of those
    > special keys will never be visible at all to the OS, because the firmware
    > hides the fact that they were pressed entirely!)
    >

    Yes, on my old Inspiron brightness is completely handled by firmware.
    There is no ACPI, nor keyboard events generated whatsoever.

    OK, I guess I would like to hear once again from userspace guys -
    DBUS/HAL/etc. Do they see a need for a generic interface that can be
    used for all kinds of events, not only related to keypresses. If they
    say that they only care about notifications arising from keypresses
    then I will add EV_NOTIFY type of events to input layer. What events
    would we need? I can imagine:

    KEY_BRIGHTNESSUP_NOTIFY
    KEY_BRIGHTNESSDOWN_NOTIFY
    KEY_BRIGHTNESSMIN_NOTIFY
    KEY_BRIGHTNESSMAX_NOTIFY
    KEY_VOLUMEUP_NOTIFY
    KEY_VOLUMEDOWN_NOTIFY
    KEY_MUTE_NOTIFY
    KEY_DISPLAYSWITCH_NOTIFY
    KEY_WIFI_NOTIFY

    What else? And it better have "key" in its name, BATTERY_OUT_NOTIFY
    won't fly ;)

    --
    Dmitry
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-17 17:59    [W:4.705 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site