Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

[Helge Hafting <helge.hafting@aitel.hist.no>]

Joe Peterson wrote:

> Dave Neuer wrote:
>  
>
> > On 8/15/05, Joe Peterson <joe@skyrush.com> wrote:
> >
> >    
> >
> > > So, overall, I agree that we should not invent hacks to make up for
> > > another software package's problems...
> > >      
> > but also wrote:
> >
> >
> >    
> >
> > > If the kernel could handle that aspect, it would make all programs more stable.
> > >      
> > which seems a little contradictory.
> >    
>
> What I was trying to say (and didn't say very well!) is that I agree
> that "hacks" should not be created to mask other problems, but perhaps
> there are ways to solve the problem in the kernel (or in user-space
> programs like udev) that are not hacks and that generally make things
> more elegant all around.
>
>  
>
> > However, Joe continued with:
> >
> >
> >    
> >
> > > It does not sound right to push the handling of the intermittent nature
> > > to each user program.
> > >      
> > Indeed. Each user program should not care about it. An event/hotplug
> > library should, and the user programs should use that. Like d-bus/HAL.
> >    
>
> Right.  Or, if it makes sense, I was proposing that a new kind of device
> (or device mode) that makes a device ever-present could prevent needless
> handling of plugs and unplugs in applications or X, if that's
> appropriate.  /dev/input/mice is such a device, acting as a catch-all
> for mouse events (and as a byproduct, the specific mouse device chosen
> arbitrarily does not matter to the app).  If it's a hack (as Vojtech
> says), maybe there is a way to get the same functionality in a less
> hackish way.  But Vojtech is right that the kernel should not read
> config files or set "policy," so perhaps something like udev is the
> right place for that kind of thing...
>  
Is the kernel really needed for this trick, or could a daemon similiar to
gpm do the job instead?  I.e. the daemon reads the evdev device (when
it is there) and writes to a FIFO. X pulls events out of the other end of
that FIFO.  If the device goes away, the daemon simply waits for it to
reappear, possibly hooking into hotplug if that helps. The FIFO does
not go away, so X is happy.  X just waits till events appear again.

Helge Hafting
-
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/