Jakub Jelinek <[EMAIL PROTECTED]> writes:
> > If you are mmapping /dev/mem, there can be different offsets (exactly
> > one offset, equal to fix.smem_start). If you are mmapping /dev/fb*,
> > there is 0 offset for video memory. This is definition for mmap
> > on /dev/fb and for fix.smem_start field (and mmap on /dev/mem semantic).
> > 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...
>
> 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.
The trouble is not for known cards, but for (according to the
graphical library) unknown cards. If there had been a set standard
that all cards could follow, and all new cards would also follow this,
no updates would be needed of the library to get things to work.
What about storing an mmap offset in `struct fb_fix_screeninfo'?
Greetings,
Tomas
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
