MikeOS libmouse doesn't work as expected on real hardware

[DVicthor]

In Bochs, libmouse works perfectly. But when I tested it on my HP Mini 200 (which emulates a PS/2 mouse with the trackpad), the cursor just ran around in a straight line at the top of the screen. Any ideas as to what could be the cause? Could it be the trackpad or do I need to change the configuration? I use mouselib_setup, so it could be that my PC doesn't support the def. config.

[Prochamber]

Is this post about the MikeOS mouse library?

[DVicthor]

Yes.

[Prochamber]

Have you tried using a USB mouse with PS/2 emulation?
Does the cursor work normally other than the fact it is locked to the left/right axis?
Does the cursor move very quickly/glitchy across the top of the screen?
Can you move the cursor back to the start position?

[freecrac]

And have you tried using the Cutemouse instead?
http://cutemouse.sourceforge.net/

The Cutemouse uses the bios int 15h/AX=0C20?h for to get an irq handler for a PS2-mouse.
(With the USB-legacy enable in the bios setup it is possible also to use an USB-mouse with it.)

This example of a PS-mouse-handler need to modify for to store the mouse bytes into a known memory location.

Code: Select all

checkPS2:
int 11h			; get equipment list
test    al, 3
jz  noPS2		; jump if PS/2-Mouse not indicated
mov	bh,3
mov     ax, 0C205h
int 15h		        ; initialize mouse, bh=datasize
jc noPS2
mov	bh,3
mov     ax, 0C203h
int 15h		        ; set mouse resolution bh
jc noPS2
mov     ax, cs
mov     es, ax
mov	bx, OFFSET PS2dummy
mov     ax, 0C207h
int 15h		        ; mouse, es:bx=ptr to handler
jc noPS2
xor     bx, bx
mov     es, bx		; mouse, es:bx=ptr to handler
mov     ax, 0C207h
int 15h
ret

noPS2:
stc
ret

PS2dummy:
retf
;---------------------------------------------------------
enablePS2:
call disablePS2
mov    ax, cs
mov    es, ax
mov    bx, OFFSET IRQhandler
mov    ax, 0C207h	; es:bx=ptr to handler
int 15h
mov	bh,1		; set mouse on
mov     ax, 0C200h
int 15h
ret
;-------------------------------
disablePS2:
xor	bx, bx		; set mouse off
mov	ax, 0C200h
int 15h
xor     bx, bx
mov     es, bx
mov     ax, 0C207h	; es:bx=ptr to handler
int 15h
ret
;---------------------------------------------------------------------------
IRQhandler:
		assume	ds:nothing,es:nothing
cld
push    ds
push    es
pusha
mov     ax, cs
mov     ds, ax
mov	bp,sp
mov	al,[bp+24+6]	; buttons
mov	bl,al
shl	al,3		; CF=Y sign bit
sbb	ch,ch		; signed extension 9->16 bit
cbw			; extend X sign bit
mov	al,[bp+24+4]	; AX=X movement
mov	cl,[bp+24+2]	; CX=Y movement
xchg	bx,ax
neg	cx              ; reverse Y movement
popa
pop	es
pop     ds
retf

Dirk

[DVicthor]

Have you tried using a USB mouse with PS/2 emulation?
Does the cursor work normally other than the fact it is locked to the left/right axis?
Does the cursor move very quickly/glitchy across the top of the screen?
Can you move the cursor back to the start position?

1. No, how can I do this?
2. Yes
3. Quickly
4. If drag my hand gently across the trackpad, yes.
Then something weirder happened. As at the time I posted this, i was trying to incorporate mouse support into the kernel, but when i ran the examples(on real hardware), it ran perfectly, and i used the same initialization code as the example, so I'm terribly confused right now.
EDIT: I removed the "push ds" and and a few more lines in mouselib_int_handler, it works at the first try, then locks to the first line again, if i drag the trackpad violently, the cursor moves to another line then back to the first.

[DVicthor]

@freecrac, I'll look into that. Thanks.

[Prochamber]

Hmm, something funny is going on.
I'll have a look at the code tonight.

[Brendan]

Hi,

