linux-kernel - Re: [PATCH] Map volume and brightness events on thinkpads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d120d5000710170857i3f534544pe9cab0ca6c1b0aa4@mail.gmail.com>
Date:	Wed, 17 Oct 2007 11:57:18 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Henrique de Moraes Holschuh" <hmh@....eng.br>,
	"Jeremy Katz" <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	davej@...hat.com
Subject: Re: [PATCH] Map volume and brightness events on thinkpads

On 10/16/07, Linus Torvalds <torvalds@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/