Intellimouse difficulties

SDL Development
1

Greetings to those met by these bits,

I am unable to correctly use my microsoft ps/2 intellismouse with the SDL
framebuffer target. It sees the mouse, but I only get garbage movement,
mostly towards the upper-right corner, and a lot of right clicks. GPM
and X both work fine with their IMPS/2 respective drivers.

What solutions are there for this? Am I best off trying to use use a
GPM repeater nad direct SDL to use /dev/gdmdata? And if so, what
environment variable do I need to set? Is there a way to have SDL read
that mouse data directly?

TIA for any help,
Benjamin Keil

2

I am unable to correctly use my microsoft ps/2 intellismouse with the SDL
framebuffer target. It sees the mouse, but I only get garbage movement,
mostly towards the upper-right corner, and a lot of right clicks. GPM
and X both work fine with their IMPS/2 respective drivers.

Looking briefly at SDL_fbevents.c’s FB_OpenMouse() function, if you’ve not
got a /dev/psaux node (which will be checked explicitly to see if it’s an
IMPS/2 protocol device), then SDL will fallback to trying /dev/mouse, and
assume that it’s a Microsoft serial mouse if it suceeds in opening it.

Which means if you’re system looks like most, that is:

$ ls -l /dev/psaux /dev/mouse
lrwxrwxrwx 1 root root 15 May 18 22:58 /dev/mouse -> /dev/psaux
crw-rw-rw- 1 root sys 10, 1 Apr 12 08:04 /dev/psaux

…then you’d be fine. But if you’ve got this:

$ ls -l /dev/psaux /dev/mouse
crw-rw-rw- 1 root sys 10, 1 Apr 12 08:04 /dev/mouse
(no such file for psaux)

…then SDL will get confused.

I wonder if it would be better to search /dev for a device with major 10,
minor 1 when searching for a PS/2 style mouse. Then again, devfs and
/dev/input/mice are suppose to supercede all this mess. :slight_smile:

This might not be your problem at all, but that’s the instant candidate I
see in the source.

As for environment vars, you can specify a mouse device (export
SDL_MOUSEDEV=/dev/psaux) and the IMPS/2 protocol (export
SDL_MOUSEDEV_IMPS2=yes)…just not at the same time. :slight_smile:

In short, as the source currently stands (I’m looking at 1.2 CVS), I’d say
try:

mknod /dev/psaux c 10 1
export SDL_MOUSEDEV_IMPS2=yes
./my_sdl_app

One of those two would almost HAVE to fix it.

Now I’m all guessed out. :slight_smile: Let me know if any of that helped.

–ryan.

3

In article <Pine.LNX.4.21.0105242348210.5156-100000 at gemini.verizon.net>,
“Ryan C. Gordon” wrote:

Looking briefly at SDL_fbevents.c’s FB_OpenMouse() function, if you’ve
not got a /dev/psaux node (which will be checked explicitly to see if
it’s an IMPS/2 protocol device), then SDL will fallback to trying
/dev/mouse, and assume that it’s a Microsoft serial mouse if it suceeds
in opening it.

First of all, thanks for your quick response, with the SDL_MOUSEDEV_IMPS2
variable, I was able to get it all to work. Now, moving on to your other
suggestions and questions…

I’m using devfs, and I’m not sure if that has anything to do with it. I
have a /dev/psaux which is a symlink to /dev/misc/psaux, which is the
10/1 character device. I have no file named /dev/mouse, and no directory
/dev/input.

Hope that sheds some light on the sibject.

Thanks again,
Ben.

4

I’m using devfs, and I’m not sure if that has anything to do with it. I
have a /dev/psaux which is a symlink to /dev/misc/psaux, which is the
10/1 character device. I have no file named /dev/mouse, and no directory
/dev/input.

Hmm…as far as SDL goes, if it manages to open() /dev/psaux (and by
extension, /dev/misc/psaux), then it’ll check to see if it’s an IMPS/2
mouse, in which case the test isn’t dependent on filename or device
numbers.

Apparently the test is failing; the environment variable just skips the
test and assumes you know that you really want an IMPS/2 mouse.

The ONLY other way I can see this failing is if the user running the SDL
app doesn’t have WRITE access to /dev/misc/psaux, since you write a byte
to the device (the byte is 0xF2, which I guess is the “query
protocol” request), and read the response. If you can’t write that byte,
it gives up on the IMPS/2 check.

