Very Computer

        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

 #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 */

        __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

--

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:>    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 ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:>    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 ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Op vrijdag 4 April 2003, schreef Alan Cox:
     ^^^                                          ^^^^^
The Welsh setup isn't 100% finished yet ;-)

Quote:> > 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

--

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

Quote:> 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))

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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.

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

--

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/