Xorg woes and partial tips

[tlaronde%polynum.com@localhost]

Hello,

The previous version of Xorg in pkgsrc (pkgsrc-2010Q1) having issues 
on my :

NetBSD 3.1.1_PATCH i386

I have "upgraded" with the version in pkgsrc-2010Q2.

My previous problems were with the cursor, that was whether grabbed by a
window, or suddenly shifting to +0+0 with the necessity to switch to the
keyboard to move the cursor to ungrab or unstore it.

There are still problems with the cursor, and more problems with the VT.

To stabilize a little, I have to throw away the "auto-detect"
improvements (linked to Linux hal if I understand correctly) by adding
this to xorg.conf :

Section "ServerFlags"
        Option "AutoAddDevices" "false"
        Option "AllowEmptyInput" "false"
EndSection

Important enough is the "AllowEmptyInput" set to "false" since, if not,
you can have a display and strictly no input, that is no means (except
with remote connection) to stop the thing.

Furthermore, with ati/radeon, I have to choose "EXA" acceleration if I
want to stabilize the cursor. With "XAA", I have more acceleration
(pixmap) but the cursor jumps.

Exiting from X/radeon, the VT is fading. If you relaunch (xinit(1)),
every time the VT fade more untill you can see strictly nothing.

xgamma(1) has an effect on the X display (VT5) but strictly none on the
wscons VT.

To "reset" I can use the X server vesa(1). But it takes ages to launch
(30 secondes), apparently beating around the bush about the keyboard.

Once the vesa display is launched, the wscons VT are gradually
hightlighted ; that is, if you have exited one from radeon, launching
once vesa resets everything ; if you have exited n from radeon, one
needs to relaunch n times vesa to restore.

Furthermore, from time to time, the input on the display freezes (no
keyboard, no pointer). Only solution : remote connection, say ssh(1),
and you have to kill the programs including X. But this is not enough,
you must switch to root to remove /tmp/.X* or you will not be able to
relaunch X.

Why relaunch X? Simply because the VT consoles are unusable, even if you
can enter commands: the card seems in graphics state, not text state, 
and on all the VT consoles one sees part of the "paperwall" consisting
of the frozen display. But relaunching X(1) gives you at least a 
correct X display; even if the only correct solution is to reboot---and
sometimes cold reboot, since the BIOS caches various config data in
NVRAM and this may be havoc.

Using wsconscfg(8) to add or remove VT doesn't help, at least simply
deleting and adding doesn't help. Are there commands to reset the
graphics card via the console?

Even if Xorg is modular, and if the various dependencies are
superficially satisfied, I had initially even more problems before
upgrading various components of the X system (libraries) to latest
versions.

The interaction between X and wscons is partially problematic, but all
problems don't come from here (see the divergent behavior in X switching
between EXA and XAA acceleration implementations).

A note: the mousedrv(4) (said to be mouse(4) in X man pages) lists a
"USB" protocol that doesn't exist; removing "wscons" protocol and
device /dev/wmouse is no problem since the default finds them correctly.

[Various "mood" comments removed by the politically correct department]

I'm starting to understand why NetBSD developers had provided xsrc...
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C