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

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 17 Oct 2007, Matthew Garrett wrote:
> On Wed, Oct 17, 2007 at 11:57:18AM -0400, Dmitry Torokhov wrote:
> > 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:
> 
> Why use EV_NOTIFY? They're still keys. I'd also quibble with the need 

Why not?  Why the heck do we have to keep the worst of the current mess,
when many drivers CAN (and sometimes have to) tell appart the two classes of
events?  Make notifications a separate thing from regular events, please.

The use of the same path for notifications and events are already a big
enough concession to the HAL model.  AFAIK, HAL is the only reason why on
most systems the userspace consumer of events and notification events are
the same.  HAL gets them all (as well as ACPI events, and whatever else its
helpers poll the system for), and then distributes them over to various
other paths.

On a HAL-less system, it is far less clear that anything that needs the real
events would bother with the notifications.  The only class of applications
that have an use for the notifications are OSD applets and the like.

> for adding _NOTIFY varients of already existing keys - the existing 
> consumers can all cope already.

If one adds EV_NOTIFY, one can just allow for the same KEY constants that
are valid for EV_KEY, and be done with that, I suppose.  But my take is that
Dmitry wants to limit the number of notifications going over input.

I'd rather we added an EV_NOTIFY *bit* that gets or-ed to the real EV_*
type, so that one can turn any event into a notification.  This is certainly
to be useful at least for EV_KEY and EV_SWITCH.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh