linuxconsole-dev

Re: mousedev patch

[Charles D. <cd...@mv...>]

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.

Re: [PATCH] gamecon.c change for SNES controller (fwd)

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

On Tue, Jul 24, 2001 at 07:55:57PM -0700, James Simmons wrote:
> 
> Patch for the SNES controller attached to a parallel port. I don't have
> this hardware so please test it.

Already long in the CVS.

> 
> >The old code was giving the same values when you pressed right or left or
> >when  you pressed up or down. The new code have been done to not use
> >expensive codification (i.e. multiplication).
> 
> --- drivers/char/joystick/gamecon.c.orig Sat Jul 14 19:03:12 2001
> +++ drivers/char/joystick/gamecon.c     Wed Jul 18 16:00:50 2001
> @@ -345,8 +345,8 @@
>                         s = gc_status_bit[i];
>  
>                         if (s & (gc->pads[GC_NES] | gc->pads[GC_SNES])) {
> -                               input_report_abs(dev + i, ABS_X, ! - !(s 
> & data[6]) - !(s & data[7]));
> -                               input_report_abs(dev + i, ABS_Y, ! - !(s 
> & data[4]) - !(s & data[5]));
> +                               input_report_abs(dev + i, ABS_X, - !!(s 
> & data[6]) + !!(s & data[7]));
> +                               input_report_abs(dev + i, ABS_Y, - !!(s 
> & data[4]) + !!(s & data[5]));
>                         }
>  
>                         if (s & gc->pads[GC_NES])
> 
> --- end of patch ---
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

-- 
Vojtech Pavlik
SuSE Labs

Re: mousedev patch

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

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

Re: mousedev patch

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

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

[ANONOUNCE] Synced with 2.4.7.

[James S. <jsi...@tr...>]

Ruby has been synced with 2.4.7 and 2.4.7-rmk1 (arm tree). Both compile.
Have fun.

Some of the new stuff. 

We have new serial drivers to replace the old ones. 

Re: tsdev mixer?

[Charles D. <cd...@mv...>]

On Wed, Jul 25, 2001 at 02:57:47PM -0700, James Simmons wrote:
> Okay you have some points here. Of course this driver will not behave
> properly for PDA's with two touchscreens. Yes I have seen such devices 
> in japan. oF course the compaq interface is broken in this manner as well.

The attached patch does everything yesterday's does, and adds a tsdev
mixer device.

Re: tsdev mixer?

[James S. <jsi...@tr...>]

> A number of apps already exist that use /dev/ts w/ the Compaq
> touchscreen protocol. These apps try to open '/dev/ts' (a single
> device) and use it for all input. 

I noticed that. Especially since I rewrote that driver.  I managed to
convince Jamey Hicks to migrate over to the input api :-) 

> Having a tsdev mixer device would
> allow /dev/ts to be symlinked to this device, and all mice/touchpanels
> would suddenly Just Work without any userland code changes.
> 
> Supporting these legacy apps was the original point of having tsdev in
> the first place, but separating the tsdev devices reduces its
> effectiveness in reaching that goal (as it ensures that any legacy app
> can only feed from one device at a time). Thus, a mixer here would be
> the Right Thing to do.

Okay you have some points here. Of course this driver will not behave
properly for PDA's with two touchscreens. Yes I have seen such devices 
in japan. oF course the compaq interface is broken in this manner as well.

Re: tsdev mixer?

[Charles D. <cd...@mv...>]

On Wed, Jul 25, 2001 at 01:33:13PM -0700, James Simmons wrote:
> > Would anyone object if tsdev gained a mixer device? (I ask because
> > these have been a bit controversial elsewhere).
>=20
> I would rather have a generic mixer device. The only thing is you
> would need a special data struct to tell devices apart. It could get
> very mess for absolute devices otherwise. I would suggest for a
> device id the minor number of the /dev/input/eventX device.

Yup, that's a Very Good Thing to do -- but it leaves the immediate
issue here unsolved.

A number of apps already exist that use /dev/ts w/ the Compaq
touchscreen protocol. These apps try to open '/dev/ts' (a single
device) and use it for all input. Having a tsdev mixer device would
allow /dev/ts to be symlinked to this device, and all mice/touchpanels
would suddenly Just Work without any userland code changes.

Supporting these legacy apps was the original point of having tsdev in
the first place, but separating the tsdev devices reduces its
effectiveness in reaching that goal (as it ensures that any legacy app
can only feed from one device at a time). Thus, a mixer here would be
the Right Thing to do.

mixers and such

[James S. <jsi...@tr...>]

Speaking of what happened to the remote input device? I remember their
where a bunch of patches but nothing came of it. 

Re: tsdev mixer?

[James S. <jsi...@tr...>]

> Would anyone object if tsdev gained a mixer device? (I ask because
> these have been a bit controversial elsewhere).

I would rather have a generic mixer device. The only thing is you would
need a special data struct to tell devices apart. It could get very mess
for absolute devices otherwise. I would suggest for a device id the minor
number of the /dev/input/eventX device.

Re: mousedev patch

[James S. <jsi...@tr...>]

> > 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.

Re: ps2/ new data for mouse protocol (fwd msg attached)

[Arndt S. <ab...@sr...>]

Hi Allen,

I received your following message since James Simmons CC'd it to the
linuxconsole-dev mailing list:

> > However, some mouse secrets from various sources I hacked in here:
> > http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c -
> 
> Very nice. I am currently looking for some info to solve a problem with 
> thinkpads and logitech cordless mice over ps/2. Basicly the wheel doesnt 
> work. Looking closer they dont respond to the imps/2 or mousemanps/2 
> protocol. Since cordless mice are more common than thinkpads, I think the 
> problem would be solved if it was with the mouse. So I am guessing the IBM 
> defaults to just repeating standard ps/2 protocol, and you have to first 
> trick that before you trick the mouse. Since it works in windows there IS a 
> way...
> 
> Where do I find the public available protocols, and the secrets? :)
> 
> And for the list, who should I notify that I am working on autodetecting IBM 
> thinkpad  ps/2 repeaters in mouse driver?

recently I spent a lot of time figuring out how to make a chordless wheel
mouse, which had two extra buttons on the left and on the right, work
on Linux with gpm and XFree86 4.0.3. The mouse was supposed to support
both the IntelliMouse and IntelliMouse Explorer protocol extensions,
but no matter which protocol selection I tried with gpm, the mouse would
stick in its 3 byte standard PS/2 mode. The same happened without gpm,
when I tried to use the mouse with XFree86's "ExplorerPS/2" setting.

After many hours of research I finally discovered why. The initialization
sequence used by both programs is not exactly what the mouse needs:

  - XFree86's "ExplorerPS/2" setting sends an initialization sequence of
    { 243, 200, 243, 200, 243, 80 }. For this mouse, however, the sequence
    must be { 243, 200, 243, 100, 243, 80, 243, 200, 243, 200, 243, 80 }.

  - The initialization sequence used by gpm 1.19.3 includes the byte 246
    which is meant to reset some mouse settings back to normal. However,
    for this mouse, it also resets it to 3 byte standard PS/2 mode.

I already submitted a patch to the XFree86 team, but don't know whom to
contact for the gpm fix.

I hope this helps you with your mouse!
Arndt

PS1: A good reading for mouse related stuff is Adam Chapweske's page at
http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/mouse/mouse.html.

PS2: FWIW, my mouse is a NEO AirView 405 RF, which is a OEM product sold
in Germany under multiple brand (at least Neolec, Typhoon, Dexxa) and
product names (see e.g. http://neolec.de/news/indexAirView405RF.html).

-- 
 /////    Quelltext AG -- Professional Software Services
//   //   Arndt Schoenewald <ab...@sr...>. CEO
//   //   Ostenhellweg 31, 44135 Dortmund, Germany
//  \\/   Tel +49 231 9503750, Fax +49 231 9503751
 ////\\   Web http://quelltext.com

Re: ps2/ new data for mouse protocol (fwd msg attached)

[James S. <jsi...@tr...>]

> > However, some mouse secrets from various sources I hacked in here:
> > http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c -
> 
> Very nice. I am currently looking for some info to solve a problem with 
> thinkpads and logitech cordless mice over ps/2. Basicly the wheel doesnt 
> work. Looking closer they dont respond to the imps/2 or mousemanps/2 
> protocol. Since cordless mice are more common than thinkpads, I think the 
> problem would be solved if it was with the mouse. So I am guessing the IBM 
> defaults to just repeating standard ps/2 protocol, and you have to first 
> trick that before you trick the mouse. Since it works in windows there IS a 
> way...
> 
> Where do I find the public available protocols, and the secrets? :)
> 
> And for the list, who should I notify that I am working on autodetecting IBM 
> thinkpad  ps/2 repeaters in mouse driver?

Actually I'm interested in this work. We have input api drivers for PS/2
devices so it would be easy to add support. Any info would be helpfu to
expand the devices we support.

tsdev mixer?

[Charles D. <cd...@mv...>]

Would anyone object if tsdev gained a mixer device? (I ask because
these have been a bit controversial elsewhere).

I propose this primarily because it would be very useful to me: If I
have a target with both a touchpanel and a mouse, 'twould be great to
be able to use either without having to change /dev/ts to point to the
appropriate device and restart (QtE|microwindows|X|whatever) each
time. Particularly with apps that need to be recompiled to switch
between a mouse and touchscreen interface (QtE), this would be of
great benefit.

I'll probably write the thing tomorrow if I hear no complaints.

Re: mousedev patch

[Charles D. <cd...@mv...>]

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

Re: mousedev patch

[James S. <jsi...@tr...>]

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.

Re: input.h keycode request

[James S. <jsi...@tr...>]

