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)

On Sun, 8 Feb 2009, Michael wrote:

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

On Sun, 8 Feb 2009, Michael wrote:

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.

        Could it be potentially useful in the future for arbitrary PCI
        boards on sparc64 and macppc? (Just curious)

        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.

        Ah - thanks.

        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.

        Its easier for users to determine what the value is, and that
        there is such a machdep value for the current host. I would
        have a slight preference for sysctl, but certainly not a strong

                David/absolute       -- No hype required --

Home | Main Index | Thread Index | Old Index