Have you tried using a USB mouse with PS/2 emulation?
Does the cursor work normally other than the fact it is locked to the left/right axis?
Does the cursor move very quickly/glitchy across the top of the screen?
Can you move the cursor back to the start position?

1. No, how can I do this?
2. Yes
3. Quickly
4. If drag my hand gently across the trackpad, yes.
Then something weirder happened. As at the time I posted this, i was trying to incorporate mouse support into the kernel, but when i ran the examples(on real hardware), it ran perfectly, and i used the same initialization code as the example, so I'm terribly confused right now.

That sounds like the hardware is using one "mouse protocol" while you're expecting a different "mouse protocol", causing you to interpret the data incorrectly.

Can you post the code that issues the "read device ID" command; and the code that uses the returned "device ID" to determine which mouse protocol the hardware uses (and if it actually is a mouse, and not something like a bar-code scanner or something)?


Cheers,

Brendan

[Prochamber]

I'm rewriting some of the code in the library to initialize things a bit nicer.

@Brendan: Surely there is only one "mouse protocol"? i.e. a '0x00' = A standard PS/2 mouse with no extensions.

[Brendan]

Hi,

@Brendan: Surely there is only one "mouse protocol"? i.e. a '0x00' = A standard PS/2 mouse with no extensions.

No. For PS/2 mouse there's:

• a standard 3-byte protocol for 3-button mouse
• a standard 4-byte protocol for "3-button with scroll wheel" mouse
• a standard 4-byte protocol for "5-button with scroll wheel" mouse
• an unknown number of non-standard protocols

A mouse is a "relative co-ordinate" device - it tells you how far it has moved since last time (with 8-bits of "distance" and 1 bit of direction for both X and Y). For a touch-pad or touch-screen you want absolute co-ordinates. For example, if the user taps on the top left you want to know where they tapped (not "distance since last time"). You might also want to be able to handle multi-touch (2 or more places at once); and you might want more precision than "8+1" bits (e.g. I'd want 12-bits of X and 12-bits of Y for larger touch-pads and touch-screens).

Note: "touch-pad" isn't limited to the tiny little things you get on laptops, but includes large/precise touch-pads used by professional artists that are typically used with a stylus. Example:


To be honest; if I were designing a protocol for touch-pad and touch-screen I'd want to send a "one bit per co-ordinate" bitmap with a variable width and height (determined by how sensitive the device is), where the raw bitmap data is sent as run-length encoded horizontal strips (to reduce bandwidth).

Now; given that using a mouse protocol for touch-pads is completely stupid and broken to start with; and given that PS/2 is a serial communication protocol and is not limited to just keyboard and mouse and could be used for a very wide variety of very different devices; if a touch-pad actually does use a mouse protocol at all, then surely it should be assumed that the touch-pad's mouse protocol is a hacky broken legacy mode for compatibility that should never actually be used.

For a random example; I downloaded a "Synaptics TouchPad Interfacing Guide". They use a protocol where a packet contains an (absolute) 13-bit X co-ord and 13-bit Y co-ord, an 8-bit "pressure" value, and a "tap/drag gesture in progress" flag. They also include a hacky broken legacy "mouse protocol" mode for compatibility that should never actually be used.

[EDIT]I didn't spend much time reading the "Synaptics TouchPad Interfacing Guide". Apparently their newer touchpads also have a "W value" used to determine if the touch-pad is being touched by 2 or more fingers, a pen, a very wide finger or palm, etc.[/EDIT]


Cheers,

Brendan

[Brendan]

Hi,

Just to put my previous post into context...

Normally (due to backward compatibility) when a PS/2 device is reset properly it should (fingers crossed, if it's not too dodgy) begin in its default mode (e.g. the "hacky broken legacy 3-button mouse protocol" mode for pointing devices); then the OS has to go through a sequence of steps in an attempt to enable subsequent modes and ask the device for its ID again to determine if it accepted/supports the mode.

Basically; if the device says it's a "3-button mouse" you'd try to enable the "3-button with scroll wheel" protocol and see if it worked; then try to enable the "5-button with scroll wheel" protocol and see if it worked; try to enable any number of different touch-pad protocols and see if any of them worked. Once you've done all of this and know what the device is and which protocol should be used you can begin initialising the device/device driver properly.


Cheers,

Brendan