Check the permissions on /dev/misc/psaux, and let us know.

That should really be an ioctl(), but now I’m complaining about kernel
design. :slight_smile:

–ryan.

5

The ONLY other way I can see this failing is if the user running the SDL
app doesn’t have WRITE access to /dev/misc/psaux, since you write a byte
to the device (the byte is 0xF2, which I guess is the “query
protocol” request), and read the response. If you can’t write that byte,
it gives up on the IMPS/2 check.

if that’s the problem perhaps we should check the permissions of the device
but it’s not clear what we should do about it.
Explicitly checking device major/minor numbers is seriously ugly

That should really be an ioctl(), but now I’m complaining about kernel
design. :slight_smile:

nothing should be an ioctl :slight_smile:

6

“Ryan C. Gordon” wrote:

I’m using devfs, and I’m not sure if that has anything to do with it. I
have a /dev/psaux which is a symlink to /dev/misc/psaux, which is the
10/1 character device. I have no file named /dev/mouse, and no directory
/dev/input.

Hmm…as far as SDL goes, if it manages to open() /dev/psaux (and by
extension, /dev/misc/psaux), then it’ll check to see if it’s an IMPS/2
mouse, in which case the test isn’t dependent on filename or device
numbers.

Apparently the test is failing; the environment variable just skips the
test and assumes you know that you really want an IMPS/2 mouse.

The ONLY other way I can see this failing is if the user running the SDL
app doesn’t have WRITE access to /dev/misc/psaux, since you write a byte
to the device (the byte is 0xF2, which I guess is the “query
protocol” request), and read the response. If you can’t write that byte,
it gives up on the IMPS/2 check.

Check the permissions on /dev/misc/psaux, and let us know.

bash-2.04# ls -l /dev/misc/psaux
crw-rw---- 1 root audio 10, 1 May 25 01:58 /dev/misc/psaux

bash-2.04# groups bkeil
bkeil : users nobody audio games

Not exactly sure why psaux comes out in the audio group… rummaging through
devfs.conf might solve it, but I don’t really care at this point.

Further probing reveals that the protocol test works when I run the program as
bkeil, but not when I run it as root. Does that make any sense?

Cheers,–
…
: Benjamin Keil VEGAN Publications :
: Webmaster and A Professional Website for :
: Strategy / Linux Editor Video Game Reviewing and Reporting :
:… http://www.veganpub.com/ …:

7

Benjamin Keil wrote:

Further probing reveals that the protocol test works when I run the program as
bkeil, but not when I run it as root. Does that make any sense?

On a related note, when I run the program as root from my console (matroxfb) it
restores the console on exit, but it seems like the hardware acceleration
(vertical scrolling) is disabled. This problem doesn’t happen when I run as a
regular user. It only affects the virtual console I run the app from. Killing
and restarting agetty on that console doesn’t help.

Not sure how really related that is, but it might be interesting.

Thanks again for all your help,–
…
: Benjamin Keil VEGAN Publications :
: Webmaster and A Professional Website for :
: Strategy / Linux Editor Video Game Reviewing and Reporting :
:… http://www.veganpub.com/ …:

8

Further probing reveals that the protocol test works when I run the program as
bkeil, but not when I run it as root. Does that make any sense?

No. In fact, I’m now COMPLETELY baffled. :slight_smile:

(shrug)

–ryan.

9

“Ryan C. Gordon” wrote:

Further probing reveals that the protocol test works when I run the program as
bkeil, but not when I run it as root. Does that make any sense?

No. In fact, I’m now COMPLETELY baffled. :slight_smile:

Well… actually… I completely wrong… I thought I had the mouse protocol
test working, but I think I just coincidentally moved the mouse in such a way
that the garbage movement matched my normal movement closely enough that I was
satisfied. Or maybe I had a SDL_MOUSEDEV_IMPS2 variable set that I overlooked
somehow. I didn’t see it in the output of “$ set”, though.

To verify that I could write to /dev/psaux, I tried the following

$ echo 72 > /dev/psaux
$

which seemed to work fine. It cause some strange behavior in a xterm, though :slight_smile:

Something’s wrong, but I can’t figure out what.

Cheers,–
…
: Benjamin Keil VEGAN Publications :
: Webmaster and A Professional Website for :
: Strategy / Linux Editor Video Game Reviewing and Reporting :
:… http://www.veganpub.com/ …: