Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!yarrina.connect.com.au!munnari.OZ.AU!news.hawaii.edu!ames!hookup!newsfeed.internetmci.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!news.mit.edu!shivers
From: shivers@ai.mit.edu (Olin Shivers)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: More on PS/2 mouse lossage
Followup-To: comp.unix.bsd.freebsd.misc
Date: 04 Dec 1995 05:14:37 GMT
Organization: Artificial Intelligence Lab, MIT
Lines: 38
Distribution: world
Message-ID: <SHIVERS.95Dec4001437@lambda.ai.mit.edu>
Reply-To: shivers@ai.mit.edu
NNTP-Posting-Host: lambda.ai.mit.edu
Well, I now know why the PS/2 mouse device, /dev/psm0, is not
cat'able. A quick glance through the driver, /sys/i386/isa/psm.c,
seems to indicate that if the device has an odd minor device number,
then a read(2) is always non-blocking, independent of what flags you give
to open(2). I have no idea why this is the case; there is no man page
for psm(4). Here's the relevant code from psm.c:
/* Block until mouse activity occured */
s = spltty();
while (sc->inq.count == 0) {
if (minor(dev) & 0x1) {
splx(s);
return(EWOULDBLOCK);
}
sc->state |= ASLP;
error = tsleep((caddr_t)sc, PZERO | PCATCH, "psmrea", 0);
if (error != 0) {
splx(s);
return(error);
}
}
Well, the device's minor device number is odd, so blocking reads are out.
I fired up my Scheme shell, and, sure enough, was able to interactively
open /dev/psm0, but a read on the port errored out with errno 35 = EWOULDBLOCK.
This is very strange behaviour; I don't know why the device works this way,
and I don't know if this is what is screwing up my X server.
Does anyone else know what's going on?
To forestall the obvious suggestions,
- my kernel config file has the proper "conflicts" keyword:
device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr
- I have successfuly rebuilt the kernel.
-Olin