All of lore.kernel.org
 help / color / mirror / Atom feed
* Global /dev/input/events device
@ 2009-06-05 13:54 Marcel Holtmann
  2009-06-05 15:03 ` Dmitry Torokhov
  0 siblings, 1 reply; 3+ messages in thread
From: Marcel Holtmann @ 2009-06-05 13:54 UTC (permalink / raw)
  To: dmitry.torokhov; +Cc: linux-input

Hi Dmitry,

so I am working on creating a replacement for the kernel RFKILL input
support with a proper daemon in userspace that allows us to implement
proper policy support for RFKILL soft switch event buttons.

What I am missing is a /dev/input/events device (similar to the mice
device) that combines all events into one to make it easier for
application if they really don't care which actual physical or virtual
device created that event. Is it possible that we create something like
this?

Regards

Marcel



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Global /dev/input/events device
  2009-06-05 13:54 Global /dev/input/events device Marcel Holtmann
@ 2009-06-05 15:03 ` Dmitry Torokhov
  2009-06-05 15:10   ` Marcel Holtmann
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Torokhov @ 2009-06-05 15:03 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: linux-input

Hi Marcel,

On Fri, Jun 05, 2009 at 03:54:39PM +0200, Marcel Holtmann wrote:
> Hi Dmitry,
> 
> so I am working on creating a replacement for the kernel RFKILL input
> support with a proper daemon in userspace that allows us to implement
> proper policy support for RFKILL soft switch event buttons.
> 
> What I am missing is a /dev/input/events device (similar to the mice
> device) that combines all events into one to make it easier for
> application if they really don't care which actual physical or virtual
> device created that event. Is it possible that we create something like
> this?
> 

I really don't think that creating such device is in out best interest.
We just went through this with /dev/input/mice and X using legacy
keybpard driver. Inevitably people start trying to remove certain
devices from the multiplexed stream coming up with crazy and fragile
exclusion schemes that only bring more problems in the long run.

Just have your daemon listen to hotplug/dbus events and select() from
all devices you are interested in. Then it will be easier later on to
ignore some devices users feel should not be taken into account.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Global /dev/input/events device
  2009-06-05 15:03 ` Dmitry Torokhov
@ 2009-06-05 15:10   ` Marcel Holtmann
  0 siblings, 0 replies; 3+ messages in thread
From: Marcel Holtmann @ 2009-06-05 15:10 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

Hi Dmitry,

> > so I am working on creating a replacement for the kernel RFKILL input
> > support with a proper daemon in userspace that allows us to implement
> > proper policy support for RFKILL soft switch event buttons.
> > 
> > What I am missing is a /dev/input/events device (similar to the mice
> > device) that combines all events into one to make it easier for
> > application if they really don't care which actual physical or virtual
> > device created that event. Is it possible that we create something like
> > this?
> > 
> 
> I really don't think that creating such device is in out best interest.
> We just went through this with /dev/input/mice and X using legacy
> keybpard driver. Inevitably people start trying to remove certain
> devices from the multiplexed stream coming up with crazy and fragile
> exclusion schemes that only bring more problems in the long run.

I understand that argument, but I don't care about that specific detail
at all. The fact which device send the event is meaningless to me. I
would have to require a filter/mask on that device to be only woken up
for certain event I care about, but that is true for all of them. It is
a major power saving requirement anyway.

> Just have your daemon listen to hotplug/dbus events and select() from
> all devices you are interested in. Then it will be easier later on to
> ignore some devices users feel should not be taken into account.

So I see such a common/global device as pretty useful for simplifying
applications that don't care about the details of multi-device
differences.

Regards

Marcel



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-06-05 15:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-05 13:54 Global /dev/input/events device Marcel Holtmann
2009-06-05 15:03 ` Dmitry Torokhov
2009-06-05 15:10   ` Marcel Holtmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.