Linux Console Project

At 09:13 23.07.2002, Vojtech Pavlik wrote:
>On Sun, Jul 21, 2002 at 12:22:11PM -0700, James Gibson wrote:
> > On Sun, 21 Jul 2002, Scot Wilcoxon wrote:
> > > A long time ago, James Simmons generously inscribed:
> > >  >> You can have multiple keyboards:
> > >  >  o either they get merged and look like one keyboard
> > >  >  o or, if you use the X Input extension, it appears as another
> > >  > input device.
> > >
> > > I just wanted to point out a need for input "filters".  It would be
> > > helpful to be able to redirect input from specific devices, or to filter
> > > input through a userland program.
> > <snip>
>
>We have the uinput device, which allows the userspace to create a new
>input device and feed it with synthetic events. I guess this is enough.

Great, that's at least enough to finally replace the mouse button emulation 
in drivers/macintosh/mac_hid.c with a userspace daemon, probably as an 
addition to the already existing pbbuttonsd.

What I'm still unsure about is the best way for a daemon to detect newly 
added evdev devices. Or is continously scanning /dev/input/ the best way? 
What did happen to the idea of a status device for connect/disconnect/etc 
messages?

Franz.

On Tue, Jul 23, 2002 at 11:46:45AM +0200, Franz Sirl wrote:
> At 09:13 23.07.2002, Vojtech Pavlik wrote:
> >On Sun, Jul 21, 2002 at 12:22:11PM -0700, James Gibson wrote:
> > > On Sun, 21 Jul 2002, Scot Wilcoxon wrote:
> > > > A long time ago, James Simmons generously inscribed:
> > > >  >> You can have multiple keyboards:
> > > >  >  o either they get merged and look like one keyboard
> > > >  >  o or, if you use the X Input extension, it appears as another
> > > >  > input device.
> > > >
> > > > I just wanted to point out a need for input "filters".  It would be
> > > > helpful to be able to redirect input from specific devices, or to filter
> > > > input through a userland program.
> > > <snip>
> >
> >We have the uinput device, which allows the userspace to create a new
> >input device and feed it with synthetic events. I guess this is enough.
> 
> Great, that's at least enough to finally replace the mouse button emulation 
> in drivers/macintosh/mac_hid.c with a userspace daemon, probably as an 
> addition to the already existing pbbuttonsd.
> 
> What I'm still unsure about is the best way for a daemon to detect newly 
> added evdev devices. Or is continously scanning /dev/input/ the best way? 
> What did happen to the idea of a status device for connect/disconnect/etc 
> messages?

There is /proc/bus/input/devices you can read and select() on. The input
core also knows how to call /sbin/hotplug with proper arguments and
environment. The first will probably go away over time in favor of the
second.

-- 
Vojtech Pavlik
SuSE Labs

On Tue, 23 Jul 2002 17:13, Vojtech Pavlik wrote:
> On Sun, Jul 21, 2002 at 12:22:11PM -0700, James Gibson wrote:
> > On Sun, 21 Jul 2002, Scot Wilcoxon wrote:
> > > A long time ago, James Simmons generously inscribed:
> > >  >> You can have multiple keyboards:
> > >  >
> > >  >	o either they get merged and look like one keyboard
> > >  >	o or, if you use the X Input extension, it appears as another
> > >  > input device.
> > >
> > > I just wanted to point out a need for input "filters".  It would be
> > > helpful to be able to redirect input from specific devices, or to
> > > filter input through a userland program.
> >
> > <snip>
>
> We have the uinput device, which allows the userspace to create a new
> input device and feed it with synthetic events. I guess this is enough.
I like this. However it appears to only support a single device. Any reason?

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

On Tue, Jul 23, 2002 at 08:29:24PM +1000, Brad Hards wrote:

> On Tue, 23 Jul 2002 17:13, Vojtech Pavlik wrote:
> > On Sun, Jul 21, 2002 at 12:22:11PM -0700, James Gibson wrote:
> > > On Sun, 21 Jul 2002, Scot Wilcoxon wrote:
> > > > A long time ago, James Simmons generously inscribed:
> > > >  >> You can have multiple keyboards:
> > > >  >
> > > >  >	o either they get merged and look like one keyboard
> > > >  >	o or, if you use the X Input extension, it appears as another
> > > >  > input device.
> > > >
> > > > I just wanted to point out a need for input "filters".  It would be
> > > > helpful to be able to redirect input from specific devices, or to
> > > > filter input through a userland program.
> > >
> > > <snip>
> >
> > We have the uinput device, which allows the userspace to create a new
> > input device and feed it with synthetic events. I guess this is enough.
> I like this. However it appears to only support a single device. Any reason?

It should not. For every open() of that node in /dev, you get a new input
device created.

-- 
Vojtech Pavlik
SuSE Labs

On Tue, 23 Jul 2002 20:35, Vojtech Pavlik wrote:
> On Tue, Jul 23, 2002 at 08:29:24PM +1000, Brad Hards wrote:
> > I like this. However it appears to only support a single device. Any
> > reason?
>
> It should not. For every open() of that node in /dev, you get a new input
> device created.
OK. I haven't actually tried it, but I don't see any checking of minors, and
it looks like you have to use an ioctl() to create the device.

Clearly I need some sample code. Anyone got a test example? 
I'll look at adding this to my documentation set at an appropriate time.


Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

On Tue, Jul 23, 2002 at 08:48:59PM +1000, Brad Hards wrote:
> On Tue, 23 Jul 2002 20:35, Vojtech Pavlik wrote:
> > On Tue, Jul 23, 2002 at 08:29:24PM +1000, Brad Hards wrote:
> > > I like this. However it appears to only support a single device. Any
> > > reason?
> >
> > It should not. For every open() of that node in /dev, you get a new input
> > device created.

> OK. I haven't actually tried it, but I don't see any checking of minors, and

There is only one minor. 

> it looks like you have to use an ioctl() to create the device.

That's correct - you need first to set up the device, then create it.

> Clearly I need some sample code. Anyone got a test example? 

I don't have any at the moment, ask aris@....

> I'll look at adding this to my documentation set at an appropriate time.

-- 
Vojtech Pavlik
SuSE Labs