Subject: Re: Xi FreeBSD X server, NetBSD failure (now partial success!)
To: None <port-i386@NetBSD.ORG>
From: None <Havard.Eidnes@runit.sintef.no>
List: port-i386
Date: 12/03/1997 23:02:21
Todd Vierling and a couple of others (thanks!) suggested essentially:

> It's not a FreeBSD system call; it's the fact that you don't have
> the FreeBSD shared libraries in /emul/freebsd/usr/lib/lib*.so.*,
> and the FreeBSD dynamic linker in /emul/freebsd/usr/libexec/ld.so
> ...

Ah, I should have thought of that.

Now I've dowloaded and installed shared libraries from a FreeBSD 2.2
system, and ldconfig'ed the FreeBSD libraries with the FreeBSD
ldconfig.

And much to my pleasure the X server now comes up.  There does
however seem to be a small problem with the mouse still to solve.

I used "trial and error" to find which type of mouse I should select
in the Xaccel server, and it turns out that the "busmouse" with the
use of /dev/pms0 is the correct choice in my case (not PS/2, as you
would intuitively guess).

The problem I have now is that the mouse works exactly for *one* X
session after a reboot, but not for any subsequent sessions.  From
reading the ktrace output for subsequent runs of the X server, it
would seem that the X server gets EAGAIN error code from read() of
the mouse device (/dev/pms0 on my Dell Latitude XPi-150CD).  The
mouse device is closed on exit of the first X server, and as far as
I can see there's only a few unimplemented (in NetBSD) ioctls being
done before the select/read loop in the X server.

Given that the probe of the ps/2 mouse device during the autoconfig
phase takes approximately 90s on my PC (see PR port-i386/4523), this
turns out to be fairly painful.

The problem is apparently reproducible without involving the X
server (!).  If I just do

# cat /dev/pms0

and move the trackball around, the first time I do this after a
reboot I get a stream of "funny characters" displayed on the screen,
and they come in proportion to the movement of the trackball.  If I
^C out of this and try it again, I get nothing (!).  Can this
somehow be related to the fact that the probe (and reset) of the
ps/2 mouse driver takes an inordinately long time during autoconfig,
or is it a general ps/2 mouse driver problem?

Oh, yes, this is with a kernel compiled from yesterday's sources.


Regards,

- H=E5vard