cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

[Alex Buell]

Hi guys,

I have a patch here that fixes an annoying bug in the cg14 framebuffer
driver on sparc32 platforms. The bug is when it never switches off the
cursor before going into X11 mode, so you get an 'orrible cursor
overlaying whatever you've got on the screen, in the same position as the
consoles. Switching to any console and back to the X11 display, the cursor
overlays the last position the cursor was in on the console. On
investigating, discovered that the cg14 framebuffer doesn't switch off the
cursor!

Here's the patch:

--- linux/drivers/video/cgfourteenfb.c.orig     Thu Jul 26 11:34:00 2001
+++ linux/drivers/video/cgfourteenfb.c  Thu Jul 26 11:48:30 2001
@@ -234,6 +234,9 @@
        spin_lock_irqsave(&fb->lock, flags);
        if (c->enable)
                cur->ccr |= CG14_CCR_ENABLE;
+       else
+               cur->ccr &= ~CG14_CCR_ENABLE;
+
        cur->cursx = ((c->cpos.fbx - c->chot.fbx) & 0xfff);
        cur->cursy = ((c->cpos.fby - c->chot.fby) & 0xfff);
        spin_unlock_irqrestore(&fb->lock, flags);


-- 
Hey, they *are* out to get you, but it's nothing personal.

http://www.tahallah.demon.co.uk

Re: cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

[David S. Miller]

Alex Buell writes:
 > I have a patch here that fixes an annoying bug in the cg14 framebuffer
 > driver on sparc32 platforms.

I've made this change in both my 2.2.x and 2.4.x trees.

Thanks a lot for hunting this down and making a fix.

Later,
David S. Miller
davem@redhat.com

Re: cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

[Alex Buell]

On Fri, 27 Jul 2001, David S. Miller wrote:

> I've made this change in both my 2.2.x and 2.4.x trees.
> Thanks a lot for hunting this down and making a fix.

Is the 2.4.7 fix anything like this:

       if (c->enable) {
                u8 tmp = sbus_readb(&cur->ccr);

                tmp |= CG14_CCR_ENABLE;
                sbus_writeb(tmp, &cur->ccr);
        }
        else {
                u8 tmp = sbus_readb(&cur->ccr);

                tmp &= ~CG14_CCR_ENABLE;
                sbus_writeb(tmp, &cur->ccr);
        }

It looks a bit ugly though. I'd prefer:

	u8 tmp = sbus_readb(&cur->ccr);

	if (c->enable)
		tmp != CG14_CCR_ENABLE;
	else
		tmp &= ~CG14_CCR_ENABLE;

	sbus_writeb(tmp, &cur->ccr);

I'll test this as soon as I recompile 2.4.7 with egcs 1.1.2 to prove a
theory of mine that using 2.95.3 results in non-bootable kernels.

PS: I'm still learning the internals of the sparc32 port. Lots of lovely
confusing bits to hack my way through. :o)

-- 
Hey, they *are* out to get you, but it's nothing personal.

http://www.tahallah.demon.co.uk

Re: cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

[Anton Blanchard]

Hi,

> I'll test this as soon as I recompile 2.4.7 with egcs 1.1.2 to prove a
> theory of mine that using 2.95.3 results in non-bootable kernels.

Im compiling my kernels on 2.95.3 at the moment. I found one bug that
turned out to be my fault (in include/asm-sparc/bitops.h), but there
are sure to be more I havent caught yet.

Anton

Re: cg14 frambuffer bug in 2.2.19 (and probably 2.4.x as well)

[Alex Buell]

On Sat, 28 Jul 2001, Anton Blanchard wrote:

> Im compiling my kernels on 2.95.3 at the moment. I found one bug that
> turned out to be my fault (in include/asm-sparc/bitops.h), but there
> are sure to be more I havent caught yet.

Hmm, just seen davem's list of CVS commits, have run an update just now,
and will try again using 2.95.3.

Here's a patch to apply on top of the fix applied to 2.4.7 today, to fix
the ugliness of the if {} else {} statement and save a few bytes.

PS: If we need to discuss this any further, let's move this back to
sparclinux mailing list, shall we?

--- linux/drivers/video/cgfourteenfb.c.orig     Fri Jul 27 17:41:15 2001
+++ linux/drivers/video/cgfourteenfb.c  Fri Jul 27 17:46:15 2001
@@ -236,19 +236,17 @@
        struct cg_cursor *c = &fb->cursor;
        struct cg14_cursor *cur = fb->s.cg14.cursor;
        unsigned long flags;
+       u8 tmp;

        spin_lock_irqsave(&fb->lock, flags);
-       if (c->enable) {
-               u8 tmp = sbus_readb(&cur->ccr);
+       tmp = sbus_readb(&cur->ccr);

+       if (c->enable)
                tmp |= CG14_CCR_ENABLE;
-               sbus_writeb(tmp, &cur->ccr);
-       } else {
-               u8 tmp = sbus_readb(&cur->ccr);
-
+       else
                tmp &= ~CG14_CCR_ENABLE;
-               sbus_writeb(tmp, &cur->ccr);
-       }
+
+       sbus_writeb(tmp, &cur->ccr);
        sbus_writew(((c->cpos.fbx - c->chot.fbx) & 0xfff), &cur->cursx);
        sbus_writew(((c->cpos.fby - c->chot.fby) & 0xfff), &cur->cursy);
        spin_unlock_irqrestore(&fb->lock, flags);


-- 
Hey, they *are* out to get you, but it's nothing personal.

http://www.tahallah.demon.co.uk