> Greetings.
> 
> Would it be possible to add the following keycodes to input.h?  They would 
> be most useful in reduction of inter-linking low-level keyboard handling
> with other kernel drivers.
> 
> KEY_BRIGHTNESSUP
> KEY_BRIGHTNESSDOWN
> KEY_CONTRASTUP
> KEY_CONTRASTDOWN
> KEY_PCMCIAEJECT1
> KEY_PCMCIAEJECT2

Actually I have worked on some stuff dealing with this. Usually you are
dealing with touchscreens with backlights. I made a special handler for
this (power.c). It needs more work. basically it use KEY_POWER and
KEY_SUSPEND. We sort of have a EJECT key (KEY_EJECTCD). It would be nice
if that was named to KEY_EJECT to be more generic.

> Attached is the segment from a set of patches which implement some of these,
> available in full at http://www.execpc.com/~jpgarcia/dev/jpgpatches.tar.gz

Will take a look. 

Re: mousedev patch

[Charles D. <cd...@mv...>]

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).

Re: mousedev patch

[James S. <jsi...@tr...>]

> 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;
> 
> 

[PATCH] gamecon.c change for SNES controller (fwd)

[James S. <jsi...@tr...>]

Patch for the SNES controller attached to a parallel port. I don't have
this hardware so please test it.

>The old code was giving the same values when you pressed right or left or
>when  you pressed up or down. The new code have been done to not use
>expensive codification (i.e. multiplication).

--- drivers/char/joystick/gamecon.c.orig Sat Jul 14 19:03:12 2001
+++ drivers/char/joystick/gamecon.c     Wed Jul 18 16:00:50 2001
@@ -345,8 +345,8 @@
                        s = gc_status_bit[i];
 
                        if (s & (gc->pads[GC_NES] | gc->pads[GC_SNES])) {
-                               input_report_abs(dev + i, ABS_X, ! - !(s 
& data[6]) - !(s & data[7]));
-                               input_report_abs(dev + i, ABS_Y, ! - !(s 
& data[4]) - !(s & data[5]));
+                               input_report_abs(dev + i, ABS_X, - !!(s 
& data[6]) + !!(s & data[7]));
+                               input_report_abs(dev + i, ABS_Y, - !!(s 
& data[4]) + !!(s & data[5]));
                        }
 
                        if (s & gc->pads[GC_NES])

--- end of patch ---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

input.h keycode request

[Joseph P. G. <jpg...@ex...>]

Greetings.

Would it be possible to add the following keycodes to input.h?  They would be most useful in reduction of inter-linking low-level keyboard handling with other kernel drivers.

KEY_BRIGHTNESSUP
KEY_BRIGHTNESSDOWN
KEY_CONTRASTUP
KEY_CONTRASTDOWN
KEY_PCMCIAEJECT1
KEY_PCMCIAEJECT2

Attached is the segment from a set of patches which implement some of these, available in full at http://www.execpc.com/~jpgarcia/dev/jpgpatches.tar.gz

Thank you for your time and consideration.

-- 
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

mousedev patch

[Charles D. <cd...@mv...>]

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;

Re: New input driver: Handykey's Twiddler as a joystick

[James S. <jsi...@tr...>]

Fixed.

> Please tell me if you think that I should apply for CVS access and do
> these kind of things myself...

If you continue work on it sure. Just make sure you don't break things :-)

> > It would be nice. Vojtech is in charge of the input stuff so he can pass
> > to Alan. Alan is more open to patches where Linus is not. Then it would be
> > in the ac tree until Linus would finally incorporate it.
> 
> Yeah, that would be fine!

Re: New input driver: Handykey's Twiddler as a joystick

[Arndt S. <ab...@sr...>]

On Thu, Jul 19, 2001 at 11:31:10AM -0700, James Simmons wrote:
> 
> >     #ifndef SERIO_TWIDKBD
> >     #define SERIO_TWIDKBD 4710
> >     #endif
> 
> Added. It is number 0x23.

Great! But you need to add SERIO_TWIDJOY, too (perhaps as 0x24?). And
then you can remove the "#ifndef"s from inputattach.c and twidjoy.c.

Please tell me if you think that I should apply for CVS access and do
these kind of things myself...

> > And another question: Will the new driver be included into the next
> > Linux 2.4.x kernel version?
> 
> It would be nice. Vojtech is in charge of the input stuff so he can pass
> to Alan. Alan is more open to patches where Linus is not. Then it would be
> in the ac tree until Linus would finally incorporate it.

Yeah, that would be fine!

Arndt

-- 
Arndt Schönewald <ab...@sr...>, Software Developer

Re: New input driver: Handykey's Twiddler as a joystick

[James S. <jsi...@tr...>]

>     #ifndef SERIO_TWIDKBD
>     #define SERIO_TWIDKBD 4710
>     #endif

Added. It is number 0x23.

> And another question: Will the new driver be included into the next
> Linux 2.4.x kernel version?

It would be nice. Vojtech is in charge of the input stuff so he can pass
to Alan. Alan is more open to patches where Linus is not. Then it would be
in the ac tree until Linus would finally incorporate it.