Re: HP300 support checked in

5 messages, 2 authors, 2004-07-14 · open the first message on its own page

Re: HP300 support checked in

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-07-13 08:08:28

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 16:24:28 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--

--i6CEOWXJ026457.1089642272/witte.sonytel.be--
ReSent-Date: Tue, 13 Jul 2004 10:08:20 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 16:24:28 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--

--i6CEOWXJ026457.1089642272/witte.sonytel.be--


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: HP300 support checked in

From: Antonino A. Daplas <hidden>
Date: 2004-07-14 07:32:57

On Monday 12 July 2004 15:25, Geert Uytterhoeven wrote:
On Sun, 11 Jul 2004, Kars de Jong wrote:
quoted
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).
Or we can use the fields in var->green, var->red, var->blue, ie,  to describe a 4-color
8-bit chunky framebuffer:

var->red.length = 2;
var->red.offset = 0;
var->green = var->blue = var->red.
var->bits_per_pixel = 8;

We still need to fix fbcon to handle this type of framebuffers, since fbcon always assumes
a packed pixel format.  For instance, we have this kind of code in fbcon.c

vc->vc_can_do_color = (var->bits_per_pixel != 1) ? 1 : 0;

which is incorrect in this case. Better if we test fix->visual instead.

I'll see if I can create a test patch for this. 

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: HP300 support checked in

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-07-14 08:00:51

On Wed, 14 Jul 2004, Antonino A. Daplas wrote:
On Monday 12 July 2004 15:25, Geert Uytterhoeven wrote:
quoted
On Sun, 11 Jul 2004, Kars de Jong wrote:
quoted
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
quoted
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).
Or we can use the fields in var->green, var->red, var->blue, ie,  to describe a 4-color
8-bit chunky framebuffer:

var->red.length = 2;
var->red.offset = 0;
var->green = var->blue = var->red.
var->bits_per_pixel = 8;
This breaks something different, since for pseudocolor visuals, the *.lengths
indicate the sizes of the CLUT entries (e.g. 8 bit per component for modern
24-bit color, 6 bit for VGA-style 18-bit color).
We still need to fix fbcon to handle this type of framebuffers, since fbcon always assumes
a packed pixel format.  For instance, we have this kind of code in fbcon.c

vc->vc_can_do_color = (var->bits_per_pixel != 1) ? 1 : 0;

which is incorrect in this case. Better if we test fix->visual instead.
Yep, that one should test the visual. And in this case greyscale count as color
as well...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: HP300 support checked in

From: Antonino A. Daplas <hidden>
Date: 2004-07-14 08:38:55

On Wednesday 14 July 2004 16:00, Geert Uytterhoeven wrote:
On Wed, 14 Jul 2004, Antonino A. Daplas wrote:
quoted
On Monday 12 July 2004 15:25, Geert Uytterhoeven wrote:
quoted
On Sun, 11 Jul 2004, Kars de Jong wrote:
quoted
Support for <8 bit framebuffers is probably broken. I don't know how
I'm going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers,
but the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4
(16 colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).
Or we can use the fields in var->green, var->red, var->blue, ie,  to
describe a 4-color 8-bit chunky framebuffer:

var->red.length = 2;
var->red.offset = 0;
var->green = var->blue = var->red.
var->bits_per_pixel = 8;
This breaks something different, since for pseudocolor visuals, the
*.lengths indicate the sizes of the CLUT entries (e.g. 8 bit per component
for modern 24-bit color, 6 bit for VGA-style 18-bit color).
I don't know.  For pseudocolor, color depth == CLUT size.  So if we check if all
lengths are equal and if all offsets are equal to zero, then color depth = CLUT size. 
Otherwise, color depth = red.length + green.length + blue.length. Transparency 
can be ignored for now.
  
Tony





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: HP300 support checked in

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-07-14 09:05:27

On Wed, 14 Jul 2004, Antonino A. Daplas wrote:
On Wednesday 14 July 2004 16:00, Geert Uytterhoeven wrote:
quoted
On Wed, 14 Jul 2004, Antonino A. Daplas wrote:
quoted
Or we can use the fields in var->green, var->red, var->blue, ie,  to
describe a 4-color 8-bit chunky framebuffer:

var->red.length = 2;
var->red.offset = 0;
var->green = var->blue = var->red.
var->bits_per_pixel = 8;
This breaks something different, since for pseudocolor visuals, the
*.lengths indicate the sizes of the CLUT entries (e.g. 8 bit per component
for modern 24-bit color, 6 bit for VGA-style 18-bit color).
I don't know.  For pseudocolor, color depth == CLUT size.  So if we check if all
lengths are equal and if all offsets are equal to zero, then color depth = CLUT size.
Otherwise, color depth = red.length + green.length + blue.length. Transparency
can be ignored for now.
Forget what I said. I was a bit confused, mixing code from many years ago in my
head...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help