Re: [DNG] mouse driver question

2022-05-11 Thread Fred

Hi Karl,

On 5/11/22 08:23, k...@aspodata.se wrote:

Fred:

On 5/11/22 05:02, k...@aspodata.se wrote:



You should be able to do lsinput from input-utils package to see which
/dev/input/inputX file your mouse's byte stream transformed as events
would appear. And then run input-events X to see the events. E.g.:

# lsinput | tail
open /dev/input/event11: No such device or address

/dev/input/event10
 bustype : BUS_I8042
 vendor  : 0x2
 product : 0xa
 version : 0
 name: "TPPS/2 IBM TrackPoint"
 phys: "isa0060/serio1/input0"
 bits ev : (null) (null) (null)

Why did you pick event10?


Because that where the mouse is as shown by the lsinput output.


I have event0 to 21 also mice and mouse0 in that directory.
The reason I asked is that when I ran your command line I got one 
paragraph with the name"ALSA".  My mouse is tied to event0 whether pc 
mouse or Sun.



Run lsinput and choose.

Here ia another example:

# modprobe  sermouse
# ./inputattach --daemon --mouseman /dev/ttyS0
# tail -2 /var/log/all
May 11 15:01:30 zoisit user.info kernel: [15477.331554] input: Logitech M+ 
Mouse as /devices/pnp0/00:01/tty/ttyS0/serio3/input/input19
May 11 15:01:30 zoisit user.info kernel: [15477.332229] serio: Serial port ttyS0
# lsinput | tail
open /dev/input/event18: No such device or address

/dev/input/event17
bustype : BUS_RS232
vendor  : 0x4
product : 0x1
version : 256
name: "Logitech M+ Mouse"
phys: "ttyS0/serio0/input0"
bits ev : (null) (null) (null)

# input-events 17
/dev/input/event17
bustype : BUS_RS232
vendor  : 0x4
product : 0x1
version : 256
name: "Logitech M+ Mouse"
phys: "ttyS0/serio0/input0"
bits ev : (null) (null) (null)

waiting for events
15:13:30.888773: (null) ??? (0x112) pressed
15:13:30.888773: (null) code=0 value=0
15:13:32.998688: (null) ??? -1
15:13:32.998688: (null) code=0 value=0
15:13:33.061029: (null) ??? -1
15:13:33.061029: (null) code=0 value=0
15:13:33.560736: (null) ??? 1
15:13:33.560736: (null) code=0 value=0
15:13:33.583775: (null) ??? 3
15:13:33.583775: (null) code=0 value=0
15:13:33.591262: (null) ??? 3
15:13:33.591262: (null) code=0 value=0
15:13:33.614295: (null) ??? 1
15:13:33.614295: (null) code=0 value=0
15:13:33.621787: (null) ??? 2
15:13:33.621787: (null) code=0 value=0
15:13:34.191695: (null) ??? 1
15:13:34.191695: (null) code=0 value=0
15:13:34.302401: (null) ??? 1
15:13:34.302401: (null) code=0 value=0
15:13:34.553504: (null) ??? (0x112) released
15:13:34.553504: (null) code=0 value=0
...

Here above we can see the middle button pressed, the mouse moved, and
the button released.
input-events produces essentially the same as you show.  All three 
buttons work similarly.




I think we are barking up the wrong tree here.  The application sees the
button because the pointer freezes when it is pressed.  What is missing
is X and Y movement info. while the button is pressed.


With the above example we can check if that is true.

Another way to test this is to use xev. Start xev, move the mouse xev's
window, press button, move, release, check the result:

ButtonPress event, serial 33, synthetic NO, window 0x321,
 root 0x4d3, subw 0x0, time 243503614, (56,88), root:(360,300),
 state 0x0, button 1, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
 root 0x4d3, subw 0x0, time 243504966, (57,88), root:(361,300),
 state 0x100, is_hint 0, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
 root 0x4d3, subw 0x0, time 243504989, (59,89), root:(363,301),
 state 0x100, is_hint 0, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
 root 0x4d3, subw 0x0, time 243505012, (60,90), root:(364,302),
 state 0x100, is_hint 0, same_screen YES

ButtonRelease event, serial 33, synthetic NO, window 0x321,
 root 0x4d3, subw 0x0, time 243505908, (60,90), root:(364,302),
 state 0x100, button 1, same_screen YES

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
With xev, buttons 1 and 3 are correctly identified but the middle button 
is randomly assigned 4,5,6 or 7.  Possibly this is the problem as I know 
the application is expecting button 2.


Best regards,
Fred

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] mouse driver question

2022-05-11 Thread karl
Fred:
> On 5/11/22 05:02, k...@aspodata.se wrote:

> > You should be able to do lsinput from input-utils package to see which
> > /dev/input/inputX file your mouse's byte stream transformed as events
> > would appear. And then run input-events X to see the events. E.g.:
> > 
> > # lsinput | tail
> > open /dev/input/event11: No such device or address
> > 
> > /dev/input/event10
> > bustype : BUS_I8042
> > vendor  : 0x2
> > product : 0xa
> > version : 0
> > name: "TPPS/2 IBM TrackPoint"
> > phys: "isa0060/serio1/input0"
> > bits ev : (null) (null) (null)
> Why did you pick event10?

Because that where the mouse is as shown by the lsinput output.

> I have event0 to 21 also mice and mouse0 in that directory.

Run lsinput and choose.

Here ia another example:

# modprobe  sermouse
# ./inputattach --daemon --mouseman /dev/ttyS0
# tail -2 /var/log/all
May 11 15:01:30 zoisit user.info kernel: [15477.331554] input: Logitech M+ 
Mouse as /devices/pnp0/00:01/tty/ttyS0/serio3/input/input19
May 11 15:01:30 zoisit user.info kernel: [15477.332229] serio: Serial port ttyS0
# lsinput | tail
open /dev/input/event18: No such device or address

/dev/input/event17
   bustype : BUS_RS232
   vendor  : 0x4
   product : 0x1
   version : 256
   name: "Logitech M+ Mouse"
   phys: "ttyS0/serio0/input0"
   bits ev : (null) (null) (null)

# input-events 17
/dev/input/event17
   bustype : BUS_RS232
   vendor  : 0x4
   product : 0x1
   version : 256
   name: "Logitech M+ Mouse"
   phys: "ttyS0/serio0/input0"
   bits ev : (null) (null) (null)

waiting for events
15:13:30.888773: (null) ??? (0x112) pressed
15:13:30.888773: (null) code=0 value=0
15:13:32.998688: (null) ??? -1
15:13:32.998688: (null) code=0 value=0
15:13:33.061029: (null) ??? -1
15:13:33.061029: (null) code=0 value=0
15:13:33.560736: (null) ??? 1
15:13:33.560736: (null) code=0 value=0
15:13:33.583775: (null) ??? 3
15:13:33.583775: (null) code=0 value=0
15:13:33.591262: (null) ??? 3
15:13:33.591262: (null) code=0 value=0
15:13:33.614295: (null) ??? 1
15:13:33.614295: (null) code=0 value=0
15:13:33.621787: (null) ??? 2
15:13:33.621787: (null) code=0 value=0
15:13:34.191695: (null) ??? 1
15:13:34.191695: (null) code=0 value=0
15:13:34.302401: (null) ??? 1
15:13:34.302401: (null) code=0 value=0
15:13:34.553504: (null) ??? (0x112) released
15:13:34.553504: (null) code=0 value=0
...

Here above we can see the middle button pressed, the mouse moved, and
the button released.

> I think we are barking up the wrong tree here.  The application sees the 
> button because the pointer freezes when it is pressed.  What is missing 
> is X and Y movement info. while the button is pressed.

With the above example we can check if that is true.

Another way to test this is to use xev. Start xev, move the mouse xev's 
window, press button, move, release, check the result:

ButtonPress event, serial 33, synthetic NO, window 0x321,
root 0x4d3, subw 0x0, time 243503614, (56,88), root:(360,300),
state 0x0, button 1, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
root 0x4d3, subw 0x0, time 243504966, (57,88), root:(361,300),
state 0x100, is_hint 0, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
root 0x4d3, subw 0x0, time 243504989, (59,89), root:(363,301),
state 0x100, is_hint 0, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x321,
root 0x4d3, subw 0x0, time 243505012, (60,90), root:(364,302),
state 0x100, is_hint 0, same_screen YES

ButtonRelease event, serial 33, synthetic NO, window 0x321,
root 0x4d3, subw 0x0, time 243505908, (60,90), root:(364,302),
state 0x100, button 1, same_screen YES

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] mouse driver question

2022-05-11 Thread Fred

Hi Karl,

On 5/11/22 05:02, k...@aspodata.se wrote:

Fred:
...

The Sun Compact 1 three button mouse is 1200 baud, 8 data bits, no
parity and sends 5 bytes in Mouse Systems protocol.  Byte 0 is button
info. exactly the same as msc.  Byte 1 is 8 bit signed X movement. Byte
2 is 8 bit signed Y movement.  Bytes 3, 4 are zero.


That fits the Mousesystems protocol as described in man mouse.

...

The problem seems to be that movement info. is not being sent or is
incorrect when the middle button is down.  The inputattach program
appears to be decoding the mouse protocol so I think that is where the
problem is.  I am not a C programmer so I can't determine what is wrong.

...

If I look at utils/inputattach.c from
  https://sourceforge.net/projects/linuxconsole/files/latest/download

inputattach does
. option handling
. sets the line discipline:
   ldisc = N_MOUSE;
   if (ioctl(fd, TIOCSETD, ) < 0) {
. sets the device type (e.g. it's a MSC mouse)
   ioctl(fd, SPIOCSTYPE, )
. goes into the background (daemon())
. stays there just emptying the input buffer of the serial port

So, inputattach does not decode the byte stream from the mouse.
Instead it seems that the kernels drivers/input/mouse/sermouse.c
does that. Look in the
  static void sermouse_process_msc(struct sermouse *sermouse, signed char data)
function.

So... the "input" way is too buggy. Why not consider the deprecated X11
mouse driver.

///

You should be able to do lsinput from input-utils package to see which
/dev/input/inputX file your mouse's byte stream transformed as events
would appear. And then run input-events X to see the events. E.g.:

# lsinput | tail
open /dev/input/event11: No such device or address

/dev/input/event10
bustype : BUS_I8042
vendor  : 0x2
product : 0xa
version : 0
name: "TPPS/2 IBM TrackPoint"
phys: "isa0060/serio1/input0"
bits ev : (null) (null) (null)

Why did you pick event10?
I have event0 to 21 also mice and mouse0 in that directory.



# input-events -t 100 10
/dev/input/event10
bustype : BUS_I8042
vendor  : 0x2
product : 0xa
version : 0
name: "TPPS/2 IBM TrackPoint"
phys: "isa0060/serio1/input0"
bits ev : (null) (null) (null)

waiting for events
11:58:57.217543: (null) ??? (0x110) pressed
11:58:57.217543: (null) code=0 value=0
11:58:57.356137: (null) ??? (0x110) released
11:58:57.356137: (null) code=0 value=0
11:58:59.084678: (null) ??? (0x112) pressed
11:58:59.084678: (null) code=0 value=0
11:58:59.225056: (null) ??? (0x112) released
11:58:59.225056: (null) code=0 value=0
11:58:59.613730: (null) ??? (0x111) pressed
11:58:59.613730: (null) code=0 value=0
11:58:59.689984: (null) ??? (0x111) released
11:58:59.689984: (null) code=0 value=0
^C
#

Where I pressed the left, middle and lastly right button on my laptop.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
I think we are barking up the wrong tree here.  The application sees the 
button because the pointer freezes when it is pressed.  What is missing 
is X and Y movement info. while the button is pressed.


Best regards,
Fred
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] mouse driver question

2022-05-11 Thread karl
Fred:
...
> The Sun Compact 1 three button mouse is 1200 baud, 8 data bits, no 
> parity and sends 5 bytes in Mouse Systems protocol.  Byte 0 is button 
> info. exactly the same as msc.  Byte 1 is 8 bit signed X movement. Byte 
> 2 is 8 bit signed Y movement.  Bytes 3, 4 are zero.

That fits the Mousesystems protocol as described in man mouse.

...
> The problem seems to be that movement info. is not being sent or is 
> incorrect when the middle button is down.  The inputattach program 
> appears to be decoding the mouse protocol so I think that is where the 
> problem is.  I am not a C programmer so I can't determine what is wrong.
...

If I look at utils/inputattach.c from
 https://sourceforge.net/projects/linuxconsole/files/latest/download

inputattach does
. option handling
. sets the line discipline:
  ldisc = N_MOUSE;
  if (ioctl(fd, TIOCSETD, ) < 0) {
. sets the device type (e.g. it's a MSC mouse)
  ioctl(fd, SPIOCSTYPE, )
. goes into the background (daemon())
. stays there just emptying the input buffer of the serial port

So, inputattach does not decode the byte stream from the mouse.
Instead it seems that the kernels drivers/input/mouse/sermouse.c
does that. Look in the 
 static void sermouse_process_msc(struct sermouse *sermouse, signed char data)
function.

So... the "input" way is too buggy. Why not consider the deprecated X11 
mouse driver.

///

You should be able to do lsinput from input-utils package to see which
/dev/input/inputX file your mouse's byte stream transformed as events
would appear. And then run input-events X to see the events. E.g.:

# lsinput | tail
open /dev/input/event11: No such device or address

/dev/input/event10
   bustype : BUS_I8042
   vendor  : 0x2
   product : 0xa
   version : 0
   name: "TPPS/2 IBM TrackPoint"
   phys: "isa0060/serio1/input0"
   bits ev : (null) (null) (null)

# input-events -t 100 10
/dev/input/event10
   bustype : BUS_I8042
   vendor  : 0x2
   product : 0xa
   version : 0
   name: "TPPS/2 IBM TrackPoint"
   phys: "isa0060/serio1/input0"
   bits ev : (null) (null) (null)

waiting for events
11:58:57.217543: (null) ??? (0x110) pressed
11:58:57.217543: (null) code=0 value=0
11:58:57.356137: (null) ??? (0x110) released
11:58:57.356137: (null) code=0 value=0
11:58:59.084678: (null) ??? (0x112) pressed
11:58:59.084678: (null) code=0 value=0
11:58:59.225056: (null) ??? (0x112) released
11:58:59.225056: (null) code=0 value=0
11:58:59.613730: (null) ??? (0x111) pressed
11:58:59.613730: (null) code=0 value=0
11:58:59.689984: (null) ??? (0x111) released
11:58:59.689984: (null) code=0 value=0
^C
#

Where I pressed the left, middle and lastly right button on my laptop.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng