|
From: Vojtech P. <vo...@su...> - 2001-08-03 18:22:33
|
On Fri, Aug 03, 2001 at 10:37:53AM -0700, James Simmons wrote: > > Or do you have any alternate proposals? > > Either way we end up with a mess. > > Method one is like the IRIX stuff: > > All input events are read from a input queue. > Their is a special /dev/qctrlN so you can control each device. > > Method two. > We use one file to see if a new device is added/remove. > Input events are read from individual devices. > > So it is really the flip side of a coin. Both methods get hairy. I prefer method two. The point is that, though not being completely straightforward, every bit is kept simple and easy to understand. > > My basic requirement (which I'm loathe to negotiate on) is this: > > > > - Hotplug and ready event notification must be available from one fd. > > - It must not be necessary to perform any blocking calls (or a > > select() except with a zero timeout) on more than a single fd, this > > single fd presumably being that mentioned above. > > > > Being able to wake the mouse driver from more than one source (ie. > > separately for /proc/input/devices and /dev/input/eventX) will require > > a level of app restructuring in more than one case which I believe is > > unnecessary and will reduce driver availability without good cause. Well, for one mouse you only need to select/read/whatever only one file/device at a time. The file may change, though. > Since this is such a issue and I also have written code to deal with this > hot plug issue I will write a library to hides all the "nasty" from the > apps. I'm not sure if you can do that for apps that pass the fd from the driver to the core to a central select() call which waits for events. If they're braindamaged enough, they can't be helped. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-08-03 19:11:15
|
> > Method one is like the IRIX stuff:
> >
> > All input events are read from a input queue.
> > Their is a special /dev/qctrlN so you can control each device.
> >
> > Method two.
> > We use one file to see if a new device is added/remove.
> > Input events are read from individual devices.
> >
> > So it is really the flip side of a coin. Both methods get hairy.
>
> I prefer method two. The point is that, though not being completely
> straightforward, every bit is kept simple and easy to understand.
Basically what we are doing is looking where to place the middleware. To
handle the one device file to many hardware devices we have to implement
some sort of filtering kernel side. The other side of the argument is we
push the filtering to userland.
Charles is looking from the userland perspective to ensure backwards
compatiablity and making it easy to program.
Vojtech and I are looking form the kernel side which involves adding
things like filters.
After much discussion at work with my co worker we came up with the
pros and the cons of having it userland or kernel side. We looked at what
already exist. For linux we pretty much already have a system setup kernel
side. Its the network layer. We can do various types of network filtering.
From the network layer we can see the issues that would come up. One is
backwards compatiablity. If you upgrade your kernel you might have to
upgrade your software. Often we are left keeping the old code around just
to be backwards compatiable. Example is the ip toolchains. As you can see
in as time goes on the rules get more complex and more code gets added to
the kernel.
The other thing is userland has far better and faster evolving
tools when it comes to filtering than the kernel could ever have. Plus we
just can never know what kind of crazy filters people might want. What I
want to use my 3rd mouse only when the moon is full. This is something you
can't do easily kernel side.
The third thing about doing it userland side is if we implement a
library to hide such "nasties" is if the library API is go enough it can
be made to work on other platforms like BSD or solaris. This is the most
powerful thing since we can hide the very different types of behaviours
each system can exhibit and make them appear to work the same on each
system. Programs can be made to work on different platforms very easily.
> > Since this is such a issue and I also have written code to deal with this
> > hot plug issue I will write a library to hides all the "nasty" from the
> > apps.
>
> I'm not sure if you can do that for apps that pass the fd from the
> driver to the core to a central select() call which waits for events. If
> they're braindamaged enough, they can't be helped.
No doubt they have to reworked to use such a library but the benifeits
outway the cost. If the api is simple and exist on many platforms you will
see people migrate really fast.
|
|
From: Charles D. <cd...@mv...> - 2001-08-03 19:29:25
|
On Fri, Aug 03, 2001 at 12:10:55PM -0700, James Simmons wrote: > > > Since this is such a issue and I also have written code to deal with = this > > > hot plug issue I will write a library to hides all the "nasty" from t= he > > > apps. > >=20 > > I'm not sure if you can do that for apps that pass the fd from the > > driver to the core to a central select() call which waits for events. If > > they're braindamaged enough, they can't be helped. >=20 > No doubt they have to reworked to use such a library but the benifeits > outway the cost. If the api is simple and exist on many platforms you will > see people migrate really fast. I can see this API getting widespread use as soon as Ruby makes it in to the official kernel (if it only provides an interface to the input core) or sooner (if it additionally provides an interface to /dev/psaux, /dev/ts [Compaq], /dev/touchpanel [Transmeta], /dev/tpanel [VR41xx/Embedded Planet/HIOX] and all the other individual proprietary interfaces out there). Of course, those interfaces won't last long (as they'll hopefully all make it into the input core), but they'd be great for encouraging early adoption. Something providing all these capabilities would certainly make reworking a few APIs quite worthwhile. |
|
From: Charles D. <cd...@mv...> - 2001-08-03 19:08:18
|
On Fri, Aug 03, 2001 at 10:37:53AM -0700, James Simmons wrote: > Since this is such a issue and I also have written code to deal with this > hot plug issue I will write a library to hides all the "nasty" from the > apps. As long as all communications from the library come through a single pipe, that solution should work beautifully. |
