tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: X11 per machine_arch not per port (Was: Moving ports across to X11R7)

Hash: SHA1


On Feb 8, 2009, at 12:17 PM, David Brownlee wrote:

On Sun, 8 Feb 2009, Michael wrote:

        Is moving to X11R7 a good time to make X11 sharable per
        machine_arch rather than per port?

        At the moment only amd64, i386, macppc, shark, & sparc64 have
        moved across, so...

Should work for the client stuff at least. The only incompatibility I can think of right now is the way we mmap (PCI) IO space on powerpc and shark - by picking a magic address range which isn't used by any PCI device, on macppc it's 0xf2000000 ( traditionally the 1st PCI bridge's IO range ), prep and ofppc use different values, they're currently #defined in sys/params.h so there are no magic values or #ifdefs in the Xserver. We could just add an ioctl so the Xserver can ask the kernel where it would find IO space, that would take a few clock cycles more during setup but the result would be the same and Xservers would be compatible across $MACHINE_ARCH.

        Is there any sense in adding it to the information exported by
        /dev/fb? (I expect "no" is the answer here, but just checking).

We don't need it on sparc(64) - all the Sun graphics boards I've seen so far either map no IO space or have all the registers accessible via memory space too. We need it on macppc and shark for chips like the C&T 65550 or IGS CyberPro where only the blitter is memory mapped and all the rest is in extended VGA registers.

        Having the kernel report the value definitely seems the cleanest
        option - it would allow new ports to just use an existing Xwsfb
        without needing to rebuild anything on the X side.

This has absolutely nothing to do with Xwsfb - it's for mapping IO register space which an Xserver like Xwsfb wouldn't know or care about. Failure to mmap IO space is non-fatal for exactly the reason you stated.

        Another option might be to provide it via a machdep sysctl value?

I fail to see the advantage over an ioctl - it's not like this is a value which users should be able to change.

have fun

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index