neil@celia.UUCP (Neil Richmond) (06/06/91)
I wrote a tablet driver program for my Kurta tablet to run on my A2000 under
1.3. The problem is that when I got my A3000 with 2.0, my program broke. I
have checked all phases of my program and the problem seems to occur when I
access the input.device. A couple of notes, I use IECLASS_POINTERPOS instead
of RAWMOUSE. I do this because I get absolute coordinates from the tablet. I
then transform the coodinates of the tablet to 600X400 space. I handle the
buttons in a separate input to input.device. Of course, the coordinates are
passed at that time and they are passed if no button is activated. The problem
is the mousepointer moves, even if the pen is not moving. Eventually, it moves
to the lower right corner of the screen, as if the values it is getting is a
deltax and deltay, not absolute screen coordinates, until it reaches the
maximum values. This program use to and still does work under 1.3. I need help.
Is this enough info, or should I post the program. I haven't because I don't
want to waste net resources. My references have been RKM 1.3 and Ed Hanway's
OptMouse Program that was on Fred Fish Disk #445.
neil
--
Only 3132 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!neil@usc.edu
Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)valentin@public.BTR.COM (Valentin Pepelea) (06/07/91)
In article <1043@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: > >A couple of notes, I use IECLASS_POINTERPOS instead >of RAWMOUSE. > >The problem is the mousepointer moves, even if the pen is not moving. >Eventually, it moves to the lower right corner of the screen, as if the >values it is getting is a deltax and deltay, not absolute screen coordinates, >until it reaches the maximum values. Every time, before you send the input device a fake input event, you are supposed to re-initialize all fields of the InputEvent structure. Under 1.3 you could get away without doing this. Under 2.0, the ie_Class field gets trashed. This has been fixed under more recent releases of 2.0. Consider yourself lucky this shmuk ran into the problem first. :-) :-( Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
peter@cbmvax.commodore.com (Peter Cherna) (06/08/91)
In article <1043@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >I wrote a tablet driver program for my Kurta tablet to run on my A2000 under >1.3. The problem is that when I got my A3000 with 2.0, my program broke. I >have checked all phases of my program and the problem seems to occur when I >access the input.device. A couple of notes, I use IECLASS_POINTERPOS instead >of RAWMOUSE. The 1.3 RKM manual states explicitly that you must not rely on data you place in an InputEvent remaining unmodified for your later use (see p. 698). It turned out that under 1.3, the contents of IECLASS_POINTERPOS happened to be preserved. For compatibility, recent versions of 2.0 now preserve those fields as well. A second issue is that the include files have defined the mouse-button codes (IECODE_LBUTTON, etc.) as being for the IECLASS_RAWMOUSE event, but many people sent them (incorrectly) for IECLASS_POINTERPOS. Under 1.3, that happened to work (because IECLASS_POINTERPOS was coverted very simply into IECLASS_RAWMOUSE). Under 2.0, the handling of input events is more sophisticated, and this side-effect was lost. Again, because of the number of people who depended on this and the fact that the side-effect could be easily re-created without much burden to Intuition, a change was made so things work like they did in 1.3. In any case, the last public release of 2.0 (2.03) still has this problem. You'll have to wait (not long, hopefully) for 2.04 to cure this problem. Alternately, since you wrote the driver, you could fix it to tide you over in the meantime. >neil Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
neil@celia.UUCP (Neil Richmond) (06/11/91)
In article <2980@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >this shmuk ran into the problem first. :-) :-( ^^^^^ > >Valentin >-- I resent this remark. neil -- Only 3127 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
neil@celia.UUCP (Neil Richmond) (06/11/91)
In article <22252@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >A second issue is that the include files have defined the mouse-button >codes (IECODE_LBUTTON, etc.) as being for the IECLASS_RAWMOUSE event, >but many people sent them (incorrectly) for IECLASS_POINTERPOS. Under >1.3, that happened to work (because IECLASS_POINTERPOS was coverted >very simply into IECLASS_RAWMOUSE). Under 2.0, the handling of input If this was incorrect, what is correct? To use IECLASS_RAWMOUSE whenever I am sending mouse key events and IECLASS_POINTERPOS whenever I send x and y coordinates to the mousepointer? There is VERY LITTLE reference to IECLASS_POINTERPOS in the RKM1.3 Manuals. I read that IECLASS_POINTERPOS was converted anyway in RAWMOUSE with the correct relative values. What happens in 2.0? >events is more sophisticated, and this side-effect was lost. Again, >because of the number of people who depended on this and the fact >that the side-effect could be easily re-created without much burden >to Intuition, a change was made so things work like they did in 1.3. Is it a good thing that side effect was lost? My own feeling is that I would rather do things correctly, than have some kind of repair made so what I did wrong, in the first place, will still work. Obviously, I am not the only one who made this mistake, although I might have been the only one who made it out of ignorance. Where can I find more information about this? >Alternately, since you wrote the driver, you could fix it to >tide you over in the meantime. I am trying to make this fix. This does help a lot. Thanks. neil -- Only 3127 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
peter@cbmvax.commodore.com (Peter Cherna) (06/11/91)
In article <1051@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >In article <2980@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >>this shmuk ran into the problem first. :-) :-( > ^^^^^ >> >>Valentin >>-- > >I resent this remark. You don't need to resent it. He was talking about himself. (He reported the change in behavior to us, and we fixed it so it works like it used to). >Neil F. Richmond INTERNET: celia!neil@usc.edu Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
valentin@public.BTR.COM (Valentin Pepelea) (06/11/91)
In article <1051@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >In article <2980@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) >writes: >> >>this shmuk ran into the problem first. :-) :-( > ^^^^^ >I resent this remark. > >neil I was referring to myself. Double-check the context of that statement. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
baxter_a@wehi.dn.mu.oz (06/11/91)
In article <1051@celia.UUCP>, neil@celia.UUCP (Neil Richmond) writes: > In article <2980@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >>this shmuk ran into the problem first. :-) :-( > ^^^^^ >> >>Valentin >>-- > > I resent this remark. > > neil Why? It seems to me that V was calling himself a shmuk (whatever that is), so I'm sure he didn't mean any harm by it. Regards Alan
neil@celia.UUCP (Neil Richmond) (06/11/91)
Peter,
I just wanted to say thanks. With your info, I got my tablet up and running
again under 2.0. I still would like more information on IECODE_LBUTTON, etc
and their relation to IECLASS_POINTERPOS. If you could point out some
references in this area, I would appreciate it very much. Thanks.
neil
--
Only 3126 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!neil@usc.edu
Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)peter@cbmvax.commodore.com (Peter Cherna) (06/12/91)
In article <1052@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >In article <22252@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >If this was incorrect, what is correct? To use IECLASS_RAWMOUSE whenever >I am sending mouse key events and IECLASS_POINTERPOS whenever I send x >and y coordinates to the mousepointer? There is VERY LITTLE reference to >IECLASS_POINTERPOS in the RKM1.3 Manuals. I read that IECLASS_POINTERPOS >was converted anyway in RAWMOUSE with the correct relative values. What >happens in 2.0? IECLASS_POINTERPOS now officially supports IECODE_xBUTTON stuff. It did in 1.3, lost it in early 2.0 (it fell out because it wasn't defined to work), and now once again does. It will continue to do so. >Is it a good thing that side effect was lost? The side-effect is back, and it does no harm to the system to leave it that way. You may continue to use IECLASS_POINTERPOS with IECODE_xBUTTON, since most everyone that has 2.0 will end up with 2.04 soon. >Neil F. Richmond INTERNET: celia!neil@usc.edu Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
peter@cbmvax.commodore.com (Peter Cherna) (06/12/91)
In article <1055@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >Peter, > >I just wanted to say thanks. With your info, I got my tablet up and running >again under 2.0. I still would like more information on IECODE_LBUTTON, etc >and their relation to IECLASS_POINTERPOS. If you could point out some >references in this area, I would appreciate it very much. Thanks. The RKM doesn't have anything direct to say about IECODE_LBUTTON and friends. The entire reference seems to be <devices/inputevent.h>: /* IECLASS_RAWMOUSE */ #define IECODE_LBUTTON 0x68 /* also uses IECODE_UP_PREFIX */ #define IECODE_RBUTTON 0x69 #define IECODE_MBUTTON 0x6A #define IECODE_NOBUTTON 0xFF The comment will get changed to: /* IECLASS_RAWMOUSE and IECLASS_POINTERPOS */ >Neil F. Richmond INTERNET: celia!neil@usc.edu Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
neil@celia.UUCP (Neil Richmond) (06/13/91)
In article <22316@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >You don't need to resent it. He was talking about himself. (He reported >the change in behavior to us, and we fixed it so it works like it >used to). Apologies to Valentin and everyone else in the net. That was not clear to me. neil -- Only 3125 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)