Re: [PATCH] interlaced packed pixels

Re: [PATCH] interlaced packed pixels

[Alan Cox]

On Gwe, 2003-04-04 at 12:17, Geert Uytterhoeven wrote:
> 	Hi,
> 
> I'd like to introduce a new frame buffer type to accommodate packed pixel frame
> buffers that store the even and odd fields separately. This is typically used
> in graphics hardware for TV output (e.g. set-top boxes).

While we are at it can we also get an FB_TYPE_MJPEG ?



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] interlaced packed pixels

[Alan Cox]

On Gwe, 2003-04-04 at 12:17, Geert Uytterhoeven wrote:
> 	Hi,
> 
> I'd like to introduce a new frame buffer type to accommodate packed pixel frame
> buffers that store the even and odd fields separately. This is typically used
> in graphics hardware for TV output (e.g. set-top boxes).

While we are at it can we also get an FB_TYPE_MJPEG ?



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

[PATCH] interlaced packed pixels

[Geert Uytterhoeven]

	Hi,

I'd like to introduce a new frame buffer type to accommodate packed pixel frame
buffers that store the even and odd fields separately. This is typically used
in graphics hardware for TV output (e.g. set-top boxes).

--- linux-2.4.21-pre6/include/linux/fb.h.orig	Tue Apr 16 10:21:43 2002
+++ linux-2.4.21-pre6/include/fb.h	Fri Apr  4 13:14:19 2003
@@ -38,6 +38,7 @@
 #define FB_TYPE_INTERLEAVED_PLANES	2	/* Interleaved planes	*/
 #define FB_TYPE_TEXT			3	/* Text/attributes	*/
 #define FB_TYPE_VGA_PLANES		4	/* EGA/VGA planes	*/
+#define FB_TYPE_PACKED_PIXELS_LACED	5	/* Interlaced Packed Pixels */
 
 #define FB_AUX_TEXT_MDA		0	/* Monochrome text */
 #define FB_AUX_TEXT_CGA		1	/* CGA/EGA/VGA Color text */
@@ -115,6 +117,8 @@
 	__u32 smem_len;			/* Length of frame buffer mem */
 	__u32 type;			/* see FB_TYPE_*		*/
 	__u32 type_aux;			/* Interleave for interleaved Planes */
+					/* Offset to odd field for      */
+					/* interlaced packed pixels */
 	__u32 visual;			/* see FB_VISUAL_*		*/ 
 	__u16 xpanstep;			/* zero if no hardware panning  */
 	__u16 ypanstep;			/* zero if no hardware panning  */

The patch applies to both 2.4.x and 2.5.x.

Any comments?

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 is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] interlaced packed pixels

[Geert Uytterhoeven]

Op vrijdag 4 April 2003, schreef Alan Cox:
> On Gwe, 2003-04-04 at 12:17, Geert Uytterhoeven wrote:
     ^^^                                          ^^^^^
The Welsh setup isn't 100% finished yet ;-)

> > I'd like to introduce a new frame buffer type to accommodate packed pixel frame
> > buffers that store the even and odd fields separately. This is typically used
> > in graphics hardware for TV output (e.g. set-top boxes).
> 
> While we are at it can we also get an FB_TYPE_MJPEG ?

What's the exact format description for MJPEG? YUV 4:*:*?
Shouldn't that be a FB_VISUAL_MJPEG?

Groetjes,

						Geert

--
Geert Uytterhoeven -- Er is heel wat Linux na ia32 -- geert@linux-m68k.org

