Menu
▾
▴
linux-fbdev-devel
|
From: Geert U. <ge...@li...> - 2001-07-03 08:18:28
|
---------- Forwarded message ----------
Date: Tue, 3 Jul 2001 17:43:20 +1000
From: Christopher Yeoh <cy...@sa...>
To: Geert Uytterhoeven <ge...@li...>
Cc: lin...@vg...
Subject: [PATCH] more penguins
Hi,
Here's a patch against 2.4.5 so we can display a decent number of
penguins at boot time (wraps the display of the boot penguins when
they can't all fit on one line).
Chris.
--
ye...@au...
IBM OzLabs Linux Development Group
Canberra, Australia
diff -urN linux-2.4.5/drivers/video/fbcon.c linux-2.4.5-logo/drivers/video/fbcon.c
--- linux-2.4.5/drivers/video/fbcon.c Thu Feb 22 14:25:28 2001
+++ linux-2.4.5-logo/drivers/video/fbcon.c Sun Jul 1 17:10:27 2001
@@ -608,8 +608,16 @@
/* Need to make room for the logo */
int cnt;
int step;
-
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ int logo_rows;
+
+ /* Work out how many rows of logos will be displayed.
+ Leave at least two rows worth of logos at bottom to
+ display boot information */
+ logo_rows = (smp_num_cpus - 1) / (p->var.xres/(LOGO_W+8)) + 1;
+ if ((int)p->var.yres - logo_rows * (LOGO_H+8) < LOGO_H*2)
+ logo_rows = (p->var.yres - LOGO_H*2) / (LOGO_H+8);
+
+ logo_lines = ((LOGO_H+8)*logo_rows + fontheight(p) - 9) / fontheight(p);
q = (unsigned short *)(conp->vc_origin + conp->vc_size_row * old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r < q; r++)
@@ -2055,6 +2063,7 @@
unsigned char *dst, *src;
int i, j, n, x1, y1, x;
int logo_depth, done = 0;
+ int yoff = 0, logo_count = 0;
/* Return if the frame buffer is not mapped */
if (!fb)
@@ -2115,8 +2124,8 @@
if (p->fb_info->fbops->fb_rasterimg)
p->fb_info->fbops->fb_rasterimg(p->fb_info, 1);
- for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
- x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
+ x = 0;
+ while (logo_count < smp_num_cpus && yoff < p->var.yres - (LOGO_H*3)) {
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
@@ -2134,7 +2143,7 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = (*src << redshift) |
@@ -2160,7 +2169,7 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W/2; x1++, src++ ) {
pix = (*src >> 4) | 0x10; /* upper nibble */
@@ -2208,7 +2217,7 @@
blueshift = p->var.blue.offset - (8-p->var.blue.length);
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = safe_shift((linux_logo_red[*src-32] & redmask), redshift) |
@@ -2234,7 +2243,7 @@
#if defined(CONFIG_FBCON_CFB4)
if (depth == 4 && p->type == FB_TYPE_PACKED_PIXELS) {
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++) {
dst = fb + y1*line + x/2;
for( x1 = 0; x1 < LOGO_W/2; x1++) {
u8 q = *src++;
@@ -2250,7 +2259,7 @@
/* depth 8 or more, packed, with color registers */
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
dst = fb + y1*line + x;
for( x1 = 0; x1 < LOGO_W; x1++ )
fb_writeb (*src++, dst++);
@@ -2282,7 +2291,7 @@
(1 << ((8-((pix*logo_depth)&7)-logo_depth) + bit)))
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
for( x1 = 0; x1 < LOGO_LINE; x1++, src += logo_depth ) {
dst = fb + y1*line + MAP_X(x/8+x1);
for( bit = 0; bit < logo_depth; bit++ ) {
@@ -2301,7 +2310,7 @@
* special case for logo_depth == 4: we used color registers 16..31,
* so fill plane 4 with 1 bits instead of 0 */
if (depth > logo_depth) {
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
for( x1 = 0; x1 < LOGO_LINE; x1++ ) {
dst = fb + y1*line + MAP_X(x/8+x1) + logo_depth*plane;
for( i = logo_depth; i < depth; i++, dst += plane )
@@ -2327,7 +2336,7 @@
int is_hga = !strncmp(p->fb_info->modename, "HGA", 3);
/* can't use simply memcpy because need to apply inverse */
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
src = logo + y1*LOGO_LINE;
if (is_hga)
dst = fb + (y1%4)*8192 + (y1>>2)*line + x/8;
@@ -2346,7 +2355,7 @@
outb_p(5,0x3ce); outb_p(0,0x3cf);
src = logo;
- for (y1 = 0; y1 < LOGO_H; y1++) {
+ for (y1 = yoff; y1 < yoff + LOGO_H; y1++) {
for (x1 = 0; x1 < LOGO_W / 2; x1++) {
dst = fb + y1*line + x1/4 + x/8;
@@ -2370,6 +2379,12 @@
done = 1;
}
#endif
+ logo_count++;
+ x += LOGO_W + 8;
+ if (x >= p->var.xres - (LOGO_W + 8)) {
+ yoff += LOGO_H + 8;
+ x = 0;
+ }
}
if (p->fb_info->fbops->fb_rasterimg)
|
|
From: Romain D. <do...@ir...> - 2001-07-03 14:27:09
|
Geert Uytterhoeven wrote: > Here's a patch against 2.4.5 so we can display a decent number of > penguins at boot time (wraps the display of the boot penguins when > they can't all fit on one line). Apparently there's some interest in marginaly useful feature like displaying penguin. I was wondering if there could be an interest in even less useful feature like overlay support. Like a full-color, full screen penguin under your text console. Such a feature isn't hard to hack: I have a hacked pm3fb that only change a handful of lines. The hardware is set up as 32bpp, with the upper 8 of each u32 being used for the ColorIndexed value used at the console level. pm3fb is fully accelerated, so it's only adding the hardware planemask. The other 24 bpp are full-color RGB used when the CI color is 0 (background color), and are never touched by the console subsytem. Any image put in these will appear as a underlay :-) Given that software like fbi are usually broken and assume 32bpp is RGB8888, they can be directly used to put the underlay... I don't think it's really something to be made standard part of the API, but other might disagree :-) The second (much less trivial, not yet implemented, and much more useful) is to use the video capability of the hardware ; the Permedia3 can overlay video (including blending) on the framebuffer. This could be used for still background picture, or for video overlay (fbtv from the xawtv package could benefit from hardware YUV->RGB conversion...) Any comments ? -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-07-03 17:17:53
|
> Apparently there's some interest in marginaly useful feature like
> displaying penguin. I was wondering if there could be an interest
> in even less useful feature like overlay support. Like a full-color,
> full screen penguin under your text console.
Something like this can also be done for vgacon. I haven't added that yet.
> The second (much less trivial, not yet implemented, and much
> more useful) is to use the video capability of the hardware ;
> the Permedia3 can overlay video (including blending) on the
> framebuffer. This could be used for still background picture,
> or for video overlay (fbtv from the xawtv package could
> benefit from hardware YUV->RGB conversion...)
This would be really nice. We had this discussion some time ago but
nothing was resolved. Basically we have to develope a way to define what
composes the framebuffer in a generic way. Something like fb_bitfields
plus a flag to say what it is. This would break things tho. I guess it
will be for the fb filesystem for 2.5.X.
|
|
From: <dol...@cl...> - 2001-07-03 17:32:30
|
> > Apparently there's some interest in marginaly useful feature like > > displaying penguin. I was wondering if there could be an interest in > > even less useful feature like overlay support. Like a full-color, full > > screen penguin under your text console. > > Something like this can also be done for vgacon. I haven't added that yet. vgacon can do overlay ??? The advantage of the hardware overlay is that there's zero system overhead ; only the actual drawing function _might_ be slower depending on the hardware. And you only eat up FB memory. > This would be really nice. We had this discussion some time ago but > nothing was resolved. Basically we have to develope a way to define what > composes the framebuffer in a generic way. Something like fb_bitfields > plus a flag to say what it is. This would break things tho. I guess it > will be for the fb filesystem for 2.5.X. Maybe we should involve the author of fbtv, he could tell us the kind of stuff that would be needed for efficient hardware YUV->RGB and/or zooming in fbtv. I guess other app would have similar requirements. -- Romain DOLBEAU | For a hill, men would kill, ENS Cachan / Ker Lann | Why ? They do not know. Thesard IRISA / CAPS | -- Metallica dol...@cl... | in 'For Whom The Bell Tolls' |
|
From: James S. <jsi...@tr...> - 2001-07-03 19:59:20
|
> > Something like this can also be done for vgacon. I haven't added that yet. > > vgacon can do overlay ??? Not really. It is a trick you do with planes and the attribute fields in text mode. > > plus a flag to say what it is. This would break things tho. I guess it > > will be for the fb filesystem for 2.5.X. > > Maybe we should involve the author of fbtv, he could tell us the kind of > stuff that would be needed for efficient hardware YUV->RGB and/or > zooming in fbtv. I guess other app would have similar requirements. Good idea. |
|
From: Romain D. <do...@ir...> - 2001-07-10 14:29:05
|
James Simmons wrote: > > Romain Dolbeau wrote: > > > > Maybe we should involve the author of fbtv, he could tell us the kind of > > stuff that would be needed for efficient hardware YUV->RGB and/or > > zooming in fbtv. I guess other app would have similar requirements. > > Good idea. It's done. Hello Mr. Knorr :-) The idea would be to add (video?) overlay support to the fbdev layer. That could be used for adding a background picture (full-size color penguin :-) or more seriously for video app like `fbtv'. I believe the interface, being in the kernel, should be kept simple even if not complete. The HW driver could supply for instance the base address of the offscreen memory area where data (RGB or YUV, depending on available hardware) can be put and the capability (shrink/expand, opaque or translucent/blended overlay...), and the app could ask to overlay said memory area to a specific offset in the FB area. Such a model would be simple (2 ioctls) and be within reach of many chip with vid-overlay capability (it would work on the Permedia3 I believe :-) Would that be enough for fbtv (and similar app) ? would that be useful ? (assuming HW YUV->RGB conversion is available) No point in adding cruft that would slow things down :-) Is there anything else that would help `fbtv' ? Could such an interface be added to ruby or should we wait after ruby is integrated in 2.5.x ? Any comments welcome. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Gerd K. <kr...@by...> - 2001-07-11 12:10:44
|
> It's done. Hello Mr. Knorr :-)
>
> The idea would be to add (video?) overlay support to the fbdev
> layer. [ ... ]
> Would that be enough for fbtv (and similar app) ? would
> that be useful ?
fbtv does not need very much: just some piece of memory where it can ask
the bt848 to dma stuff to, and some way to enable the overlay for that.
You can have a look at the code, it already can do that on matrox cards
(by mmaping the mmio area and programming the hardware itself), see
matrox.c.
When adding such ioctls to the kernel fbdev drivers I'd try to avoid
limiting it to one overlay, which in turn means that just two ioctls are
not enougth. IMHO it should look like this:
(1) A ioctl to allocate a piece of offscreen memory for overlay
(with size foo and format bar).
(2) A ioctl to ask the driver to start overlay at x,y,w,h.
(3) A ioctl to stop overlay
(4) A ioctl to free the memory.
There also should be some way to figure out the supported formats.
Either a fixed list of formats and ioctl (1) returning -EINVAL for
unsupported ones or yet another ioctl to list the available ones. It
needs to be clear what happens on console switches. Some way to set
the chroma key color would be useful too (maybe in ioctl (2) ?).
> Could such an interface be added to ruby or should we wait
> after ruby is integrated in 2.5.x ?
BTW: What is ruby?
Gerd
--
Damn lot people confuse usability and eye-candy.
|
|
From: Geert U. <ge...@li...> - 2001-07-11 12:28:36
|
On Wed, 11 Jul 2001, Gerd Knorr wrote:
> When adding such ioctls to the kernel fbdev drivers I'd try to avoid
> limiting it to one overlay, which in turn means that just two ioctls are
> not enougth. IMHO it should look like this:
>
> (1) A ioctl to allocate a piece of offscreen memory for overlay
> (with size foo and format bar).
Can be used for allocating a Z-buffer, too.
> (2) A ioctl to ask the driver to start overlay at x,y,w,h.
And scaling hs, vs.
> (3) A ioctl to stop overlay
> (4) A ioctl to free the memory.
>
> There also should be some way to figure out the supported formats.
> Either a fixed list of formats and ioctl (1) returning -EINVAL for
> unsupported ones or yet another ioctl to list the available ones. It
You can have lots of formats:
- YUV 4:4:4
- YUV 4:2:2
- YUV 4:2:0
Not to mention separation of even/odd scanlines and luminance/chrominance on
some chipsets.
> needs to be clear what happens on console switches. Some way to set
> the chroma key color would be useful too (maybe in ioctl (2) ?).
Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Romain D. <do...@ir...> - 2001-07-11 13:19:27
|
Geert Uytterhoeven wrote:
> Not to mention separation of even/odd scanlines and luminance/chrominance on
> some chipsets.
>
> Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.
Could you elaborate on those 2 ? I haven't seen that yet (not
surprising,
I'm for from an expert on the subject :-)
TIA
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: Geert U. <ge...@li...> - 2001-07-11 13:42:19
|
On Wed, 11 Jul 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > Not to mention separation of even/odd scanlines and luminance/chrominance on
> > some chipsets.
On some chipsets you have not one buffer containing all pixel data, but two
buffers: one for the even scanlines, and one for the odd scanlines.
It's also possible that the luminance and chrominance data are separated.
For YUV 4:2:2 (i.e. one Y value for each pixel, but only one U and one V for
each two pixels: YUYV), that means
- one buffer for the Y data for the even scanlines
- one buffer for the Y data for the odd scanlines
- one buffer for the UV data for the even scanlines
- one buffer for the UV data for the odd scanlines
I don't know whether this is done in any PC chipset, but it happens in chipsets
for set-top boxes.
> > Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.
>
> Could you elaborate on those 2 ? I haven't seen that yet (not
> surprising,
> I'm for from an expert on the subject :-)
pixel_is_transparent if (Ymin <= Y <= Ymax) && (Umin <= U <= Umax) &&
(Vmin <= V <= Vmax)
compare this to the single chroma key value:
pixel_is_transparent if Y == Ykey && U == Ukey && V == Vkey
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Romain D. <do...@ir...> - 2001-07-11 13:04:08
Attachments:
fbvid.h
|
Gerd Knorr wrote: > When adding such ioctls to the kernel fbdev drivers I'd try to avoid > limiting it to one overlay, which in turn means that just two ioctls are > not enougth. IMHO it should look like this: > > (1) A ioctl to allocate a piece of offscreen memory for overlay > (with size foo and format bar). > (2) A ioctl to ask the driver to start overlay at x,y,w,h. > (3) A ioctl to stop overlay > (4) A ioctl to free the memory. I've reworked my current draft proposal for 2.4.x, appended below. Heavily based on what's available in the Permedia3. Any add-on (particulary data type) and comments welcome. > BTW: What is ruby? The reworked console layer for 2.5.x. <http://sourceforge.net/projects/linuxconsole/> -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Gerd K. <kr...@by...> - 2001-07-11 14:10:27
|
> /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */
> #define FBIOGET_VIDOVERLAY_CAP 0x4620
Better use the _IOR / _IOW / _IOWR macros.
> /* pixel type that can be overlaid */
> #define FB_VIDOVERLAY_PIXELTYPE_CI8 0x0020
What is this one?
> #define FB_VIDOVERLAY_PIXELTYPE_YUV422 0x0040
> #define FB_VIDOVERLAY_PIXELTYPE_YUV444 0x0080
packed pixel or planar? yuv420 should be there too, mpeg decompressed
gives you planar yuv420.
> struct fb_vidoverlay_mem {
> unsigned long omem_start; /* Start of overlay frame buffer mem (phys add) */
> __u32 omem_len; /* (required) length of overlay frame buffer mem */
> __u8 n_over; /* number of the overlay buffer to use */
> };
I'd pass pixeltype + width + height here and let the driver calculate +
return the image size and scanline length. The driver can easily take
care about alignment and related issues then.
n_over == -1 => "give me any free one" ?
> struct fb_vidoverlay_set {
> __u32 oxsize; /* overlay size in pixels */
> __u32 oysize;
> __u16 pixel_type; /* pixeltype to use */
obviously not needed if every allocated memory area has a width and height
as suggested above.
> __u16 blend_factor; /* blending factor */
add chroma key (rage) here ?
Gerd
--
Damn lot people confuse usability and eye-candy.
|
|
From: Romain D. <do...@ir...> - 2001-07-11 14:35:19
|
Gerd Knorr wrote: > Better use the _IOR / _IOW / _IOWR macros. ATM FB doesn't use them, so I picked up a bunch of value in sequence. > > #define FB_VIDOVERLAY_PIXELTYPE_CI8 0x0020 > > What is this one? ColorIndexed 8bpp. Could be used for still overlay (i.e. a big Penguin as background picture :-) > > #define FB_VIDOVERLAY_PIXELTYPE_YUV422 0x0040 > > #define FB_VIDOVERLAY_PIXELTYPE_YUV444 0x0080 > > packed pixel or planar? yuv420 should be there too, mpeg decompressed > gives you planar yuv420. Packed Pixel was in my mind. I'll add the other. (the pm3 doesn't have YUV420 :-( ) > I'd pass pixeltype + width + height here and let the driver calculate + > return the image size and scanline length. The driver can easily take > care about alignment and related issues then. The idea was the App could allow an arbitrary buffer and do whatever it pleases in it, including somthing entirely different from overlay. It might be useful if one add a in-FB-memory copy IOCTL or API. Also I though that the only overlay-related info would be put in FBIOPUT_VIDOVERLAY_START, and never stored in the driver (except for buffer data), only in the app. > n_over == -1 => "give me any free one" ? good idea. > > __u16 blend_factor; /* blending factor */ > > add chroma key (rage) here ? The problem is, how to handle the mix between the overlay and the console layer. If the FB doesn't have an alpha channel (CI8, RGB565), one must use a color key. So one must be able to know which color this is for FBCON. If there _is_ an alpha channel and we wish to use it, we must define how to handle the alpha in the fbcon layer: if it is cleared or not when clearing the screen, what happen when FBCON draw a character (cleared, set, set only on the background...) ans so on. So I simply dodged the problem by saying, we display the overlay in its area blended (0 to 100%) with the current display. But we need a better way, obviously. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Gerd K. <kr...@by...> - 2001-07-11 15:20:27
|
On Wed, Jul 11, 2001 at 04:35:07PM +0200, Romain Dolbeau wrote: > Gerd Knorr wrote: > > > Better use the _IOR / _IOW / _IOWR macros. > > ATM FB doesn't use them, so I picked up a bunch of value > in sequence. That's IMHO no excuse. The old ones can't be changed without breaking compatibility of course, but for new ones it should be done the RightWay[tm]. > Packed Pixel was in my mind. I'll add the other. > (the pm3 doesn't have YUV420 :-( ) And please add some comments saying which is planar/packed. > > I'd pass pixeltype + width + height here and let the driver calculate + > > return the image size and scanline length. The driver can easily take > > care about alignment and related issues then. > > The idea was the App could allow an arbitrary buffer and > do whatever it pleases in it, including somthing entirely > different from overlay. It might be useful if one > add a in-FB-memory copy IOCTL or API. There still would be image data in the buffer, and the image has some width / height. Even if you are going to use that image buffer for something else than overlay (texture, bitblit or whatever). > Also I though that the only overlay-related info > would be put in FBIOPUT_VIDOVERLAY_START, and > never stored in the driver (except for buffer > data), only in the app. IMHO it is important to let the driver pick the buffer size to avoid trouble due to hardware limitations / alignment issues / ... which the application doesn't know about. > > > __u16 blend_factor; /* blending factor */ > > > > add chroma key (rage) here ? > > The problem is, how to handle the mix between the overlay > and the console layer. Hmm, is this _really_ a problem? Do you want to mix that with console? I'd expect graphic applications whould use that only, like fbtv, dvd players (there is a fb-based one IIRC), ... Gerd -- Damn lot people confuse usability and eye-candy. |
|
From: Romain D. <do...@ir...> - 2001-07-11 15:40:15
|
Gerd Knorr wrote: > That's IMHO no excuse. The old ones can't be changed without breaking > compatibility of course, but for new ones it should be done the > RightWay[tm]. You're right, but then you need to know what prefix you can use. I asked for pm3fb and got no response. I don't know what to use for adding IOCTL to generic FB stuff... And as long as it's a draft it's easy to change :-) > And please add some comments saying which is planar/packed. will do. > There still would be image data in the buffer, and the image has some > width / height. Even if you are going to use that image buffer for > something else than overlay (texture, bitblit or whatever). > > IMHO it is important to let the driver pick the buffer size to avoid > trouble due to hardware limitations / alignment issues / ... > which the application doesn't know about. My current idea was the app was told about alignement issue in _CAP, and could require the size it needs by computing (pixelsize*paddedX*paddedY), and require that size or more. The driver return the base adress of the buffer (or 0 for failure) and the actual size of the buffer (>= required or 0 for failure). Also, it returns the number of the buffer if it was (-1) as you suggested. I agree the driver can do the size computing by itself, but I still thinks it's better to keep the actual data size in the _START call to allow for larger-than- image buffer. > Hmm, is this _really_ a problem? Do you want to mix that with > console? I'd expect graphic applications whould use that only, > like fbtv, dvd players (there is a fb-based one IIRC), ... Yes, if you want to be able to use the text console while displaying stuff like video or a still image. One could use `fbi' (:-) to display a background picture or `fbtv' for background movie/video stream. It's an overlay, it should behave nicely toward the foreground app, even fbcon. IMHO :-) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Gerd K. <kr...@by...> - 2001-07-12 07:15:27
|
> > IMHO it is important to let the driver pick the buffer size to avoid > > trouble due to hardware limitations / alignment issues / ... > > which the application doesn't know about. > > My current idea was the app was told about alignement issue > in _CAP, and could require the size it needs by computing > (pixelsize*paddedX*paddedY), and require that size or more. I'd still think it is better to leave that completely up to the driver because it's more flexible and gives the driver full control. paddedX/paddedY will take care about any alignments / paddings and will probably catch most cases, but there might be other constrains ... > > Hmm, is this _really_ a problem? Do you want to mix that with > > console? I'd expect graphic applications whould use that only, > > like fbtv, dvd players (there is a fb-based one IIRC), ... > > Yes, if you want to be able to use the text console while > displaying stuff like video or a still image. One could > use `fbi' (:-) to display a background picture or `fbtv' > for background movie/video stream. It's an overlay, > it should behave nicely toward the foreground app, > even fbcon. IMHO :-) Don't know anything about the ruby design, but with the current console it simply doesn't work. fbi and fbtv switch the console into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they _have_ to do that for several reasons: - clean console switching, the apps must not write to the framebuffer if they are not running on the foreground console. fbtv also needs to turn off video DMA before it can allow switching away to another console. - full control over panning. fbcon changing the panning to scroll the text would scroll the fbi image / fbtv video too. fbtv has a switch to keep video dma enabled when switching consoles, this can lead to some funny effects ... Gerd -- Damn lot people confuse usability and eye-candy. |
|
From: Romain D. <do...@ir...> - 2001-07-12 08:35:37
|
Gerd Knorr wrote: > I'd still think it is better to leave that completely up to the driver > because it's more flexible and gives the driver full control. > paddedX/paddedY will take care about any alignments / paddings and will > probably catch most cases, but there might be other constrains ... OK, I will change to that effect (unless there's someone else that disagree). > Don't know anything about the ruby design, but with the current > console it simply doesn't work. fbi and fbtv switch the console > into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they > _have_ to do that for several reasons: I missing something there. `fbi' doesn't change anything on my display except it blanks it before (and after) displaying the image. I had a hacked pm3fb with 8+24 overlay (not video overlay), with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi' did simply put the picture in the lower 24 bits, anc after a C-c the image would stay as an underlay in the console. No fancy text mode here... but then I don't do VGA :-) I don't think every app should know what every other app do. FBcon use the FB layer, so do `fbi', `fbtv' or whatever. One can have a FB layer _without_ fbcon, say in a multihead setup, and that shouldn't prevent any app to run. Simply do whatever is required by the user in wherever memory area he wants. Every app should be made to behave nicely to other, i.e. not overwrite memory it doesn't need unless asked otherwise. That way, you can have fbcon using the FB as a console, an image viewer displaying an image anywhere in it, and another app overlaying a picture or video. If a VT is in `text mode', whatever that could be, then obviously you can't use it for graphic display. With my current model it works over pm3fb: I get fbcon to scroll under the overlay without problem (not that the overlay has anything useful in it, _that_ doesn't work yet ;-) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Gerd K. <kr...@by...> - 2001-07-12 11:40:27
|
> > Don't know anything about the ruby design, but with the current
> > console it simply doesn't work. fbi and fbtv switch the console
> > into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they
> > _have_ to do that for several reasons:
>
> I missing something there. `fbi' doesn't change anything on my
> display except it blanks it before (and after) displaying the
> image.
It doesn't change the video mode by default, yes (there is a switch to
ask for another mode throught). ioctl(tty,KDSETMODE, KD_GRAPHICS) does
not change video modes, but informs the console subsystem that the
application uses the vt for doing graphics. That means fbcon will not
print any text to that vt. console switches do not happen unless the
application allows this.
> I had a hacked pm3fb with 8+24 overlay (not video overlay),
> with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi'
> did simply put the picture in the lower 24 bits, anc after a C-c
> the image would stay as an underlay in the console.
^^^^^^^^^^
Tried that?
> I don't think every app should know what every other app
> do. FBcon use the FB layer, so do `fbi', `fbtv' or whatever.
fb applications have to take care about virtual consoles. They
need to know if they running on the foreground vt or not (i.e.
if they can draw to the framebuffer or not).
If you switch away from the X-Server to a text console you probably
don't want the X-Server continue updating the screen because that
would f*ck up your terminal.
It is still not clear what is supported to happen to any overlays if the
user switches to another virtual console. Will this invalidate any
existing overlays? Note that your fbcon virtual consoles might have
another video mode / color depth / font / ... each, which might also
affect the capabilities of the hardware (ati rage 3d can do yuv overlays
in 16 bpp and more only, but not in 8 bpp ...)
How the overlay memory area can be freed? Will the STOP ioctl do that
too?
> One can have a FB layer _without_ fbcon, say in a multihead
> setup, and that shouldn't prevent any app to run. Simply
> do whatever is required by the user in wherever memory area
> he wants. Every app should be made to behave nicely to other,
> i.e. not overwrite memory it doesn't need unless asked
> otherwise.
Ahem. That's a non-trivial problem. qt-embedded can do that
I think (have some window management in place for multiple apps
sharing a framebuffer display).
Gerd
--
Damn lot people confuse usability and eye-candy.
|
|
From: Romain D. <do...@ir...> - 2001-07-12 12:03:26
|
Gerd Knorr wrote: > > I had a hacked pm3fb with 8+24 overlay (not video overlay), > > with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi' > > did simply put the picture in the lower 24 bits, anc after a C-c > > the image would stay as an underlay in the console. > ^^^^^^^^^^ > Tried that? Yes, it did in the special 8+24 overlay mode (I don't remember trying in regular 24/32 bpp). Gave me a nice Debian underlay background. Too bad most of the logo is the same color than the fbcon text :-) > fb applications have to take care about virtual consoles. They > need to know if they running on the foreground vt or not (i.e. > if they can draw to the framebuffer or not). What happen if there's _no_ VT on the FB ? > If you switch away from the X-Server to a text console you probably > don't want the X-Server continue updating the screen because that > would f*ck up your terminal. Yes, that's a problem. Another thing I didn't try: what happen if you display a picture on FB1 from a VT0 on FB0, and switch to VT1 on FB0. The picture should not be erased on FB1, yes ? I'll need to try that. > It is still not clear what is supported to happen to any overlays if the > user switches to another virtual console. Will this invalidate any > existing overlays? Note that your fbcon virtual consoles might have > another video mode / color depth / font / ... each, which might also > affect the capabilities of the hardware (ati rage 3d can do yuv overlays > in 16 bpp and more only, but not in 8 bpp ...) My personal belief is that any app should display on the FB if there's no VT or if it is the active VT ; and that upon switching active VT or video mode all state should be assumed lost, i.e. memory buffer are invalid and all overlay are disabled. Say, what happen if a user switch video mode for a VT from another terminal ? (good old telnet :-) Another thing I didn't try yet... > How the overlay memory area can be freed? w/ _FREEBUF :-) > Will the STOP ioctl do that too? Nope, not any longer. An app might want to store picture in 2 or more buffer and start/stop overlay from either one without redisplaying the picture every time. > Ahem. That's a non-trivial problem. We wouldn't discuss the subject if it was trivial, would we ? :-) > qt-embedded can do that I think (have some window management > in place for multiple apps sharing a framebuffer display). Sven suggested a problem with mmap() ; can 2 apps mmap() the framebuffer simultaneously ? If not, then there's no need for inter-app resources control. If yes... > -- > Damn lot people confuse usability and eye-candy. I do :-) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Geert U. <ge...@li...> - 2001-07-12 12:23:59
|
On Thu, 12 Jul 2001, Romain Dolbeau wrote:
> Gerd Knorr wrote:
> > fb applications have to take care about virtual consoles. They
> > need to know if they running on the foreground vt or not (i.e.
> > if they can draw to the framebuffer or not).
>
> What happen if there's _no_ VT on the FB ?
>
> > If you switch away from the X-Server to a text console you probably
> > don't want the X-Server continue updating the screen because that
> > would f*ck up your terminal.
>
> Yes, that's a problem. Another thing I didn't try: what happen
> if you display a picture on FB1 from a VT0 on FB0, and switch
> to VT1 on FB0. The picture should not be erased on FB1, yes ?
> I'll need to try that.
In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
time, and VC switching is adisabled as long as /dev/fb* is open.
> > qt-embedded can do that I think (have some window management
> > in place for multiple apps sharing a framebuffer display).
>
> Sven suggested a problem with mmap() ; can 2 apps
> mmap() the framebuffer simultaneously ? If not, then
> there's no need for inter-app resources control. If
> yes...
Will be fixed at the same time :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Romain D. <do...@ir...> - 2001-07-12 12:32:26
|
Geert Uytterhoeven wrote: > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same > time, and VC switching is adisabled as long as /dev/fb* is open. So, XFree86-4 open /dev/fb to use the framebuffer, you can't go back to a VC until you have exited X ? Looks like a big backward step to me. But of course it solves a _lot_ of problems :-) Also, if all VC are on FB0, what happen if you mmap() FB1 ? Does it blocks VC switching or not ? -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Michel <mic...@ii...> - 2001-07-12 12:38:25
|
Romain Dolbeau wrote: > > Geert Uytterhoeven wrote: > > > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the > > same time, and VC switching is adisabled as long as /dev/fb* is open. > > So, XFree86-4 open /dev/fb to use the framebuffer, you > can't go back to a VC until you have exited X ? Nope, X just closes /dev/fb in fbdevHWLeaveVT() ... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Romain D. <do...@ir...> - 2001-07-12 12:42:17
|
Michel D=E4nzer wrote: > Nope, X just closes /dev/fb in fbdevHWLeaveVT() ... Chicken and egg. You can switch VT if you've closed fbdev, and upon changing VT you close fbdev... Or is there any way to call fbdevHWLeaveVT _before_ changing VT ? --=20 DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-07-12 17:19:33
|
> > Nope, X just closes /dev/fb in fbdevHWLeaveVT() ... > > Chicken and egg. You can switch VT if you've closed > fbdev, and upon changing VT you close fbdev... > > Or is there any way to call fbdevHWLeaveVT > _before_ changing VT ? The bigger problem will be with systems without VTs and with a framebuffer. Very few embedded devices have keybaords so it makes no sense to have a VT console on them. For example I run a iPAQ with just a serial console. I still use the framebuffer tho. I found X not to be very happy with this. Now the "community" could force devices to have VT console systems to this wouldn't go over very well since every byte of memory counts. |
|
From: Geert U. <ge...@li...> - 2001-07-12 12:40:45
|
On Thu, 12 Jul 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
> > time, and VC switching is adisabled as long as /dev/fb* is open.
>
> So, XFree86-4 open /dev/fb to use the framebuffer, you
> can't go back to a VC until you have exited X ?
> Looks like a big backward step to me. But of course
> it solves a _lot_ of problems :-)
No. You can still receive a signal when the user wants to switch VC.
In fact this is what X already does, but explicitly: it requests a new VC,
switches to it, disables VC switching, and installs a VC switching signal
handler. When the user wants to switch VCs, X gets the signal, unmaps graphics,
restores to text mode, and switches to the new VC.
So the only thing that changes is that VC switching is implicitly disabled when
/dev/fb* is opened.
> Also, if all VC are on FB0, what happen if you mmap() FB1 ?
> Does it blocks VC switching or not ?
Of course opening /dev/fbX affects VCs tied to fbX only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X