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 2:27 PM, David Brownlee wrote:

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)

Not really. Remember, this is for mmap()ing a graphics adapter through wsdisplay's ttys. The option to mmap the appropriate IO space was added so the Xserver wouldn't have to know or care about the underlying bus topology - many Macs can have more than one PCI domain for example. This way we just hand it the IO space that contains the device's IO registers.

        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

What would they do with it unless they want to hack the Xserver? This value is certainly not useful to 'normal' users.

have fun

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index