Tijdens persoonlijke conversaties met technisch-georiënteerde mensen noem ik
mezelf een hacker. Maar als ik met een journalist praat zeg ik gewoon
`programmeur' of iets in die aard.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] interlaced packed pixels

[Alan Cox]

On Gwe, 2003-04-04 at 13:22, Geert Uytterhoeven wrote:
> Op vrijdag 4 April 2003, schreef Alan Cox:
> > On Gwe, 2003-04-04 at 12:17, Geert Uytterhoeven wrote:
>      ^^^                                          ^^^^^
> The Welsh setup isn't 100% finished yet ;-)

Translations in progess still. Tackling evolution is a big job
that the translators haven't started yet

> What's the exact format description for MJPEG? YUV 4:*:*?
> Shouldn't that be a FB_VISUAL_MJPEG?

The frame buffer holds a jpeg frame. At the moment text mode
is problematic but doable (you encode each dct square the
same size for each charater and write in a carefully sized font 8))



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] interlaced packed pixels

[Russell King]

On Fri, Apr 04, 2003 at 01:17:15PM +0200, Geert Uytterhoeven wrote:
> I'd like to introduce a new frame buffer type to accommodate packed pixel frame
> buffers that store the even and odd fields separately. This is typically used
> in graphics hardware for TV output (e.g. set-top boxes).

While we're on the subject of framebuffers, one area which needs to be
looked into is the pixel layout for all of:

- little endian byte, little endian pixel
	1bpp: word 0 bit 31..0 = pixel 31..0)
	16bpp: word 0 bit 31..0 = pixel1 bits 15..0 pixel0 bits 15..0) 
- little endian byte, big endian pixel
	1bpp: word 0 bit 31..0 = pixel 24..31, 16..23, 8..15, 0..7)
	16bpp: word 0 bit 31..0 = pixel1 bits 15..0 pixel0 bits 15..0) 
- big endian byte, big endian pixel
	1bpp: word 0 bit 31..0 = pixel 0..31)
	16bpp: word 0 bit 31..0 = pixel0 bits 15..0 pixel1 bits 15..0) 

We currently do not support all these combinations, and so far I haven't
looked into it.  It is on my (great long) to do list.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] interlaced packed pixels

[Geert Uytterhoeven]

On Fri, 4 Apr 2003, Russell King wrote:
> On Fri, Apr 04, 2003 at 01:17:15PM +0200, Geert Uytterhoeven wrote:
> > I'd like to introduce a new frame buffer type to accommodate packed pixel frame
> > buffers that store the even and odd fields separately. This is typically used
> > in graphics hardware for TV output (e.g. set-top boxes).
> 
> While we're on the subject of framebuffers, one area which needs to be
> looked into is the pixel layout for all of:
> 
> - little endian byte, little endian pixel
> 	1bpp: word 0 bit 31..0 = pixel 31..0)
> 	16bpp: word 0 bit 31..0 = pixel1 bits 15..0 pixel0 bits 15..0) 
> - little endian byte, big endian pixel
> 	1bpp: word 0 bit 31..0 = pixel 24..31, 16..23, 8..15, 0..7)
> 	16bpp: word 0 bit 31..0 = pixel1 bits 15..0 pixel0 bits 15..0) 
> - big endian byte, big endian pixel
> 	1bpp: word 0 bit 31..0 = pixel 0..31)
> 	16bpp: word 0 bit 31..0 = pixel0 bits 15..0 pixel1 bits 15..0) 
> 
> We currently do not support all these combinations, and so far I haven't
> looked into it.  It is on my (great long) to do list.

Yes, this is still a (hard) problem.

BTW, more combinations are possible. E.g. swapped bytes in 16-bit words or
swapped 16-bit words in 32-bit words, due to hardware swapping of data bus
lines. And things get really fishy on such a system for 24-bit wide pixels.

The order within a pixel can already be specified using fb_bitfield.msb_right.
But how pixels are laid out in the frame buffer is a different thing.

I thought
about adding the following FB_TYPE_* flags a few years ago, but I'm not sure
they'll allow us to handle all cases:

  - FB_TYPE_SWAP_8_IN_16: individual bytes within a 16-bit word are swapped
  - FB_TYPE_SWAP_16_IN_32: individual 16-bit words within a 32-bit word are
    swapped
  - FB_TYPE_SWAP_32_IN_64: individual 32-bit words within a 64-bit word are
    swapped

These are supposed to be OR'ed with the current FB_TYPE_* definitions, e.g.
FB_TYPE_SWAP_32_IN_64 | FB_TYPE_SWAP_16_IN_32 | FB_TYPE_SWAP_8_IN_16 |
FB_TYPE_PACKED_PIXELS would indicate a completely swapped video bus.


An alternative solution moves more processing into the kernel. Since the actual
fbdev driver knows about all this (it has to provide fb_ops), it can provide
the following operations to userspace:
  - fillrect()
  - copyrect()
  - put_image()
  - get_image()
This would allow a user space application to perform all simple drawing
operations without having to care at all about the actual frame buffer layout.

For more complex operations, these can be performed by the application on a
shadow frame buffer in a simple packed format, while letting the kernel take
care of the actual drawing, including necessary chunky-to-planar conversions
and bit mangling.

For performance reasons, the driver should report optimal positional and size
alignments for {put,get}_image().

What do you think?

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 is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/