linuxconsole-dev

RE: X compiled for evdev?

[Scot W. <sc...@wi...>]

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.

Barcode readers: Many barcode readers use keyboard wedges, but an 
environment may want to process barcode data differently than keyboard 
data -- even if a keyboard is also connected to the same hardware port. 
  A POS (cash register) app may want to show different screens when 
merchandise or gift certificate barcodes are read no matter which is the 
current input field.  A device with encoding different than direct 
keyboard emulation, such as a CueCat wand or raw on/off wand, may only 
need simple in->filter->out processing.

Software-intense input devices, such as non-standard "accessibility" 
input methods, may need complex processing.  Although the hardware may 
report it's a keyboard or mouse, physically it might be a few switches 
mounted on a wheelchair and the input may need to be directed through an 
X11 app so letters or words can be assembled before being presented as 
"keyboard" input to standard X11 apps.

I know several years ago there were X11 mods to support multiple input 
methods, but this got diverted to supporting only a single active input 
method (useful for selecting a keyboard for a language).  But as this 
group knows, system-level support is also needed -- fortunately this 
group already has done much of this work.

RE: X compiled for evdev?

[James G. <twi...@su...>]

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> 

*de-lurking*

Good thoughts. I sadly have not had a chance to test much of the progress 
made on here in the last 6 months, but have avidly followed this group's 
travails. I fell in love with the Input API when I started playing with 
USB, and am glad to see it moving into the rest of the kernel.

A somewat unrelated question to the crew: I heard that a deadline has been
placed for the 2.5 feature freeze (Oct mumble); What, in a nutshell, of
the work you have been doing here is already inplace in the 2.5 tree? It's
been a little hard to follow the messages about patches on here sometimes.

Keep up the awesome work! It is much appreciated.

--James

*re-lurking*

Re: X compiled for evdev?

[Vojtech P. <vo...@su...>]

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.

> *de-lurking*
> 
> Good thoughts. I sadly have not had a chance to test much of the progress 
> made on here in the last 6 months, but have avidly followed this group's 
> travails. I fell in love with the Input API when I started playing with 
> USB, and am glad to see it moving into the rest of the kernel.
> 
> A somewat unrelated question to the crew: I heard that a deadline has been
> placed for the 2.5 feature freeze (Oct mumble); What, in a nutshell, of
> the work you have been doing here is already inplace in the 2.5 tree? It's
> been a little hard to follow the messages about patches on here sometimes.

Almost everything at the moment is in 2.5. We're not going to miss the
freeze.

> Keep up the awesome work! It is much appreciated.

-- 
Vojtech Pavlik
SuSE Labs

Re: X compiled for evdev?

[Franz S. <Fra...@la...>]

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.

Re: X compiled for evdev?

[Vojtech P. <vo...@su...>]

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

Re: X compiled for evdev?

[Brad H. <bh...@bi...>]

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.

Re: X compiled for evdev?

[Vojtech P. <vo...@su...>]

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

Re: X compiled for evdev?

[Brad H. <bh...@bi...>]

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.

Re: X compiled for evdev?

[Vojtech P. <vo...@su...>]

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 ar...@ca....

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

-- 
Vojtech Pavlik
SuSE Labs