On 14 Dec 99 at 18:22, Tomas Berndtsson wrote:
> > > The first problem was that cgsix doesn't support changing resolution;
> > > it produced an error, because every ggi-demo seemed to set some
> > > resolution. The cgsix is set to 1152x900x8.
> > That's a problem. So do not run demos ;-) If your display supports
> > only limited functionality, you'll get only limited functionality
> > from libraries.
> Yes, but maybe the library shouldn't exit completely. The cgsix driver
Maybe program exits because of there is nothing to do if it requires
32bpp RGB, but you have 8bpp paletized only.
> gives error no matter what resolution you try to set with the ioctl,
> so even if you set 1152x900x8, it will fail.
At least this one resolution...
> > > priv->fb_ptr = mmap(NULL, priv->mmap_size, PROT_READ | priv->PROT_WRITE,
> > > MAP_SHARED, LIBGGI_FD(vis), 0);
> > > This will not work on the cgsix, because it needs an offset of
> > > 0x70016000 when mmapping the display. Similar, but other values on
> > > other cards. I think cgthree needs offset 0x04000000, although I
> > You are not serious, are you? mmapping on /dev/fb is DEFINED that at
> > offset zero there is framebuffer with length found in fix.smem_len.
> > Immediately after that there is mmio region with length fix.mmio.len.
> > (maybe you should add PAGE_ALIGN() around fix.*_len values; but driver
> > should report PAGE_ALIGNed values to userspace).
> > I see no notice about smem_start, about 0x70016000 and so on in that
> > sentece... You should fix cgsix, I think (are other tools (fbtv) able
> > to find your videomemory?).
> At least I have to use that offset in oFBis to mmap the display on the
> cgsix. I got the values from the XSun X server. I can't try fbtv right
> now.
> Maybe this is a bug in the sparc kernel?
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...
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]
