Hi Vojtech,
I'm running 2.5.26 with an ordinary PS/2 keyboard and a 5 button PS/2 mouse.
When using the old psaux driver the mouse works fine.
With input core support, however, the scroll wheel doesn't work properly.
In my XF86Config I'm using IMPS/2 protocol and ZAxisMapping 4 5.
Scrolling up causes the window to scroll down. Scrolling down doesn't do
anything. When changing the protocol to ExplorerPS2 things are not much
better. You can't drag windows over the screen.
The following is the relevant kernel information.
Do you have any tips?
mice: PS/2 mouse device common for all mice
input.c: calling /sbin/hotplug input [HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUC
input.c: hotplug returned -2
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
input.c: calling /sbin/hotplug input [HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUC
input.c: hotplug returned -2
input: ImExPS/2 Microsoft IntelliMouse Explorer on isa0060/serio1
Regards,
Udo.
On Wed, Jul 17, 2002 at 12:13:51PM +0200, Udo A. Steinberg wrote:
>
> Hi Vojtech,
>
> I'm running 2.5.26 with an ordinary PS/2 keyboard and a 5 button PS/2 mouse.
> When using the old psaux driver the mouse works fine.
> With input core support, however, the scroll wheel doesn't work properly.
> In my XF86Config I'm using IMPS/2 protocol and ZAxisMapping 4 5.
> Scrolling up causes the window to scroll down. Scrolling down doesn't do
> anything. When changing the protocol to ExplorerPS2 things are not much
> better. You can't drag windows over the screen.
>
> The following is the relevant kernel information.
> Do you have any tips?
It's a bug. This patch should fix it:
diff -Nru a/drivers/input/mouse/psmouse.c b/drivers/input/mouse/psmouse.c
--- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
+++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
@@ -142,7 +142,7 @@
*/
if (psmouse->type == PSMOUSE_IMEX) {
- input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 7) - (int) (packet[2] & 8));
+ input_report_rel(dev, REL_WHEEL, (int) (packet[2] & 8) - (int) (packet[3] & 7));
input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
}
> mice: PS/2 mouse device common for all mice
> input.c: calling /sbin/hotplug input [HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUC
> input.c: hotplug returned -2
> input: AT Set 2 keyboard on isa0060/serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> input.c: calling /sbin/hotplug input [HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUC
> input.c: hotplug returned -2
> input: ImExPS/2 Microsoft IntelliMouse Explorer on isa0060/serio1
>
> Regards,
> Udo.
--
Vojtech Pavlik
SuSE Labs
On Wed, Jul 17, 2002 at 12:13:51PM +0200, Udo A. Steinberg wrote:
> I'm running 2.5.26 with an ordinary PS/2 keyboard and a 5 button PS/2 mouse.
> When using the old psaux driver the mouse works fine.
> With input core support, however, the scroll wheel doesn't work properly.
> In my XF86Config I'm using IMPS/2 protocol and ZAxisMapping 4 5.
> Scrolling up causes the window to scroll down. Scrolling down doesn't do
> anything. When changing the protocol to ExplorerPS2 things are not much
> better. You can't drag windows over the screen.
I think this is no kernel problem. You have 7 buttons (5 + 2 wheel).
Try this: http://www.deadman.org/X/xbuttons.html or google for
intellimouse and linux.
Regards,
Oliver.
Vojtech Pavlik wrote:
>
> It's a bug. This patch should fix it:
Hello,
With this patch I can now properly scroll down. But scrolling the
mouse wheel up doesn't do any scrolling up in X.
-Udo.
On Wed, Jul 17, 2002 at 01:47:12PM +0200, Udo A. Steinberg wrote:
> Vojtech Pavlik wrote:
> >
> > It's a bug. This patch should fix it:
>
> Hello,
>
> With this patch I can now properly scroll down. But scrolling the
> mouse wheel up doesn't do any scrolling up in X.
This is interesting. Can you try the attached test utility? You need to
enable CONFIG_INPUT_EVDEV, as well, and use it on /dev/input/evdev0 or
1, depening what's your mouse.
I'm wondering whether the scroll events show up or not.
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
>
> This is interesting. Can you try the attached test utility? You need to
> enable CONFIG_INPUT_EVDEV, as well, and use it on /dev/input/evdev0 or
> 1, depening what's your mouse.
>
> I'm wondering whether the scroll events show up or not.
Hello,
They show up in the output. First 4 events are scroll-down, last
4 events are scroll-up.
Regards,
-Udo.
./evtest /dev/input/event2
Input driver version is 1.0.0
Input device ID: bus 0x11 vendor 0x6 product 0x2 version 0x100
Input device name: "ImExPS/2 Microsoft IntelliMouse Explorer"
Supported events:
Event type 1 (Key)
Event code 272 (LeftBtn)
Event code 273 (RightBtn)
Event code 274 (MiddleBtn)
Event code 275 (SideBtn)
Event code 276 (ExtraBtn)
Event type 2 (Relative)
Event code 0 (X)
Event code 1 (Y)
Event code 8 (Wheel)
Testing ... (interrupt to exit)
Event: time 1026908021.053509, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1026908021.607555, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1026908022.017017, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1026908022.412833, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1026908023.241679, type 2 (Relative), code 8 (Wheel), value -7
Event: time 1026908023.711842, type 2 (Relative), code 8 (Wheel), value -7
Event: time 1026908024.149266, type 2 (Relative), code 8 (Wheel), value -7
Event: time 1026908024.529600, type 2 (Relative), code 8 (Wheel), value -7
On Wed, Jul 17, 2002 at 02:15:12PM +0200, Udo A. Steinberg wrote:
> Vojtech Pavlik wrote:
> >
> > This is interesting. Can you try the attached test utility? You need to
> > enable CONFIG_INPUT_EVDEV, as well, and use it on /dev/input/evdev0 or
> > 1, depening what's your mouse.
> >
> > I'm wondering whether the scroll events show up or not.
>
> Hello,
>
> They show up in the output. First 4 events are scroll-down, last
> 4 events are scroll-up.
Ok, another patch. :)
diff -Nru a/drivers/input/mouse/psmouse.c b/drivers/input/mouse/psmouse.c
--- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
+++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
@@ -142,7 +142,7 @@
*/
if (psmouse->type == PSMOUSE_IMEX) {
- input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
+ input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 7) - (int) (packet[3] & 8));
input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
}
>
> Regards,
> -Udo.
>
> ./evtest /dev/input/event2
> Input driver version is 1.0.0
> Input device ID: bus 0x11 vendor 0x6 product 0x2 version 0x100
> Input device name: "ImExPS/2 Microsoft IntelliMouse Explorer"
> Supported events:
> Event type 1 (Key)
> Event code 272 (LeftBtn)
> Event code 273 (RightBtn)
> Event code 274 (MiddleBtn)
> Event code 275 (SideBtn)
> Event code 276 (ExtraBtn)
> Event type 2 (Relative)
> Event code 0 (X)
> Event code 1 (Y)
> Event code 8 (Wheel)
> Testing ... (interrupt to exit)
> Event: time 1026908021.053509, type 2 (Relative), code 8 (Wheel), value -1
> Event: time 1026908021.607555, type 2 (Relative), code 8 (Wheel), value -1
> Event: time 1026908022.017017, type 2 (Relative), code 8 (Wheel), value -1
> Event: time 1026908022.412833, type 2 (Relative), code 8 (Wheel), value -1
> Event: time 1026908023.241679, type 2 (Relative), code 8 (Wheel), value -7
> Event: time 1026908023.711842, type 2 (Relative), code 8 (Wheel), value -7
> Event: time 1026908024.149266, type 2 (Relative), code 8 (Wheel), value -7
> Event: time 1026908024.529600, type 2 (Relative), code 8 (Wheel), value -7
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
>
> Ok, another patch. :)
Very close :)
Directions of scrolling are reversed. The following works ok:
diff -Nru a/drivers/input/mouse/psmouse.c b/drivers/input/mouse/psmouse.c
--- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
+++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
@@ -142,7 +142,7 @@
*/
if (psmouse->type == PSMOUSE_IMEX) {
- input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
+ input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
}
Regards,
-Udo.
On Wed, Jul 17, 2002 at 02:41:45PM +0200, Udo A. Steinberg wrote:
> Vojtech Pavlik wrote:
> >
> > Ok, another patch. :)
>
> Very close :)
> Directions of scrolling are reversed. The following works ok:
>
> diff -Nru a/drivers/input/mouse/psmouse.c b/drivers/input/mouse/psmouse.c
> --- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> +++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> @@ -142,7 +142,7 @@
> */
>
> if (psmouse->type == PSMOUSE_IMEX) {
> - input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
> + input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
> input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
> input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
> }
Can you check with evtest again? Up should be showing as -1, down as 1.
If it doesn't, then there is another direction bug elsewhere.
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
>
> Can you check with evtest again? Up should be showing as -1, down as 1.
With my patch up is 1 and down is -1 and things scroll the right way.
> If it doesn't, then there is another direction bug elsewhere.
Possibly.
-Udo.
On 17 Jul 02 at 14:44, Vojtech Pavlik wrote:
> > --- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > +++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > @@ -142,7 +142,7 @@
> > */
> >
> > if (psmouse->type == PSMOUSE_IMEX) {
> > - input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
> > + input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
> > input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
> > input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
> > }
Hi,
any plans to support A4Tech mouse? It uses IMEX protocol, but
switch(packet[3] & 0x0F) {
case 0: /* nothing */
case 1: vertical_wheel--; break;
case 2: horizontal_wheel++; break;
case 0xE: horizontal_wheel--; break;
case 0xF: vertical_wheel++; break;
}
and obviously it never reports wheel move > 1 in one sample.
Thanks,
Petr Vandrovec
[email protected]
On Wed, Jul 17, 2002 at 02:54:25PM +0200, Udo A. Steinberg wrote:
> Vojtech Pavlik wrote:
> >
> > Can you check with evtest again? Up should be showing as -1, down as 1.
>
> With my patch up is 1 and down is -1 and things scroll the right way.
What protocol are you using in X?
Does this happen with both ExplorerPS/2 and ImPS/2?
> > If it doesn't, then there is another direction bug elsewhere.
>
> Possibly.
mousedev.c
--
Vojtech Pavlik
SuSE Labs
On Wed, Jul 17, 2002 at 02:55:21PM +0200, Petr Vandrovec wrote:
> On 17 Jul 02 at 14:44, Vojtech Pavlik wrote:
>
> > > --- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > +++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > @@ -142,7 +142,7 @@
> > > */
> > >
> > > if (psmouse->type == PSMOUSE_IMEX) {
> > > - input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
> > > + input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
> > > input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
> > > input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
> > > }
>
> Hi,
> any plans to support A4Tech mouse? It uses IMEX protocol, but
>
> switch(packet[3] & 0x0F) {
> case 0: /* nothing */
> case 1: vertical_wheel--; break;
> case 2: horizontal_wheel++; break;
> case 0xE: horizontal_wheel--; break;
> case 0xF: vertical_wheel++; break;
> }
>
> and obviously it never reports wheel move > 1 in one sample.
Is there a way to detect whether it's an ImEx or A4? Or will we need a
command line parameter ... ?
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> What protocol are you using in X?
ImPS/2
> Does this happen with both ExplorerPS/2 and ImPS/2?
Both ImPS/2 and ExplorerPS/2 behave the same way when configured with
5 buttons and ZAxisMapping 4 5.
When using ExplorerPS/2 with 7 buttons and ZAxisMapping 6 7, then
scrolling doesn't work at all, however evtest displays all button
and scroll events correctly (with scroll directions reversed).
-Udo.
On 17 Jul 02 at 15:01, Vojtech Pavlik wrote:
> On Wed, Jul 17, 2002 at 02:55:21PM +0200, Petr Vandrovec wrote:
> > On 17 Jul 02 at 14:44, Vojtech Pavlik wrote:
> >
> > > > --- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > > +++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > > @@ -142,7 +142,7 @@
> > > > */
> > > >
> > > > if (psmouse->type == PSMOUSE_IMEX) {
> > > > - input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
> > > > + input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
> > > > input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
> > > > input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
> > > > }
> >
> > Hi,
> > any plans to support A4Tech mouse? It uses IMEX protocol, but
> >
> > switch(packet[3] & 0x0F) {
> > case 0: /* nothing */
> > case 1: vertical_wheel--; break;
> > case 2: horizontal_wheel++; break;
> > case 0xE: horizontal_wheel--; break;
> > case 0xF: vertical_wheel++; break;
> > }
> >
> > and obviously it never reports wheel move > 1 in one sample.
>
> Is there a way to detect whether it's an ImEx or A4? Or will we need a
> command line parameter ... ?
I'm not aware of any way. It behaves like proper ExPS/2 mouse: after reset
it returns id0, after ImPS/2 sequence 3, and after ExPS/2 sequence 4.
In both ImPS/2 and ExPS/2 modes it uses 2/0xE(0xFE) in fourth byte of
packet for horizontal wheel.
Windows .INF talks about "A4M0004", but it looks to me like an internal
.INF identifier and not as an identification string obtainable from mouse.
I'll try to write email to them, maybe they'll answer.
Thanks,
Petr Vandrovec
[email protected]
On Wed, Jul 17, 2002 at 03:58:21PM +0200, Gunther Mayer wrote:
> > > Hi,
> > > any plans to support A4Tech mouse? It uses IMEX protocol, but
> > >
> > > switch(packet[3] & 0x0F) {
> > > case 0: /* nothing */
> > > case 1: vertical_wheel--; break;
> > > case 2: horizontal_wheel++; break;
> > > case 0xE: horizontal_wheel--; break;
> > > case 0xF: vertical_wheel++; break;
> > > }
> > >
> > > and obviously it never reports wheel move > 1 in one sample.
> >
> > Is there a way to detect whether it's an ImEx or A4? Or will we need a
> > command line parameter ... ?
>
> from http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c :
>
> char a4tech_id[]={ 0xf3,200, 0xf3,100, 0xf3,80, 0xf3,60, 0xf3,40, 0xf3,20};
>
> if(a4tech) {
> sendbuf(fd,f,a4tech_id,12);
> buf[0]=0xf2;
> write(fd,&buf,1);
> b=consumefa(f);
> printf("a4tech ID(f2) is %x\n",b);
>
> if(b==6 || b==8) printf("AUTODETECT: a4tech\n");
> // b=6: spiffy gyro-mouse "8D Profi-Mouse Point Stick"
> // b=8: boeder Smartmouse Pro (4Button, 2Scrollwheel, 520dpi) PSM_4DPLUS_ID MOUSE_MODEL_4DPLUS
> }
Cool! Anyone send me a patch? ;)
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Wed, Jul 17, 2002 at 02:55:21PM +0200, Petr Vandrovec wrote:
> > On 17 Jul 02 at 14:44, Vojtech Pavlik wrote:
> >
> > > > --- a/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > > +++ b/drivers/input/mouse/psmouse.c Wed Jul 17 12:19:13 2002
> > > > @@ -142,7 +142,7 @@
> > > > */
> > > >
> > > > if (psmouse->type == PSMOUSE_IMEX) {
> > > > - input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[2] & 7));
> > > > + input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
> > > > input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
> > > > input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
> > > > }
> >
> > Hi,
> > any plans to support A4Tech mouse? It uses IMEX protocol, but
> >
> > switch(packet[3] & 0x0F) {
> > case 0: /* nothing */
> > case 1: vertical_wheel--; break;
> > case 2: horizontal_wheel++; break;
> > case 0xE: horizontal_wheel--; break;
> > case 0xF: vertical_wheel++; break;
> > }
> >
> > and obviously it never reports wheel move > 1 in one sample.
>
> Is there a way to detect whether it's an ImEx or A4? Or will we need a
> command line parameter ... ?
from http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c :
char a4tech_id[]={ 0xf3,200, 0xf3,100, 0xf3,80, 0xf3,60, 0xf3,40, 0xf3,20};
if(a4tech) {
sendbuf(fd,f,a4tech_id,12);
buf[0]=0xf2;
write(fd,&buf,1);
b=consumefa(f);
printf("a4tech ID(f2) is %x\n",b);
if(b==6 || b==8) printf("AUTODETECT: a4tech\n");
// b=6: spiffy gyro-mouse "8D Profi-Mouse Point Stick"
// b=8: boeder Smartmouse Pro (4Button, 2Scrollwheel, 520dpi) PSM_4DPLUS_ID MOUSE_MODEL_4DPLUS
}
On 17 Jul 02 at 16:01, Vojtech Pavlik wrote:
> On Wed, Jul 17, 2002 at 03:58:21PM +0200, Gunther Mayer wrote:
>
> > > > Hi,
> > > > any plans to support A4Tech mouse? It uses IMEX protocol, but
> > > >
> > > > switch(packet[3] & 0x0F) {
> > > > case 0: /* nothing */
> > > > case 1: vertical_wheel--; break;
> > > > case 2: horizontal_wheel++; break;
> > > > case 0xE: horizontal_wheel--; break;
> > > > case 0xF: vertical_wheel++; break;
> > > > }
> > > >
> > > > and obviously it never reports wheel move > 1 in one sample.
> > >
> > > Is there a way to detect whether it's an ImEx or A4? Or will we need a
> > > command line parameter ... ?
> >
> > from http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c :
> >
> > char a4tech_id[]={ 0xf3,200, 0xf3,100, 0xf3,80, 0xf3,60, 0xf3,40, 0xf3,20};
> >
> > if(a4tech) {
> > sendbuf(fd,f,a4tech_id,12);
> > buf[0]=0xf2;
> > write(fd,&buf,1);
> > b=consumefa(f);
> > printf("a4tech ID(f2) is %x\n",b);
> >
> > if(b==6 || b==8) printf("AUTODETECT: a4tech\n");
> > // b=6: spiffy gyro-mouse "8D Profi-Mouse Point Stick"
> > // b=8: boeder Smartmouse Pro (4Button, 2Scrollwheel, 520dpi) PSM_4DPLUS_ID MOUSE_MODEL_4DPLUS
> > }
>
> Cool! Anyone send me a patch? ;)
Been there, done that... and unfortunately, my WOP35 insist on
taking first 6 bytes as PS/2->ImPS/2 sequence, and rest as normal
DPI settings. I tried it in reverse order, and couple of permutations,
but it still returns ExPS/2 id. I tried also other sequences from
gm_psauxprint-0.01, but I found nothing interesting, except that
mouse definitely does not support MS PNP id.
Answer from A4Tech support was that mouse is not supported under Linux,
and that I should use Windows and verify that mouse is properly connected.
So I'm on the best way to the command line switch, I think. Google
find couple of problem reporters, but nobody found detection method :-(
Petr Vandrovec
[email protected]
On Thu, Jul 18, 2002 at 12:17:51PM +0200, Petr Vandrovec wrote:
> > Cool! Anyone send me a patch? ;)
>
> Been there, done that... and unfortunately, my WOP35 insist on
> taking first 6 bytes as PS/2->ImPS/2 sequence, and rest as normal
> DPI settings. I tried it in reverse order, and couple of permutations,
> but it still returns ExPS/2 id. I tried also other sequences from
> gm_psauxprint-0.01, but I found nothing interesting, except that
> mouse definitely does not support MS PNP id.
>
> Answer from A4Tech support was that mouse is not supported under Linux,
> and that I should use Windows and verify that mouse is properly connected.
> So I'm on the best way to the command line switch, I think. Google
> find couple of problem reporters, but nobody found detection method :-(
Well, it should be possible to snoop the mouse data off the wire using
a slightly modified parkbd.c module on a different machine and a split
PS/2 mouse cable ...
--
Vojtech Pavlik
SuSE Labs
On 18 Jul 02 at 14:58, Vojtech Pavlik wrote:
> On Thu, Jul 18, 2002 at 12:17:51PM +0200, Petr Vandrovec wrote:
>
> > > Cool! Anyone send me a patch? ;)
> >
> > Been there, done that... and unfortunately, my WOP35 insist on
> > taking first 6 bytes as PS/2->ImPS/2 sequence, and rest as normal
> > DPI settings. I tried it in reverse order, and couple of permutations,
> > but it still returns ExPS/2 id. I tried also other sequences from
> > gm_psauxprint-0.01, but I found nothing interesting, except that
> > mouse definitely does not support MS PNP id.
> >
> > Answer from A4Tech support was that mouse is not supported under Linux,
> > and that I should use Windows and verify that mouse is properly connected.
> > So I'm on the best way to the command line switch, I think. Google
> > find couple of problem reporters, but nobody found detection method :-(
>
> Well, it should be possible to snoop the mouse data off the wire using
> a slightly modified parkbd.c module on a different machine and a split
> PS/2 mouse cable ...
Problem is that A4Tech driver does not care. It just interprets incoming
data in the way I described: +-1 is vertical move, +-2 is horizontal,
0 is no move, and everything else is ignored... This is A4Tech's
interpretation of ImPS/2 and ExPS/2 protocols.
So we can either assume (like GPM does) that wheel movement can be
only +-1, and so we can safely assume that +-2 is horizontal move,
and then everything is fine, or we need some option which will affect
mouse driver behavior.
All my (A4Tech...) PS/2 wheel mouse report wheel movement only +-1 even
with 10Hz sample rate, but I do not think that my mouses are representative
sample of available ExPS/2 implementations.
Petr Vandrovec
On Thu, Jul 18, 2002 at 03:36:59PM +0200, Petr Vandrovec wrote:
> On 18 Jul 02 at 14:58, Vojtech Pavlik wrote:
> > On Thu, Jul 18, 2002 at 12:17:51PM +0200, Petr Vandrovec wrote:
> >
> > > > Cool! Anyone send me a patch? ;)
> > >
> > > Been there, done that... and unfortunately, my WOP35 insist on
> > > taking first 6 bytes as PS/2->ImPS/2 sequence, and rest as normal
> > > DPI settings. I tried it in reverse order, and couple of permutations,
> > > but it still returns ExPS/2 id. I tried also other sequences from
> > > gm_psauxprint-0.01, but I found nothing interesting, except that
> > > mouse definitely does not support MS PNP id.
> > >
> > > Answer from A4Tech support was that mouse is not supported under Linux,
> > > and that I should use Windows and verify that mouse is properly connected.
> > > So I'm on the best way to the command line switch, I think. Google
> > > find couple of problem reporters, but nobody found detection method :-(
> >
> > Well, it should be possible to snoop the mouse data off the wire using
> > a slightly modified parkbd.c module on a different machine and a split
> > PS/2 mouse cable ...
>
> Problem is that A4Tech driver does not care. It just interprets incoming
> data in the way I described: +-1 is vertical move, +-2 is horizontal,
> 0 is no move, and everything else is ignored... This is A4Tech's
> interpretation of ImPS/2 and ExPS/2 protocols.
>
> So we can either assume (like GPM does) that wheel movement can be
> only +-1, and so we can safely assume that +-2 is horizontal move,
> and then everything is fine, or we need some option which will affect
> mouse driver behavior.
>
> All my (A4Tech...) PS/2 wheel mouse report wheel movement only +-1 even
> with 10Hz sample rate, but I do not think that my mouses are representative
> sample of available ExPS/2 implementations.
No, normal ImPS/2 and ExPS/2 mice indeed can report values greater than 1
for wheel movement.
We can either make some heuristic (ever saw movement of 3? If yes, then
it's not an A4Tech mouse ...), or go for the command line parameter.
I guess I'll pull out some of my A4Tech mice and torture them a bit to
see if they'd react to some sequence ...
Another thing is then USB A4Tech mice, which use a button to
differentiate between the wheels, while the USB spec has provisions for
two wheels on a mouse :(. But those are at least possible to detect.
--
Vojtech Pavlik
SuSE Labs