All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ronald Lembcke <es186@fen-net.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ronald Lembcke <es186@fen-net.de>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: bugfix für RadeonFB (against 2.4.22-ac4, bug in 2.6.0-test9, too)
Date: Wed, 19 Nov 2003 12:50:16 +0100	[thread overview]
Message-ID: <20031119115016.GA2912@defiant.crash> (raw)
In-Reply-To: <Pine.GSO.4.21.0311191043110.7852-100000@waterleaf.sonytel.be>

On Wed, Nov 19, 2003 at 10:50:22AM +0100, Geert Uytterhoeven wrote:
> Your change is not correct: bpp is the _physical_ bits per pixel, i.e. it's 16
> for both color depth 15 (5/5/5 mode) and color depth 16 (5/6/5).
> 
> To differentiate between 5/5/5 and 5/6/5, you have to look at green.length, and
> apply standard fbdev fit-our-round-up[*] rules.
I don't see where this rule applies here. I searched on google, but
did't find anything about rounding of color depth.

> Note that some hardware in addition does RGBA4444, too.
Yes, but that nothing to do with these patches.

Sorry, I don't see, where my patches for intelfb and radonfb (as said
before, I'm not sure about the imsttfb patch anyway) make the driver
less correct. Where are they wrong?

Nothing about the use of bits_per_pixel is changed.
The only change is whether 555 or 565 is default.

If those patches are wrong, than matroxfb and rivafb are buggy, too:

matrox/matroxfb_crtc2.c:
	if (var->bits_per_pixel == 16) {
		if (var->green.length == 5) {
			var->red.offset = 10;
			var->red.length = 5;
			var->green.offset = 5;
			var->green.length = 5;
			var->blue.offset = 0;
			var->blue.length = 5;
			var->transp.offset = 15;
			var->transp.length = 1;
			*mode = 15;
		} else {
			var->red.offset = 11;
			var->red.length = 5;
			var->green.offset = 5;
			var->green.length = 6;
			var->blue.offset = 0;
			var->blue.length = 5;
			var->transp.offset = 0;
			var->transp.length = 0;
		}



riva/fbdev.c
        switch (v.bits_per_pixel) {
[...]
	case 9 ... 15:
		v.green.length = 5;
		/* fall through */
	case 16:
		v.bits_per_pixel = 16;
		nom = 2;
		den = 1;
		if (v.green.length == 5) {
			/* 0rrrrrgg gggbbbbb */
			v.red.offset = 10;
			v.green.offset = 5;
			v.blue.offset = 0;
			v.red.length = 5;
			v.green.length = 5;
			v.blue.length = 5;
		} else {
			/* rrrrrggg gggbbbbb */
			v.red.offset = 11;
			v.green.offset = 5;
			v.blue.offset = 0;
			v.red.length = 5;
			v.green.length = 6;
			v.blue.length = 5;
		}
		break;


They do the same thing as intelfb and radonfb with the patches applied.
So both must be wrong or right.

Roni

  reply	other threads:[~2003-11-19 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-05 22:57 PATCH: bugfix für RadeonFB (against 2.4.22-ac4, bug in 2.6.0-test9, too) Ronald Lembcke
2003-11-06  7:14 ` Benjamin Herrenschmidt
2003-11-19  9:50 ` Geert Uytterhoeven
2003-11-19 11:50   ` Ronald Lembcke [this message]
2003-11-19 11:57     ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031119115016.GA2912@defiant.crash \
    --to=es186@fen-net.de \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.