bterm vs. creator 3d
It appears there may be kernel bugs causing bterm problems.
----- Forwarded message from Daniel Jacobowitz <dan@debian.org> -----
Date: Sun, 25 Apr 2004 10:21:00 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Blars Blarson <blarson@blars.org>, 245620@bugs.debian.org
Subject: Re: Bug#245620: A little patch to help debug
On Sat, Apr 24, 2004 at 11:26:26PM -0700, Blars Blarson wrote:
> (gdb) print fb_fix
> $1 = {id = "Creator 3D\000\000\000\000\000", smem_start = 0,
> smem_len = 1310720, type = 0, type_aux = 0, visual = 2, xpanstep = 0,
> ypanstep = 0, ywrapstep = 0, line_length = 8192, mmio_start = 0,
> mmio_len = 0, accel = 11, reserved = {0, 0, 0}}
> (gdb) print fb_var
> $2 = {xres = 1152, yres = 864, xres_virtual = 1280, yres_virtual = 1024,
> xoffset = 0, yoffset = 0, bits_per_pixel = 32, grayscale = 0, red = {
> offset = 0, length = 8, msb_right = 0}, green = {offset = 8, length = 8,
> msb_right = 0}, blue = {offset = 16, length = 8, msb_right = 0}, transp = {
> offset = 0, length = 0, msb_right = 0}, nonstd = 0, activate = 0,
> height = 4294967295, width = 4294967295, accel_flags = 1, pixclock = 10000,
> left_margin = 0, right_margin = 0, upper_margin = 0, lower_margin = 0,
> hsync_len = 0, vsync_len = 0, sync = 0, vmode = 0, rotate = 0, reserved = {
> 0, 0, 0, 0, 0}}
> (gdb) print bogl_frame_len
> $3 = 1310720
xres_virtual = 1280
yres_virtual = 1024
bits_per_pixel = 32
Minimum memory you need for such a framebuffer is 1280 * 1024 * 4 =
5242880 bytes.
smem_len = 1310720
line_length = 8192
With that line length you'd need 8192 * 1024 = 8388608 (8MB).
So why does smem_len == 1024 * 1280? I think your kernel is lying.
Looking at the 2.6 Creator3D driver, I don't see where it initializes
smem_len. I can't see how xres_virtual and yres_virtual get larger
than xres/yres either.
Oh, you're using 2.4, let me look at the 2.4 driver. I see how you get
margins now. And it says:
type->fb_depth = depth = (fbtype == FBTYPE_SUN2BW) ? 1 : 8;
i.e. the 2.4 driver does not appear to support 32 bit. That's in
sbusfb.c, which then calls an init function in creatorfb.c, which
changes the depth to 24 and the bpp to 32 - but smem_len is never
changed. Thus the mapping is too small.
I don't think this bug has anything to do with bogl. Have you tried
any other framebuffer graphics application on this kernel? Excluding
X, which tends to ignore the kernel's information anyway.
Maybe debian-sparc knows more.
> It fills a block with red left to right accross the top of the screen
> for the first several calls of bogl_tcfb_text until xx exceeds 320
> where it is off of the screen. It loops back again and the red gets
> brighter. The red on the left third of the screen is brighter than
> the right, and it's bombing out before the screen is half full of red.
>
> The (white) text that was on the screen when it started stays on.
This certainly sounds like something is lying about the framebuffer
parameters.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
----- End forwarded message -----
--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
Reply to: