On 14 Dec 99 at 19:26, Jakub Jelinek wrote:
> > Maybe program exits because of there is nothing to do if it requires
> > 32bpp RGB, but you have 8bpp paletized only.
> Ok, but things are not that strightforward e.g. on the Creator.
> It is at all times able to do 8bpp and 32bpp at the same time.
> And it seems silly to me that the kernel should be involved in "changing" the
> depths on it, when it is a clear userland thing.
Kernel should be able to print message on console at any time. So it should
at least know which format is used for display. It is not problem for
Creator, as I see from your and Dave's description, but it is problem
for other hardware.
> As I said, the issue is binary compatibility. We used to mmap /dev/fb
> more than 4 years ago, at that time no fbcon existed (maybe in m68k
> port but not in mainstream). We cannot simply allow maps at offset 0 because
> some of the devices are already using those mmap regions for other things.
> I don't see what's the trouble to do getfix ioctl in userland, do a
> switch or table lookup on the known cards and set things up accordingly.
Unfortunately, it creates two APIs, one linux-except-sparc32,64 and
one linux-sparc-32,64+sunos. Is it possible to get these offsets somewhere
(except Sun X server)?
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
