Menu
▾
▴
linuxconsole-dev
|
From: Charles D. <cd...@mv...> - 2001-07-22 15:42:37
|
This patch stops mousedev from dividing by zero when handling events
from (faulty?) drivers which send ABS_* events but don't set
dev->abs{min,max}.
Index: mousedev.c
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/input/mousedev.c,v
retrieving revision 1.27
diff -u -3 -r1.27 mousedev.c
--- mousedev.c 2001/06/24 15:16:34 1.27
+++ mousedev.c 2001/07/22 15:39:06
@@ -97,15 +97,25 @@
if (test_bit(BTN_TRIGGER, handle->dev->keybit))
break;
switch (code) {
- case ABS_X:
+ case ABS_X:
size = handle->dev->absmax[ABS_X] - handle->dev->absmin[ABS_X];
- list->dx += (value * xres - list->oldx) / size;
- list->oldx += list->dx * size;
+ if(size != 0) {
+ list->dx += (value * xres - list->oldx) / size;
+ list->oldx += list->dx * size;
+ } else {
+ list->dx += value - list->oldx;
+ list->oldx += list->dx;
+ }
break;
case ABS_Y:
size = handle->dev->absmax[ABS_Y] - handle->dev->absmin[ABS_Y];
- list->dy -= (value * yres - list->oldy) / size;
- list->oldy -= list->dy * size;
+ if(size != 0) {
+ list->dy -= (value * yres - list->oldy) / size;
+ list->oldy -= list->dy * size;
+ } else {
+ list->dy -= value - list->oldy;
+ list->oldy -= list->dy;
+ }
break;
}
break;
|
|
From: James S. <jsi...@tr...> - 2001-07-25 02:59:42
|
> This patch stops mousedev from dividing by zero when handling events
> from (faulty?) drivers which send ABS_* events but don't set
> dev->abs{min,max}.
Hm. I have done this :-/ Shouldn't it print a error instead?
>
> Index: mousedev.c
> ===================================================================
> RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/input/mousedev.c,v
> retrieving revision 1.27
> diff -u -3 -r1.27 mousedev.c
> --- mousedev.c 2001/06/24 15:16:34 1.27
> +++ mousedev.c 2001/07/22 15:39:06
> @@ -97,15 +97,25 @@
> if (test_bit(BTN_TRIGGER, handle->dev->keybit))
> break;
> switch (code) {
> - case ABS_X:
> + case ABS_X:
> size = handle->dev->absmax[ABS_X] - handle->dev->absmin[ABS_X];
> - list->dx += (value * xres - list->oldx) / size;
> - list->oldx += list->dx * size;
> + if(size != 0) {
> + list->dx += (value * xres - list->oldx) / size;
> + list->oldx += list->dx * size;
> + } else {
> + list->dx += value - list->oldx;
> + list->oldx += list->dx;
> + }
> break;
> case ABS_Y:
> size = handle->dev->absmax[ABS_Y] - handle->dev->absmin[ABS_Y];
> - list->dy -= (value * yres - list->oldy) / size;
> - list->oldy -= list->dy * size;
> + if(size != 0) {
> + list->dy -= (value * yres - list->oldy) / size;
> + list->oldy -= list->dy * size;
> + } else {
> + list->dy -= value - list->oldy;
> + list->oldy -= list->dy;
> + }
> break;
> }
> break;
>
>
|
|
From: Charles D. <cd...@mv...> - 2001-07-25 03:22:52
|
On Tue, Jul 24, 2001 at 07:59:32PM -0700, James Simmons wrote:
> > This patch stops mousedev from dividing by zero when handling events
> > from (faulty?) drivers which send ABS_* events but don't set
> > dev->abs{min,max}.
>=20
> Hm. I have done this :-/ Shouldn't it print a error instead?
Not necessarily -- situations can exist where the min/max absolute
values are unavailable and the resolution of the touchpanel matches
that of the LCD it covers (and thus no scaling is, literally, good
scaling). While one could try have the user enter the appropriate
value at configure- or module load-time, the easiest solution here is
simply to allow the touchpanel driver not to provide a resolution if
one is unavailable.
The presumption that a touchpanel's resolution matches that of its
correspending LCD is frequently correct -- I've got four touchpanel
devices in the testing lab over here; not one of them has a resolution
different from that of the LCD panel it's connected to.
Thus, I'd like to have this be Correct Behaviour for an event handler.
(Some changes are also needed to tsdev.c; I'd be glad to provide
them).
|
|
From: James S. <jsi...@tr...> - 2001-07-25 04:08:52
|
Okay. I looked over the code. I had to make sure the guassian filter we have didn't use this field. Also joydev.c uses absmax but also long as dev->absmax[j] == dev->absmin[j] we don't have to worry about divide by zero errors. We had those errors anyways if the user forgot to set them. So this patch avoids a nasty error. If the user has to scale it then his driver will misbehavior but it will not oops. Which IMO is a good thing. Patch applied. > Not necessarily -- situations can exist where the min/max absolute > values are unavailable and the resolution of the touchpanel matches > that of the LCD it covers (and thus no scaling is, literally, good > scaling). I have noticed this too. Especially since most framebuffers on embedded devices have fixed resolutions. The only except so far is the iPAQ h3600 touchscreen. It is 1024x768 while the screen is 320x240. It is the only exception so far. > While one could try have the user enter the appropriate > value at configure- or module load-time, the easiest solution here is > simply to allow the touchpanel driver not to provide a resolution if > one is unavailable. Personally I hate the enter screen resolution stuff. I don't think Vojtech cares for either but it is needed for X windows. Especially since the developement cycle is so longgggggggggggggggggggg. Hopefully /dev/mouse will go away but that will take time. > Thus, I'd like to have this be Correct Behaviour for an event handler. > (Some changes are also needed to tsdev.c; I'd be glad to provide > them). Applied your patch. Yes I would like that patch. |
|
From: Charles D. <cd...@mv...> - 2001-07-25 08:58:55
Attachments:
tsdev-fixup.patch
|
On Tue, Jul 24, 2001 at 09:08:38PM -0700, James Simmons wrote: > Applied your patch. Yes I would like that patch. Here she be. This is a bit more comprehensive than what I had planned -- the original patch I'd just done off the top of my head, and when I tested it pre-submission, I found a number of preexisting issues. It's since become more of a general bugfix-and-enhancement of the tsdev driver, which also happens to stop it from oopsing when no scaling data is available. I've modified (and tested) it to work well in converting mouse-generated data for touchpad use. As my test host doesn't have any touchpanels on the moment and I don't (yet!) have a test program to generate absolute and pressure events, I haven't tested them. The code is simple enough, however, that it should Just Work. (*) tsdev really, really needs to be assigned a minor range that doesn't conflict with anything else. I left it starting at 32 in this patch, to let the assignment be done by one of 'yall maintainer-folk (during testing, I moved it over to overlap with the jsdev range, but that doesn't work well either). Enjoy! (*) - #31 from the Infamous Last Words list |
|
From: James S. <jsi...@tr...> - 2001-07-25 19:55:45
|
> > Applied your patch. Yes I would like that patch. > > Here she be. Applied. > tsdev really, really needs to be assigned a minor range that doesn't > conflict with anything else. I left it starting at 32 in this patch, Yeah I know about this problem. evdev keeps adding and adding devices. Placeing a device high above it lower the number of evdev devices you can use. > (*) - #31 from the Infamous Last Words list Hm. |
|
From: Vojtech P. <vo...@su...> - 2001-07-29 18:36:46
|
On Tue, Jul 24, 2001 at 09:08:38PM -0700, James Simmons wrote: > > Okay. I looked over the code. I had to make sure the guassian filter we > have didn't use this field. Also joydev.c uses absmax but also long as > dev->absmax[j] == dev->absmin[j] we don't have to worry about divide by > zero errors. We had those errors anyways if the user forgot to set them. > So this patch avoids a nasty error. If the user has to scale it then his > driver will misbehavior but it will not oops. Which IMO is a good thing. > Patch applied. > > > Not necessarily -- situations can exist where the min/max absolute > > values are unavailable and the resolution of the touchpanel matches > > that of the LCD it covers (and thus no scaling is, literally, good > > scaling). > > I have noticed this too. Especially since most framebuffers on embedded > devices have fixed resolutions. The only except so far is the iPAQ h3600 > touchscreen. It is 1024x768 while the screen is 320x240. It is the only > exception so far. > > > While one could try have the user enter the appropriate > > value at configure- or module load-time, the easiest solution here is > > simply to allow the touchpanel driver not to provide a resolution if > > one is unavailable. > > Personally I hate the enter screen resolution stuff. I don't think Vojtech > cares for either but it is needed for X windows. I don't like the way as well. I don't like having mousedev at all. But so far it was very useful. Perhaps we could somehow tell mousedev about the screen resolution when we're not in X? That would make it work nicely in console mode with eg. GPM. > Especially since the > developement cycle is so longgggggggggggggggggggg. Hopefully /dev/mouse > will go away but that will take time. > > > Thus, I'd like to have this be Correct Behaviour for an event handler. > > (Some changes are also needed to tsdev.c; I'd be glad to provide > > them). > > Applied your patch. Yes I would like that patch. I agree that we should avoid oopses and thus the patch is OK, but still I think all drivers should provide min and max for the absolute axes. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-07-31 03:53:37
|
> I don't like the way as well. I don't like having mousedev at all. But > so far it was very useful. Perhaps we could somehow tell mousedev about > the screen resolution when we're not in X? That would make it work > nicely in console mode with eg. GPM. This will not be easy. Their is also the case with embedded systems that don't use a VT console. I run my ipaq using ruby only with a serial console. > I agree that we should avoid oopses and thus the patch is OK, but still > I think all drivers should provide min and max for the absolute axes. I have to agree here. For the ipaq I basically read raw data from the hardware to see what the maximum and minimum values reported back. For the ipaq it is 1024x768 but yet the SA1100 framebuffer is at 240x320. |
|
From: Vojtech P. <vo...@su...> - 2001-07-29 18:31:54
|
On Tue, Jul 24, 2001 at 08:21:43PM -0700, Charles Duffy wrote:
> On Tue, Jul 24, 2001 at 07:59:32PM -0700, James Simmons wrote:
> > > This patch stops mousedev from dividing by zero when handling events
> > > from (faulty?) drivers which send ABS_* events but don't set
> > > dev->abs{min,max}.
> >
> > Hm. I have done this :-/ Shouldn't it print a error instead?
>
> Not necessarily -- situations can exist where the min/max absolute
> values are unavailable and the resolution of the touchpanel matches
> that of the LCD it covers (and thus no scaling is, literally, good
> scaling). While one could try have the user enter the appropriate
> value at configure- or module load-time, the easiest solution here is
> simply to allow the touchpanel driver not to provide a resolution if
> one is unavailable.
I don't think this is good. For absolute devices there should be a
defined range. It's not just mousedev who uses the values.
> The presumption that a touchpanel's resolution matches that of its
> correspending LCD is frequently correct -- I've got four touchpanel
> devices in the testing lab over here; not one of them has a resolution
> different from that of the LCD panel it's connected to.
I have a transparent Gunze touchpanel here whose physical resolution is
1024x1024 (although it has a 3:4 aspect ratio), on a 800x600 TFT screen.
So there exist panels for which you need to scale. But you shouldn't
need mousedev for touchpanels in the first place.
> Thus, I'd like to have this be Correct Behaviour for an event handler.
> (Some changes are also needed to tsdev.c; I'd be glad to provide
> them).
I think much better would be letting mousedev know both the correct
screen and touchpanel resolution.
--
Vojtech Pavlik
SuSE Labs
|
|
From: Charles D. <cd...@mv...> - 2001-07-29 20:23:04
|
On Sun, Jul 29, 2001 at 08:31:38PM +0200, Vojtech Pavlik wrote: > On Tue, Jul 24, 2001 at 08:21:43PM -0700, Charles Duffy wrote: > > Thus, I'd like to have this be Correct Behaviour for an event handler. > > (Some changes are also needed to tsdev.c; I'd be glad to provide > > them). >=20 > I think much better would be letting mousedev know both the correct > screen and touchpanel resolution. Yes, if the information is available. If it isn't, it makes sense for an event handler to attempt to function nevertheless rather than give up utterly. It also doesn't make sense to require the device generating events to ask the user for numbers which aren't otherwise available to it if in most application those numbers will serve no purpose. Thus, while I agree that an event generator should be as strict as possible in what it generates -- providing resolution numbers if at all available -- an event handler should still be able to Do The Right Thing (or the closest possible approximation) if the numbers just aren't there. |
|
From: Vojtech P. <vo...@su...> - 2001-07-29 21:00:24
|
On Sun, Jul 29, 2001 at 01:21:29PM -0700, Charles Duffy wrote: > On Sun, Jul 29, 2001 at 08:31:38PM +0200, Vojtech Pavlik wrote: > > On Tue, Jul 24, 2001 at 08:21:43PM -0700, Charles Duffy wrote: > > > Thus, I'd like to have this be Correct Behaviour for an event handler. > > > (Some changes are also needed to tsdev.c; I'd be glad to provide > > > them). > > > > I think much better would be letting mousedev know both the correct > > screen and touchpanel resolution. > > Yes, if the information is available. If it isn't, it makes sense for > an event handler to attempt to function nevertheless rather than give > up utterly. I agree with the changes to mousedev (and/or tsdev) because they make it more robust. But this is *not* a reason to omit setting the absmin/absmax in the touchscreen driver. > It also doesn't make sense to require the device > generating events to ask the user for numbers which aren't otherwise > available to it if in most application those numbers will serve no > purpose. Yes. But it would definitely be nice if it could get the numbers from the console subsystem - in many cases they are known. Namely on handhelds. By the way, now that we have tsdev, perhaps support for abs values in mousedev could be dropped completely, because X will be able to read even say USB tablets via the tsdev device as absolute values? > Thus, while I agree that an event generator should be as strict as > possible in what it generates -- providing resolution numbers if at > all available -- an event handler should still be able to Do The Right > Thing (or the closest possible approximation) if the numbers just > aren't there. It's good we agree perfectly then. -- Vojtech Pavlik SuSE Labs |
|
From: Charles D. <cd...@mv...> - 2001-07-30 01:22:24
|
On Sun, Jul 29, 2001 at 11:00:08PM +0200, Vojtech Pavlik wrote: > By the way, now that we have tsdev, perhaps support for abs values > in mousedev could be dropped completely, because X will be able to > read even say USB tablets via the tsdev device as absolute values? I'd rather not do this yet -- some applications don't support /dev/ts properly, and it's extremely useful to be able to use either driver with either kind of input device (in the case where one has a system with both a mouse and a touchscreen attached). This will be less acute when a single interface is available which provides applications with all available information (such as James's suggestion of an evdev mixer which adds a field giving the minor number of the evdev device correspending with the source). |
|
From: Vojtech P. <vo...@su...> - 2001-07-30 07:20:12
|
On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote: > On Sun, Jul 29, 2001 at 11:00:08PM +0200, Vojtech Pavlik wrote: > > By the way, now that we have tsdev, perhaps support for abs values > > in mousedev could be dropped completely, because X will be able to > > read even say USB tablets via the tsdev device as absolute values? > > I'd rather not do this yet -- some applications don't support /dev/ts > properly, and it's extremely useful to be able to use either driver > with either kind of input device (in the case where one has a system > with both a mouse and a touchscreen attached). > > This will be less acute when a single interface is available which > provides applications with all available information (such as James's > suggestion of an evdev mixer which adds a field giving the minor > number of the evdev device correspending with the source). Do we really need an evdev mixer? Isn't it easier to just try to open and read all the evdev devices? -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-07-30 16:42:23
|
> > This will be less acute when a single interface is available which > > provides applications with all available information (such as James's > > suggestion of an evdev mixer which adds a field giving the minor > > number of the evdev device correspending with the source). > > Do we really need an evdev mixer? Isn't it easier to just try to open > and read all the evdev devices? Actually the problem is hot plug. For the software at work I basically have a thread that runs so often to see if a new device is attached. This method really sucks. We really need away to know when a new device has attached. I remember you mentioned having something in proc for that. Perhaps we should explore this path? |
|
From: Vojtech P. <vo...@su...> - 2001-07-30 19:49:46
|
On Mon, Jul 30, 2001 at 09:42:06AM -0700, James Simmons wrote: > > > > This will be less acute when a single interface is available which > > > provides applications with all available information (such as James's > > > suggestion of an evdev mixer which adds a field giving the minor > > > number of the evdev device correspending with the source). > > > > Do we really need an evdev mixer? Isn't it easier to just try to open > > and read all the evdev devices? > > Actually the problem is hot plug. For the software at work I basically > have a thread that runs so often to see if a new device is attached. > This method really sucks. We really need away to know when a new device > has attached. I remember you mentioned having something in proc for that. > Perhaps we should explore this path? Yep. I'll try to create something today/tomorrow. -- Vojtech Pavlik SuSE Labs |
|
From: Charles D. <cd...@mv...> - 2001-07-30 18:34:51
|
On Mon, Jul 30, 2001 at 09:19:53AM +0200, Vojtech Pavlik wrote: > On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote: > > This will be less acute when a single interface is available which > > provides applications with all available information (such as > > James's suggestion of an evdev mixer which adds a field giving the > > minor number of the evdev device correspending with the source). >=20 > Do we really need an evdev mixer? Isn't it easier to just try to > open and read all the evdev devices? No, it isn't. There's quite a bit of software written (Qt/E, for one; Microwindows, for another) which already has a mouse-handling architecture which allows the mouse driver to open() a file, which is then returned by the driver; the framework select()s on that file (among other things), and calls the mouse event handler when select returns with the appropriate fd. Writing evdev drivers for this software would mean not only writing a new driver module (a trivial task) but rearchitecting the framework to allow drivers to own (and pass to the core) multiple fds, and attempting to get these patches accepted by each of the projects in question. Furthermore, there's no means of detecting disconnection/reconnection -- another thing that an extended evdev mixer could (and, IMHO, /should/) report. Assuming that all evdev devices support USB is faulty -- I personally have some that aren't (including some non-hot-pluggable devices which may be rmmod'd on entry to powersaving mode and re-insmod'd on restart; it's quite unuseful if applications can't detect new minor numbers and such as a result of such things). |
|
From: Vojtech P. <vo...@su...> - 2001-07-30 20:20:02
|
On Mon, Jul 30, 2001 at 11:33:24AM -0700, Charles Duffy wrote: > On Mon, Jul 30, 2001 at 09:19:53AM +0200, Vojtech Pavlik wrote: > > On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote: > > > This will be less acute when a single interface is available which > > > provides applications with all available information (such as > > > James's suggestion of an evdev mixer which adds a field giving the > > > minor number of the evdev device correspending with the source). > > > > Do we really need an evdev mixer? Isn't it easier to just try to > > open and read all the evdev devices? > > No, it isn't. > > There's quite a bit of software written (Qt/E, for one; Microwindows, > for another) which already has a mouse-handling architecture which > allows the mouse driver to open() a file, which is then returned by > the driver; the framework select()s on that file (among other things), > and calls the mouse event handler when select returns with the > appropriate fd. Unfortunately this probably won't help us with hotplugging. > Writing evdev drivers for this software would mean not only writing a > new driver module (a trivial task) but rearchitecting the framework to > allow drivers to own (and pass to the core) multiple fds, and > attempting to get these patches accepted by each of the projects in > question. Only if you want to use more than one mouse at a time. > Furthermore, there's no means of detecting disconnection/reconnection > -- another thing that an extended evdev mixer could (and, IMHO, > /should/) report. Disconnection is signalled by evdev by returning -ENODEV on read(). The process will be woken up on disconnect. > Assuming that all evdev devices support USB is > faulty -- I personally have some that aren't (including some > non-hot-pluggable devices which may be rmmod'd on entry to powersaving > mode and re-insmod'd on restart; it's quite unuseful if applications > can't detect new minor numbers and such as a result of such things). How would you propose detecting new minor numbers? I'd suggest doing it the same way as USB does with new devices - read /proc/input/devices for an uptodate list, select() on the very same file to get notified of its changes. -- Vojtech Pavlik SuSE Labs |
|
From: Charles D. <cd...@mv...> - 2001-07-30 21:07:43
|
On Mon, Jul 30, 2001 at 10:19:47PM +0200, Vojtech Pavlik wrote: > On Mon, Jul 30, 2001 at 11:33:24AM -0700, Charles Duffy wrote: > > There's quite a bit of software written (Qt/E, for one; Microwindows, > > for another) which already has a mouse-handling architecture which > > allows the mouse driver to open() a file, which is then returned by > > the driver; the framework select()s on that file (among other things), > > and calls the mouse event handler when select returns with the > > appropriate fd. >=20 > Unfortunately this probably won't help us with hotplugging. If the only change is to add an extra field with the minor number, then it won't. If, however, a means of notifying processes of added/removed devices (ie. creation of a EV_CON w/ connection and disconnection events, the latter only sent through the mixer), it will do plenty of good. > > Writing evdev drivers for this software would mean not only writing a > > new driver module (a trivial task) but rearchitecting the framework to > > allow drivers to own (and pass to the core) multiple fds, and > > attempting to get these patches accepted by each of the projects in > > question. >=20 > Only if you want to use more than one mouse at a time. =2E..or you want to have one device which, when opened, will *always* get your mouse (whichever kind it may be). This is not an uncommon case -- and being able to switch mice without restarting X (or whatever the app may be) is most certainly useful. > > Furthermore, there's no means of detecting disconnection/reconnection > > -- another thing that an extended evdev mixer could (and, IMHO, > > /should/) report. >=20 > Disconnection is signalled by evdev by returning -ENODEV on read(). The > process will be woken up on disconnect. Quite right. But in Microwindows (for instance), disconnection of the mouse will cause the system to die, without even calling the mouse driver for its advice. One of the assumptions the system is based around -- an assumption which is valid everywhere else -- is that mice will *not* be hot-plugged, or that if they are the device will still remain valid in the mean-time. I'm not familiar with the behaviour of Qt/E or X in these cases, but I'd be unsuprised were they similar. > > Assuming that all evdev devices support USB is > > faulty -- I personally have some that aren't (including some > > non-hot-pluggable devices which may be rmmod'd on entry to powersaving > > mode and re-insmod'd on restart; it's quite unuseful if applications > > can't detect new minor numbers and such as a result of such things). >=20 > How would you propose detecting new minor numbers? I'd suggest doing it > the same way as USB does with new devices - read /proc/input/devices for > an uptodate list, select() on the very same file to get notified of its > changes. If the evdev mixer is implemented inside the evdev module, it will have access to the evdev_list, and thus the evdev struct including the minor number. As for /proc/input/devices, while the concept is great in theory, it would vastly complicate the task of writing evdev-based drivers for application software. It will mean that the existing mouse interfaces (which near-universally assume that an input driver, when it initializes, will only need to be notified of events from one fd; that this fd will never change; that when the file is closed on the other side, there's no recovery possible) are insufficient, and that the userland frameworks providing them will need to be rewritten (perhaps meaning a rewrite for the other mouse drivers included in these packages as well). In short, making it necessary for a mouse driver to monitor more than one file means /a whole lot more work/ for those of us writing evdev drivers on the userspace end -- and that's not good for anyone. |
|
From: James S. <jsi...@tr...> - 2001-08-02 17:08:15
|
> I'd rather not do this yet -- some applications don't support /dev/ts > properly, and it's extremely useful to be able to use either driver > with either kind of input device (in the case where one has a system > with both a mouse and a touchscreen attached). Which apps? Only X to my knowledge and a few other unknow apps use it. In the end apps should be ported over to use the event interface. > This will be less acute when a single interface is available which > provides applications with all available information (such as James's > suggestion of an evdev mixer which adds a field giving the minor > number of the evdev device correspending with the source). This is for /dev/shmiq support on IRIX platforms. BTW it is not a easy device to work with. |
|
From: Charles D. <cd...@mv...> - 2001-08-02 18:15:41
|
On Thu, Aug 02, 2001 at 10:07:16AM -0700, James Simmons wrote: > > I'd rather not do this yet -- some applications don't support /dev/ts > > properly, and it's extremely useful to be able to use either driver > > with either kind of input device (in the case where one has a system > > with both a mouse and a touchscreen attached). >=20 > Which apps? Only X to my knowledge and a few other unknow apps use it.=20 > In the end apps should be ported over to use the event interface.=20 Are you asking which apps use mousedev? GtkFB, QtE, Nano-X (Microwindows) and gpm, to name a few off the top of my head. Or are you asking what uses Compaq's /dev/ts? X, Microwindows and QtE (though it looks like it was patched in at the last minute there; additionally, X's /dev/ts support is rather broken, having no support for moving the cursor without the button depressed, though we should be fixing that here soon). I absolutely agree that apps should be ported to use the event interface -- that's why I'm arguing for an event interface which is easy to port to (ie. doesn't require any framework changes, which listening on multiple fds does impose). > > This will be less acute when a single interface is available which > > provides applications with all available information (such as James's > > suggestion of an evdev mixer which adds a field giving the minor > > number of the evdev device correspending with the source). >=20 > This is for /dev/shmiq support on IRIX platforms. BTW it is not a easy > device to work with. Ahh -- I misread you. 'Twould work rather well for evdev, though, don't ya think? Or do you have any alternate proposals? Note that I won't be able to spend the time to write such an evdev mixer and port the apps we support here (pretty much those listed above, and X) to it at least until next month. When the time is available, however, I'd be glad to do so; in the interm, we can come to a design that everyone can agree to. 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. |
|
From: Vojtech P. <vo...@su...> - 2001-08-02 18:31:01
|
On Thu, Aug 02, 2001 at 11:13:21AM -0700, Charles Duffy wrote:
> 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.
Would there be a problem with
1) Opening and parsing /proc/input/devices.
1a) If no device is found either go to 1) if non-blocking is required
or select() on /proc/input/devices and then go to 1)
2) Opening the correct /proc/input/eventX
3) Read the event data
4) If -ENODEV received go to 1)
We can't sanely mix all event sources into one, because there are
devices which generate lots of events and it'd be not a good idea in my
opinion to feed all of them to the app.
--
Vojtech Pavlik
SuSE Labs
|
|
From: Charles D. <cd...@mv...> - 2001-08-02 18:59:50
|
On Thu, Aug 02, 2001 at 08:30:42PM +0200, Vojtech Pavlik wrote: > On Thu, Aug 02, 2001 at 11:13:21AM -0700, Charles Duffy wrote: > > 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. >=20 > Would there be a problem with >=20 > 1) Opening and parsing /proc/input/devices. > 1a) If no device is found either go to 1) if non-blocking is required > or select() on /proc/input/devices and then go to 1) > 2) Opening the correct /proc/input/eventX > 3) Read the event data > 4) If -ENODEV received go to 1) There are a few problems here: 1. It isn't possible to read from two devices simultaneously while still conforming to the single-source requirement. This is extremely useful when, for instance, a device has both a touchpanel and USB ports (ie. the Hitachi webpad). 2. Some mechanism will be required to allow the app to modify the fd in the select list used by the framework (in switching between steps 1 and 2 or 4). I'm looking over the apps which will require modification. Qt/E (thanks to its signal/slot notification) will be fairly straightforward to support with the plan you propose; XFree86 also looks straightforward (as much as it ever is). Microwindows, on the other hand, will not be possible without architectural changes as it requires a non-blocking mouse driver and provides no means of changing the single fd which is select()ed on after open. Looping inside the driver between 1 and 1a is as bad as a blocking select -- the point is that the mouse driver's functions should be active very little time, and only called when the single fd which it select()s on is ready. > We can't sanely mix all event sources into one, because there are > devices which generate lots of events and it'd be not a good idea in > my opinion to feed all of them to the app. So the app can use ioctl()s to decide what it does and doesn't wish to hear. Perhaps the mixer initially provides nothing but attach and detach events until the app adds additional sources via ioctl()s. |
|
From: James S. <jsi...@tr...> - 2001-08-03 18:04:41
|
> > Would there be a problem with > > > > 1) Opening and parsing /proc/input/devices. > > 1a) If no device is found either go to 1) if non-blocking is required > > or select() on /proc/input/devices and then go to 1) > > 2) Opening the correct /dev/input/eventX > > 3) Read the event data > > 4) If -ENODEV received go to 1) > > There are a few problems here: > > 1. It isn't possible to read from two devices simultaneously while > still conforming to the single-source requirement. This is > extremely useful when, for instance, a device has both a touchpanel > and USB ports (ie. the Hitachi webpad). WHat do you mean by single source requirement? > 2. Some mechanism will be required to allow the app to modify the fd > in the select list used by the framework (in switching between > steps 1 and 2 or 4). Example? > > devices which generate lots of events and it'd be not a good idea in > > my opinion to feed all of them to the app. > > So the app can use ioctl()s to decide what it does and doesn't wish to > hear. Perhaps the mixer initially provides nothing but attach and > detach events until the app adds additional sources via ioctl()s. This is the mess a was talking about with the IRIX implementation. The more devices you have the more chance of losing event packets since you get a flood of them then. Plus what if one device goes crazy. Then 90% of the event packets coming in block the other devices. We actually had this problem with one device here at work. What had to do certain tricks to make sure everything got a fair share. The IRIX implement uses the qnctrl device files to manage this. |
|
From: Vojtech P. <vo...@su...> - 2001-08-03 18:23:34
|
On Fri, Aug 03, 2001 at 11:04:35AM -0700, James Simmons wrote: > > > > Would there be a problem with > > > > > > 1) Opening and parsing /proc/input/devices. > > > 1a) If no device is found either go to 1) if non-blocking is required > > > or select() on /proc/input/devices and then go to 1) > > > 2) Opening the correct /dev/input/eventX > > > 3) Read the event data > > > 4) If -ENODEV received go to 1) > > > > There are a few problems here: > > > > 1. It isn't possible to read from two devices simultaneously while > > still conforming to the single-source requirement. This is > > extremely useful when, for instance, a device has both a touchpanel > > and USB ports (ie. the Hitachi webpad). > > WHat do you mean by single source requirement? > > > 2. Some mechanism will be required to allow the app to modify the fd > > in the select list used by the framework (in switching between > > steps 1 and 2 or 4). > > Example? > > > > devices which generate lots of events and it'd be not a good idea in > > > my opinion to feed all of them to the app. > > > > So the app can use ioctl()s to decide what it does and doesn't wish to > > hear. Perhaps the mixer initially provides nothing but attach and > > detach events until the app adds additional sources via ioctl()s. > > This is the mess a was talking about with the IRIX implementation. The > more devices you have the more chance of losing event packets since you > get a flood of them then. Plus what if one device goes crazy. Then 90% > of the event packets coming in block the other devices. We actually had > this problem with one device here at work. What had to do certain tricks > to make sure everything got a fair share. The IRIX implement uses the > qnctrl device files to manage this. I really would like to avoid this route if possible. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-08-03 17:38:09
|
> you asking what uses Compaq's /dev/ts? X, Microwindows and QtE (though > it looks like it was patched in at the last minute there; > additionally, X's /dev/ts support is rather broken, having no support > for moving the cursor without the button depressed, though we should > be fixing that here soon). The /dev/ts stuff. I didn't expect it to be so broken. > I absolutely agree that apps should be ported to use the event > interface -- that's why I'm arguing for an event interface which is > easy to port to (ie. doesn't require any framework changes, which > listening on multiple fds does impose). > Ahh -- I misread you. 'Twould work rather well for evdev, though, > don't ya think? > > 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. > 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. 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X