Subject: Re: who is using modular X.org?
To: Jeremy C. Reed <reed@reedmedia.net>
From: Michael Lorenz <macallan@netbsd.org>
List: tech-x11
Date: 05/25/2006 13:35:45
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> I imported it a while ago, added the missing bits and pieces to make 
>> it work
>> on sparc64 ( because that's my main work horse and 64bit problems are 
>> more
>> likely to show up on BE machines ) Seems reasonably stable so far.
>
> Thanks for the info.
>
> Do you plan on commiting upstream? Or submitting via freedesktop.org
> bugzilla?

Of course. As soon as I'm done moving and my hardware is usable again :)
Only committed them into xsrc right before packing up so others can 
review and play with them.

> I made a patch based on your changes and I could probably commit some 
> of
> it, but would want to make sure it doesn't break non-NetBSD. For 
> example:
> "Hide mouse cursor on exit, don't blank screen before mmap()ing 
> registers"
> -- Is that specific for NetBSD?

No. The sunffb driver is full of bugs and doesn't really work as it is 
in xorg 7.0. We have other fixes as well ( like redrawing the whole 
screen on unblank on old ffb1 boards because blanking too long seems to 
muck up VRAM content there ) which I didn't port over yet.
None of that is in any way specific to NetBSD, but nobody seems to test 
this driver anywhere, especially not in a 64bit environment. I get the 
feeling we're the only ones who have it anywhere near working properly 
;)

> I also saw some things that simply commented out definitions which may
> break OpenBSD too.

In the PCI code I guess? Yes, it's not really cleaned up yet. I just 
took over things from xsrc/xfree.
I have a hack that would eliminate accesses to /dev/pci, /dev/ttyE* and 
use /dev/fb* instead on sparc64 ( that's why machfb exposes a /dev/fb 
at all ), maybe I should commit that at some point as well - it allows 
to use as many heads as you can cram video controllers into the 
machine, I ran my U10 triple headed with a Creator, onboard mach64 and 
a PCI Matrox Millennium II ( using a generic fb-only 'driver' ). 
Impossible with current xsrc since it mmap()s everything through ttyE0 
which lets you access only the console fb.

> Please let me know if you want me to submit all your changes (that 
> aren't
> in upstream already) to bugzilla.

Feel free to submit what you think can be submitted. There's more to 
port over, like the acceleration code for cg6 boards, the pnozz driver 
etc. and I have no real idea if i broke anything for other platforms.

>> Saw your posts on the xorg mailing list - I fixed the X vs. X0 problem
>> locally ( not sure if I committed it, I'm in the middle of moving ) -
>> the socket is getting the wrong name length, one too short so the 0 is
>> cut off but the unlink() call gets the correct name ( with trailing 0 
>> )
>> so the socket is not deleted.
>
> I didn't see that committed, so if you can please do so. Thanks!

Won't be able to do that for a few weeks - the machine with the source 
is packed up. The bug is in the address length field when calling 
bind(), should be trivial to fix.

> I have also been defining _POSIX_THREAD_SAFE_FUNCTIONS, but I wasn't 
> sure
> about (and didn't test) some older NetBSDs.

Should be fine at least with 3.0 and newer ( I tested only on -current 
though ).

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRHXq8cpnzkX8Yg2nAQLmwQgApuRkuf5YtO3x3snTQdYdHPV3W5uCeeL0
UMhWpGl3YXfryj5u16d35ipl6eI03PTo+d+CR/ShRIKjcU5aU2G7UmlJx6YPJxgw
G3JE1+zknDaCw4J2GhnBP6072GuJf19wgMWECvbEWdodsmd6+eTjJnzGYF6lPOfF
RbgkPK+QBp+akx10Nk2wEKYqEIZpfB3fd2QClaLxMSwIRbaVMU+KIWgHxQrRy4yW
Ruuap+yrbt5BGKeAXUdqzM0wUNF08s56c+7QpsIWe2le+eP1i2wKGmVFwJsXOG/Y
F0QBKGPkTIE7X4NpgCaq3FH6BO6AScL1nQwzj4pdmipRlwzzPbrpgw==
=uJD1
-----END PGP SIGNATURE-----