From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org,
Pekka Enberg <penberg@cs.helsinki.fi>,
Tero Roponen <teanropo@jyu.fi>, Andy Whitcroft <apw@shadowen.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: tty-related oops in latest kernel(s)?
Date: Thu, 31 May 2007 17:04:38 +0800 [thread overview]
Message-ID: <1180602278.4570.42.camel@daplas> (raw)
In-Reply-To: <Pine.LNX.4.64.0705310916240.17047@anakin>
On Thu, 2007-05-31 at 09:17 +0200, Geert Uytterhoeven wrote:
> On Thu, 31 May 2007, Antonino A. Daplas wrote:
> > On Wed, 2007-05-30 at 22:04 +0400, Alexey Dobriyan wrote:
> > > 2) palette in neofb_par is "u32 palette[16];" which is 4x16 = 64 bytes.
> > > struct fb_info::pseudo_palette is assigned to it in neo_alloc_fb_info().
> > > Yet, we check at the beginning of neofb_setcolreg() for color map
> > > length which neofb advertises as 256 which seems too many.
> > >
> >
> > Yes, 256 is too many. the pseudo_palette is used for the 16-color
> > console only.
> >
> > I'm impressed that this bug has escaped notice for this long. That bug
> > is present since the 2.5.x era.
> >
> > Probably, the best thing to do is hide the pseudo_palette from the
> > drivers and move it to the console layer where it belongs to spare
> > future driver writers from palette usage confusion. That will be a
> > thankless job.
>
> The console layer doesn't know how to fill in the pseudo palette in all
> cases, that's why the driver have to do it.
>
I have actually started working on that. It involves breaking down
fb_setcolreg() so it deals only with writing to the actual hardware
registers. The part of fb_setcolreg() that adds entries to the
pseudo_palette can be separated as a new method, fb_get_pixel(), which
given red, blue, green, transp, the driver returns a u32 pixel value
that can be written to the pseudo_palette.
So fbcon can hold a copy of the pseudo_palette and fills it up by
calling info->fbops->fb_get_pixel() successively.
This will touch the logo code, the drawing libraries, each driver, etc
so it's a lot of work. During the conversion period, we support having
info->pseudo_palette and fbcon->pseudo_palette at the same time. Once
all drivers are converted, we can remove info->pseudo_palette.
One use for having an fb_get_pixel() method is we can use this as an
rgb888-image-to-raw-framebuffer-format converter.
Currently, I have only converted vesafb. Once the core code is done,
I'll start converting the rest of the drivers one by one.
Tony
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
WARNING: multiple messages have this Message-ID (diff)
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org,
Pekka Enberg <penberg@cs.helsinki.fi>,
Tero Roponen <teanropo@jyu.fi>, Andy Whitcroft <apw@shadowen.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [Linux-fbdev-devel] tty-related oops in latest kernel(s)?
Date: Thu, 31 May 2007 17:04:38 +0800 [thread overview]
Message-ID: <1180602278.4570.42.camel@daplas> (raw)
In-Reply-To: <Pine.LNX.4.64.0705310916240.17047@anakin>
On Thu, 2007-05-31 at 09:17 +0200, Geert Uytterhoeven wrote:
> On Thu, 31 May 2007, Antonino A. Daplas wrote:
> > On Wed, 2007-05-30 at 22:04 +0400, Alexey Dobriyan wrote:
> > > 2) palette in neofb_par is "u32 palette[16];" which is 4x16 = 64 bytes.
> > > struct fb_info::pseudo_palette is assigned to it in neo_alloc_fb_info().
> > > Yet, we check at the beginning of neofb_setcolreg() for color map
> > > length which neofb advertises as 256 which seems too many.
> > >
> >
> > Yes, 256 is too many. the pseudo_palette is used for the 16-color
> > console only.
> >
> > I'm impressed that this bug has escaped notice for this long. That bug
> > is present since the 2.5.x era.
> >
> > Probably, the best thing to do is hide the pseudo_palette from the
> > drivers and move it to the console layer where it belongs to spare
> > future driver writers from palette usage confusion. That will be a
> > thankless job.
>
> The console layer doesn't know how to fill in the pseudo palette in all
> cases, that's why the driver have to do it.
>
I have actually started working on that. It involves breaking down
fb_setcolreg() so it deals only with writing to the actual hardware
registers. The part of fb_setcolreg() that adds entries to the
pseudo_palette can be separated as a new method, fb_get_pixel(), which
given red, blue, green, transp, the driver returns a u32 pixel value
that can be written to the pseudo_palette.
So fbcon can hold a copy of the pseudo_palette and fills it up by
calling info->fbops->fb_get_pixel() successively.
This will touch the logo code, the drawing libraries, each driver, etc
so it's a lot of work. During the conversion period, we support having
info->pseudo_palette and fbcon->pseudo_palette at the same time. Once
all drivers are converted, we can remove info->pseudo_palette.
One use for having an fb_get_pixel() method is we can use this as an
rgb888-image-to-raw-framebuffer-format converter.
Currently, I have only converted vesafb. Once the core code is done,
I'll start converting the rest of the drivers one by one.
Tony
next prev parent reply other threads:[~2007-05-31 9:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-27 9:06 tty-related oops in latest kernel(s)? Tero Roponen
2007-05-28 7:22 ` Pekka Enberg
2007-05-28 7:47 ` Pekka Enberg
2007-05-28 8:08 ` Tero Roponen
2007-05-28 9:34 ` Pekka Enberg
2007-05-29 16:04 ` Tero Roponen
2007-05-29 18:57 ` Pekka Enberg
2007-05-30 3:43 ` Tero Roponen
2007-05-30 3:57 ` Tero Roponen
2007-05-30 5:54 ` Pekka Enberg
2007-05-30 5:59 ` Pekka Enberg
2007-05-30 6:00 ` Tero Roponen
2007-05-30 12:02 ` Tero Roponen
2007-05-30 15:39 ` Andrew Morton
2007-05-30 16:01 ` Tero Roponen
2007-05-30 16:09 ` Andrew Morton
2007-05-30 18:04 ` Alexey Dobriyan
2007-05-30 23:14 ` Antonino A. Daplas
2007-05-30 23:14 ` Antonino A. Daplas
2007-05-30 23:18 ` David Miller
2007-05-30 23:18 ` David Miller
2007-05-30 23:28 ` Antonino A. Daplas
2007-05-30 23:28 ` Antonino A. Daplas
2007-05-31 7:17 ` Geert Uytterhoeven
2007-05-31 7:17 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2007-05-31 9:04 ` Antonino A. Daplas [this message]
2007-05-31 9:04 ` Antonino A. Daplas
2007-05-30 18:13 ` Pekka Enberg
2007-05-30 18:27 ` Tero Roponen
2007-05-30 22:14 ` Antonino A. Daplas
2007-05-30 23:17 ` Antonino A. Daplas
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=1180602278.4570.42.camel@daplas \
--to=adaplas@gmail.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=apw@shadowen.org \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=teanropo@jyu.fi \
/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.