Subject: Re: cleanup xsrc/xfree/xc/config/cf/NetBSD.c
To: Izumi Tsutsui <email@example.com>
From: Michael <firstname.lastname@example.org>
Date: 01/26/2005 11:05:01
-----BEGIN PGP SIGNED MESSAGE-----
>> I agree, the Xserver shouldn't have to meddle with PCI BARs, at least
>> not to access the framebuffer. On the other hand the drivers I've seen
>> so far map the framebuffer when you mmap() offsets between 0 and
>> As far as I can tell XFree's SBus code uses /dev/fb to talk to the
> I think current our cgsix.c provides mmap() function via /dev/fb.
That's exactly what XFree uses, at least to find framebuffers and
almost certainly also to access the hardware.
> (which is SunOS compatible?)
I think so, the Xsun source seems to indicate this.
> It's also provide to mmap register spaces, and an offset
> for fb memory is not zero. I guess that was the reason why
> OpenBSD guys introduced WSDISPLAYIO_MODE_DUMBFB for mmap op.
Probably. On the other hand I've yet to see a program that uses offset
0 to mmap() the framebuffer - XFree seems to expect BAR contents to
correspond to mmap() offsets though - not such a bad idea in my
opinion, especially on platforms where the BARs don't contain actual
physical addresses, like sparc64, because this way the Xserver doesn't
have to deal with this kind of remapping.
So maybe we should just provide a list of mmap()able address ranges,
probably with some additional flags which would sort of correspond to
PCI BARs but also work on - say - SBus?
(hmm, this would partially allow bus-agnostic userspace drivers... )
>> Agreed again, but it would be a bit more complicated - some PCI
>> framebuffers use more than one BAR for registers, then there's this
>> nonsense with hard-wired VGA registers and so on, some need access to
>> PCI IO space which is different on x86 and almost everything else -
>> kernel code that's not a problem thanks to bus_space_* but userland
>> code can't use it.
> Maybe we should have some generic APIs to access PCI space,
> but it may be another future project :-)
We have libpci, but it doesn't deal with IO abstraction at all. The
main difference is that on most non-x86 architectures you have to
figure out where the IO space of a particular PCI bus is mapped into
memory, mmap() it and then use the same macros as x86 ( like in8(),
out32() and so on ) - there should be some kind of abstraction which
covers this and x86's i386_iopl().
Shouldn't really be complicated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----