On Tue, 14 Dec 1999, David S. Miller wrote:
> From: "Petr Vandrovec Ing. VTEI" <[EMAIL PROTECTED]>
> Date: Tue, 14 Dec 1999 18:32:27 MET-1
>
> If driver/hardware supports more ways to access framebuffer
> ((non-)native endianess, cached/uncached), driver should choose one
> of accesses and fill fix screen info (and support mmap) accordingly
> to this. But never-ever use some magic constants...
>
> You are assuming that Linux kernel created /dev/fb standard should
> subsume all existing standards for such devices which existed several
> years before Linux's /dev/fb was conceived.
IIRC, we (the m68k people) registered /dev/fb* (char device major 29) near the
end of 1994/beginning of 1995. Hence to me it sounds logical that if the
developers for a different architecture decide to recycle the same device node
for similar purposes, they make sure they're compatible with the semantics on
the original platform.
> See my other email, the way SBUS framebuffers behave for /dev/fb mmaps
> is not changing.
Which was first, the egg or the penguin? :-)
I'm aware this is an issue that dates back to an era cross-platform
compatibility wasn't much of an issue. Which makes things much more difficult
to sort out and reach a consensus...
Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
