DragonFlyBSD

Well, I was planning to add more data here, but, after rebooting, rebooting
again to disable gdm(!), and starting Xorg with moused running:

I can no longer reproduce the problem. It actually just works now. It works
with sysmouse, it works when aimed at the mouse port(s) directly. It works
after rebooting again with just my original USB mouse and no PS/2 device attached.

Mysterious, indeed. I can only assume that, somehow, on my last boot, the
previously-running monolithic server and gdm continued to cause some sort of
problem even after both were well and truly killed.

So... my gdm install is borked right now, probably easily cured tomorrow, and...
it otherwise works. Downgrading this to 'bug,' as such, since there's no
'mystery that deserves documenting' priority.

I swear that fstat showed nothing left holding either /dev/ums0 or /dev/psm0
open after I'd gotten around to killing moused during my first round of testing.
Of course, that doesn't mean something hadn't twiddled properties
not-readily-apparent. (Would it be easy for some earlier access to screw up
/dev/sysmouse while moused is still happily providing services on the console?
That seems to have been what happened, and killing and restarting moused N
times, where N is an integer >10 obviously didn't reset it.)

Possible steps to a fix for other victims:

1. Disable gdm (or xdm, etc.) completely in rc.conf and do a real reboot.

2. If that doesn't do it and you're a USB user, reboot again with a PS/2 mouse
attached. Point Xorg at /dev/psm0 directly, then see if it's equally happy
using sysmouse with moused enabled.

3. If it persists, look for anything else possibly touching the mouse devices in
any way, and... well, get those out of the way and reboot. It would seem that
stubbornly not-rebooting (why would I need to?) prevented me from discovering
that things could work perfectly under 'normal' conditions where nothing else
had meddled with the devices previously.

Many thanks to those around to stare at this with me, even if the 'solution'
proved anticlimactic.

Brief status update, possibly to be opened as a new issue / new issues if I find
anything more:

X (the server) dies on signal 11 if /tmp/.tX0-lock and/or /tmp/.X0-lock exist.
This is probably not the intended behavior, since IIRC previous versions would
complain about locks.

Right now I can happily move the cursor around on a checkerboard screen by
running the X or Xorg link, but using startx (requires the x11/xinit package) or
gdm results in a black screen that persists after the server dies. I don't get
it -- it could be that I normally use Gnome and that could be turning up trouble
with, say, libXrandr, but trying it under accounts that should definitely just
be giving me twm turn up the same problem. I'll be doing some more tracing and
seeing if I can get to the bottom of that.

FWIW, I did confirm that my clients aren't broken and run properly to a
different display.

Resolved.

Unfortunately, I never found the culprit, but mv'ing /usr/pkg (and its db in
/var) to ensure that every single Xorg dependency (and gdm, and all its
dependencies) was freshly built did fix it.

The new binaries continue to play nice when copied atop the old /usr/pkg tree
and same is mv'd back into place. YMMV.

This on DragonFly 1.11.0-PREVIEW from Nov 23 2007, pkgsrc-2007Q3.
The old Xorg had the same problems after that update until the above was performed.

Reminder: If you move /usr/pkg aside and your login shell lives there...

GNOME users: The only lingering issue is a mouse problem in GNOME. This
doesn't occur with gdm or twm left running all night, but after an indeterminate
time in a gnome-session (MTBF 15 minutes), the pointer jumps to the top left
corner and 'sticks' there, yet button events still work. Replugging the mouse
is no cure and moused doesn't seem to be an issue, so it's probably somewhere in
GNOME itself. When I figure this one out I'll document it in the bugtracker.