mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Horton <pdh@berserk.demon.co.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Radeon frame buffer driver
Date: Wed, 10 Apr 2002 14:03:15 +0100	[thread overview]
Message-ID: <20020410130315.GA1372@berserk.demon.co.uk> (raw)
In-Reply-To: <20020410101913.GA975@berserk.demon.co.uk> <Pine.GSO.4.21.0204101305210.24941-100000@trillium.sonytel.be>

On Wed, Apr 10, 2002 at 01:06:09PM +0200, Geert Uytterhoeven wrote:
> On Wed, 10 Apr 2002, Peter Horton wrote:
> > 
> > The colour map is only used by the kernel and the kernel only uses 16
> > entries so there isn't any reason to waste memory by making it any
> > larger. I checked a few other drivers and they do the same (aty128fb for
> > one).
> 
> However, this change will make the driver not save/restore all color map
> entries on VC switch in graphics mode.
> 

Well I thought this didn't matter because if we only use 16 entries they
will all be saved / restored. But there is a problem because the copy of
the entire palette that we keep is per card and will be lost on VC
switch, though the kernel will restore the first 16 entries.  Really we
need to keep a copy of the relevant part of the palette for each display
(256 for 8bpp, 32 for 15 bit mode, 64 for 16bpp and 256 for 32bpp).
Looking at a handful of drivers this seems to be a common error, so it
can't be causing users much grief. I don't think changing the size of
the colour map fixes this though (I need to look at the code when I get
home).

On a side note would you take a patch that changed the cursor xor value
in fbcon-cfb16/24/32 to the correct value if the display is DIRECTCOLOR
rather than TRUECOLOR? We could then avoid having to set spurious
palette indices to make the soft cursor work. I note that fbcon-cfb8
does the right thing.

I think the correct xor values are

	depth 15	0x3DEF
	depth 16	0x79EF
	depth 24/32	0x000F0F0F

P.

  parent reply	other threads:[~2002-04-10 13:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-10  0:12 Peter Horton
2002-04-10  2:31 ` Jonathan A. Davis
2002-04-10  6:04 ` Ani Joshi
2002-04-10  9:06 ` benh
2002-04-10  9:40   ` Peter Horton
2002-04-10 10:57     ` benh
2002-04-10 10:19       ` Peter Horton
2002-04-10 11:06         ` Geert Uytterhoeven
2002-04-10 13:01           ` benh
2002-04-10 12:22             ` Geert Uytterhoeven
2002-04-10 13:27               ` benh
2002-04-10 13:03           ` Peter Horton [this message]
2002-04-10 13:14             ` Geert Uytterhoeven
2002-04-10 23:09           ` Peter Horton
2002-04-10 13:00         ` benh

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=20020410130315.GA1372@berserk.demon.co.uk \
    --to=pdh@berserk.demon.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®