From: cglur@onwe.co.za
Date: Mon May 06 2002 - 07:51:38 CEST
> Someone else proposed this:
>
> "dd if=/dev/ttyS0 of=/dev/null bs=1 count=1 && halt"
>
> But I can klick as much as I want, it doesn't shut down :-(
Let's try to work systematically, instead of 'shooting from the hip' ?!
Since someone suggested that mouse protocol is 3 chars long,
lets get multiples of 3 bytes and save to a file for
inspection/analysis.
Here the log of what I did, with comments:------------------
Since presently gpm is using /dev/tty0 lets put an extra mouse
on the second serial port and use /dev/tty1.
Apparently unix see all devices as 'files' ?
Apparently the dd command can read from any file/device and write
to any file/device ?
dd --help shows the sytax/usage for mulinux
dd if=/dev/ttyS1 ibs=1 obs=1 count=60 of=/mouse.data
would hopefully:
read input from /dev/ttyS1
input 1 byte(s) at a time
output 1 byte(s) at a time
copy only 60 (1 byte) input blocks
write to file /mouse.data for later inspection
This was not successful. The dd command did not return after several
mouse activities, which would presumably have been read by port
/dev/ttyS1.
The dd command had to be aborted by Control-C.
Let's try /dev/ttyS0. But this is currently used by gpm.
The command ps will show all running processes including gpm.
We see:
1702 ? S 0:0 (gpm) gpm -m /dev/mouse -t ms -r 10
so:
kill 1702
will kill the gpm proccess and make /dev/ttyS0 free for experimenting.
Now executing:
dd if=/dev/ttyS1 ibs=1 obs=1 count=60 of=/mouse.data
with the mouse turned upside down, so that no signal are sent by
it's 'movement', we can click the button(s); which, after several
click, signals that the 60 bytes have been received - and stored to
file mouse.data.
Inspecting the saved chars shows (typically):
M3..$+9%....<<-/53%<0.0.&.#.. P..@..P..@..P..@..P..@..P..@..
Which using mc (no linux user should be without this 'killer application'
on diskette WKS for mulinux) shows the hex value of the 60 bytes as:
00000 4D 33 08 01 24 2B 39 25 10 10 10 11 3C 3C 2D 2F M3..$+9%....<<-/
00010 35 33 25 3C 30 2E 30 10 26 10 23 19 14 09 50 00 53%<0.0.&.#...P.
00020 00 40 00 00 50 00 00 40 00 00 50 00 00 40 00 00 .@..P..@..P..@..
00030 50 00 00 40 00 00 50 00 00 40 00 00 P..@..P..@..
This looks like some 'initialisation pattern' followed by a repeated pattern
of 6 bytes: 50 00 00 40 00 00 ??
Also the number of times you need to click to get the 60 bytes, should
tell something. I found: Left=5, Mid=4, Right=5
By testing for left, mid, right button we can determine which char-string
is sent by each button. Consider also down-click and release-click.
My test indicate:
right = 50 00 00 40 00 00 = pattern of 6 chars
mid = 40 00 00 20 40 00 00 00,
40 00 00 20 40 00 00 00,
40 00 00 20 40 00 00 00,
40 00 00 20 40 00 = pattern of 8 chars
left = 60 00 00 40 00 00,
60 00 00 40 00 00,
60 00 00 40 00 00,
60 00 00 40 00 00,
60 00 00 40 00 00 = pattern of 6 chars
NB. the above tables are obtained by simply using mc and cut and paste
with gpm.
By capturing the char strings for sequences eg:
Left-down, mid-down, left-up, mid-up; we could determine which chars
of "40 00 00 20 40 00 00 00" are for 'down' and which for 'up'.
Probably 4 chars each ?
BTW the file 'Header' seems to be 1e bytes long:
00000 4D 33 08 01 24 2B 39 25 10 10 10 11 3C 3C 2D 2F M3..$+9%....<<-/
00010 35 33 25 3C 30 2E 30 10 26 10 23 19 14 09
Once we've establish (instead of guessing) if/what chars are returned
by the mouse, we can systematically move toi the next step.
I think, the original poster wanted to use the mouse to do a specific
command? The oberon OS uses a large number of mouse key combinations
(cording) to do the most common tasks.
How would mulinux's script (?ash?) write:
IF /dev/ttyS0's-char-sequence = b0....b7 THEN execute-cmnd
??
Why did /dev/ttyS1 not see the serial input signal ?
-- Chris Glur.
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.dk
For additional commands, e-mail: mulinux-help@sunsite.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:22 CET