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

[David Brownlee <abs%NetBSD.org@localhost>]

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
        one.


--
                David/absolute       -- www.NetBSD.org: No hype required --