Menu
▾
▴
linux-fbdev-devel
|
From: Antonino D. <ad...@po...> - 2003-01-07 20:51:48
|
James,
I've waited a few days, seems nobody objected.
Attached is a patch for linux-2.5.54 + James Simmons' latest fbdev.diff.
1. Changed meaning of image.depth. If image.depth == 0, it flags for
color expansion, otherwise, it flags for image drawing (without color
expansion). This change is to accomodate monochrome cards so they can
differentiate character drawing from logo drawing.
2. diff submitted by Geert: cleaner logo data preparation for
monochrome cards and correct initialization of palette_cmap.transp.
3. added a few commentaries in skeletonfb.c detailing image.depth and
image.data.
Tony
diff -Naur linux-2.5.54/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.54/drivers/video/cfbimgblt.c 2003-01-07 16:00:08.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2003-01-07 15:39:33.000000000 +0000
@@ -323,7 +323,7 @@
bitstart &= ~(bpl - 1);
dst1 = p->screen_base + bitstart;
- if (image->depth == 1) {
+ if (image->depth == 0) {
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.54/drivers/video/console/fbcon.c 2003-01-07 16:01:11.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2003-01-07 15:43:52.000000000 +0000
@@ -395,7 +395,7 @@
image.dx = xx * vc->vc_font.width;
image.dy = yy * vc->vc_font.height;
image.height = vc->vc_font.height;
- image.depth = 1;
+ image.depth = 0;
if (!(vc->vc_font.width & 7)) {
unsigned int pitch, cnt, i, j, k;
@@ -1170,7 +1170,7 @@
image.dy = real_y(p, ypos) * vc->vc_font.height;
image.width = vc->vc_font.width;
image.height = vc->vc_font.height;
- image.depth = 1;
+ image.depth = 0;
image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
info->fbops->fb_imageblit(info, &image);
diff -Naur linux-2.5.54/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.54/drivers/video/fbmem.c 2003-01-07 16:00:15.000000000 +0000
+++ linux/drivers/video/fbmem.c 2003-01-07 15:43:11.000000000 +0000
@@ -386,6 +386,7 @@
palette_cmap.red = palette_red;
palette_cmap.green = palette_green;
palette_cmap.blue = palette_blue;
+ palette_cmap.transp = NULL;
for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
n = LINUX_LOGO_COLORS - i;
@@ -461,13 +462,11 @@
break;
case 1:
case ~1:
- default:
- for (i = 0; i < (LOGO_W * LOGO_H)/8; i++)
- for (j = 0; j < 8; j++)
- logo[i*8 + j] = (linux_logo_bw[i] & (7 - j)) ?
- ((needs_logo == 1) ? 1 : 0) :
- ((needs_logo == 1) ? 0 : 1);
- break;
+ for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
+ u8 d = linux_logo_bw[i];
+ for (j = 0; j < 8; j++, d <<= 1)
+ logo[i*8+j] = ((d ^ needs_logo) >> 7) & 1;
+ }
}
}
diff -Naur linux-2.5.54/drivers/video/i810/i810_accel.c linux/drivers/video/i810/i810_accel.c
--- linux-2.5.54/drivers/video/i810/i810_accel.c 2003-01-07 16:01:28.000000000 +0000
+++ linux/drivers/video/i810/i810_accel.c 2003-01-07 15:45:47.000000000 +0000
@@ -404,7 +404,7 @@
return;
}
- if (par->depth == 4 || image->depth != 1) {
+ if (par->depth == 4 || image->depth != 0) {
wait_for_engine_idle(par);
cfb_imageblit(p, image);
return;
diff -Naur linux-2.5.54/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.54/drivers/video/riva/fbdev.c 2003-01-07 16:01:40.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2003-01-07 15:47:28.000000000 +0000
@@ -1323,7 +1323,7 @@
volatile u32 *d;
int i, j, size;
- if (image->depth != 1) {
+ if (image->depth != 0) {
wait_for_idle(par);
cfb_imageblit(info, image);
return;
diff -Naur linux-2.5.54/drivers/video/skeletonfb.c linux/drivers/video/skeletonfb.c
--- linux-2.5.54/drivers/video/skeletonfb.c 2003-01-07 16:00:23.000000000 +0000
+++ linux/drivers/video/skeletonfb.c 2003-01-07 15:59:33.000000000 +0000
@@ -445,9 +445,14 @@
* @fg_color: For mono bitmap images this is color data for
* @bg_color: the foreground and background of the image to
* write directly to the frmaebuffer.
- * @depth: How many bits represent a single pixel for this image.
+ * @depth: This will be zero (0) if color expanding (character drawing).
+ * If nonzero, this represent the pixel depth of the data.
* @data: The actual data used to construct the image on the display.
- * @cmap: The colormap used for color images.
+ * It is a monochrome bitmap if color expanding. For image
+ * drawing, each byte of data represents 1 pixel irrespective
+ * of the framebuffer depth. The byte is either an index to the
+ * pseudo_palette for directcolor and truecolor, or the
+ * actual pixel written to the framebuffer.
*/
}
diff -Naur linux-2.5.54/drivers/video/softcursor.c linux/drivers/video/softcursor.c
--- linux-2.5.54/drivers/video/softcursor.c 2003-01-07 16:00:27.000000000 +0000
+++ linux/drivers/video/softcursor.c 2003-01-07 15:39:15.000000000 +0000
@@ -47,7 +47,7 @@
image.dy = cursor->image.dy;
image.width = cursor->image.width;
image.height = cursor->image.height;
- image.depth = cursor->image.depth;
+ image.depth = 0;
image.data = data;
if (info->fbops->fb_imageblit)
diff -Naur linux-2.5.54/drivers/video/tdfxfb.c linux/drivers/video/tdfxfb.c
--- linux-2.5.54/drivers/video/tdfxfb.c 2003-01-07 16:00:30.000000000 +0000
+++ linux/drivers/video/tdfxfb.c 2003-01-07 15:46:33.000000000 +0000
@@ -939,7 +939,7 @@
u8 *chardata = (u8 *) pixmap->data;
u32 srcfmt;
- if (pixmap->depth == 1) {
+ if (pixmap->depth == 0) {
banshee_make_room(par, 8 + ((size + 3) >> 2));
tdfx_outl(par, COLORFORE, pixmap->fg_color);
tdfx_outl(par, COLORBACK, pixmap->bg_color);
diff -Naur linux-2.5.54/drivers/video/tgafb.c linux/drivers/video/tgafb.c
--- linux-2.5.54/drivers/video/tgafb.c 2003-01-07 16:00:34.000000000 +0000
+++ linux/drivers/video/tgafb.c 2003-01-07 15:44:35.000000000 +0000
@@ -572,7 +572,7 @@
can do better than the generic code. */
/* ??? There is a DMA write mode; I wonder if that could be
made to pull the data from the image buffer... */
- if (image->depth > 1) {
+ if (image->depth > 0) {
cfb_imageblit(info, image);
return;
}
diff -Naur linux-2.5.54/drivers/video/vga16fb.c linux/drivers/video/vga16fb.c
--- linux-2.5.54/drivers/video/vga16fb.c 2003-01-07 16:00:41.000000000 +0000
+++ linux/drivers/video/vga16fb.c 2003-01-07 15:50:49.000000000 +0000
@@ -1301,7 +1301,7 @@
void vga16fb_imageblit(struct fb_info *info, struct fb_image *image)
{
- if (image->depth == 1)
+ if (image->depth == 0)
vga_imageblit_expand(info, image);
else if (image->depth == info->var.bits_per_pixel)
vga_imageblit_color(info, image);
|
|
From: Geert U. <ge...@li...> - 2003-01-07 21:08:26
|
On 8 Jan 2003, Antonino Daplas wrote:
> 2. diff submitted by Geert: cleaner logo data preparation for
> monochrome cards and correct initialization of palette_cmap.transp.
I'll have to do some more fixes there, since the monochrome logo is used not
only on monochrome displays, but on all other displays with bits_per_pixel < 4
Since the pixel data in fb_image are colormap indices, they have to reflect the
correct `black' and `white' colors on such displays.
E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
entries of {red,green,blue}8[] in fbcmap.c.
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: Antonino D. <ad...@po...> - 2003-01-08 02:55:56
|
On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> On 8 Jan 2003, Antonino Daplas wrote:
> > 2. diff submitted by Geert: cleaner logo data preparation for
> > monochrome cards and correct initialization of palette_cmap.transp.
>
> I'll have to do some more fixes there, since the monochrome logo is used not
> only on monochrome displays, but on all other displays with bits_per_pixel < 4
> Since the pixel data in fb_image are colormap indices, they have to reflect the
> correct `black' and `white' colors on such displays.
>
> E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> entries of {red,green,blue}8[] in fbcmap.c.
>
Hmm, I see. I think only linux_logo_bw will be the only one affected,
since linux_logo_16 happens to match the console palette and in
linux_logo, we either reset the palette and/or the cmap.
Would expanding each bit to the full bit depth work? Ie for bpp=8 using
monochrome data, white is 0 and black is 0xff.
I think we still have several corner cases, such as TRUECOLOR with bpp
<= 8, I'm not sure if that works.
Anyway, here's an updated patch for linux-2.5.54 + James Simmons' latest
fbdev.diff. Not sure if it works though :-)
Tony
diff -Naur linux-2.5.54/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.54/drivers/video/cfbimgblt.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2003-01-08 01:51:21.000000000 +0000
@@ -323,7 +323,7 @@
bitstart &= ~(bpl - 1);
dst1 = p->screen_base + bitstart;
- if (image->depth == 1) {
+ if (image->depth == 0) {
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.54/drivers/video/console/fbcon.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2003-01-07 15:43:52.000000000 +0000
@@ -395,7 +395,7 @@
image.dx = xx * vc->vc_font.width;
image.dy = yy * vc->vc_font.height;
image.height = vc->vc_font.height;
- image.depth = 1;
+ image.depth = 0;
if (!(vc->vc_font.width & 7)) {
unsigned int pitch, cnt, i, j, k;
@@ -1170,7 +1170,7 @@
image.dy = real_y(p, ypos) * vc->vc_font.height;
image.width = vc->vc_font.width;
image.height = vc->vc_font.height;
- image.depth = 1;
+ image.depth = 0;
image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
info->fbops->fb_imageblit(info, &image);
diff -Naur linux-2.5.54/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.54/drivers/video/fbmem.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/fbmem.c 2003-01-08 01:53:22.000000000 +0000
@@ -386,6 +386,7 @@
palette_cmap.red = palette_red;
palette_cmap.green = palette_green;
palette_cmap.blue = palette_blue;
+ palette_cmap.transp = NULL;
for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
n = LINUX_LOGO_COLORS - i;
@@ -448,26 +449,33 @@
palette[i] = i << redshift | i << greenshift | i << blueshift;
}
-static void __init fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
+#if defined (__BIG_ENDIAN)
+#define BIT_SHIFT(x, shift) ((x) >> (shift))
+#else
+#define BIT_SHIFT(x, shift) ((x) << (shift))
+#endif
+
+static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
{
int i, j;
+ u8 mask = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
switch (needs_logo) {
case 4:
- for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
+ for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
logo[i*2] = linux_logo16[i] >> 4;
logo[(i*2)+1] = linux_logo16[i] & 0xf;
}
break;
case 1:
case ~1:
- default:
- for (i = 0; i < (LOGO_W * LOGO_H)/8; i++)
- for (j = 0; j < 8; j++)
- logo[i*8 + j] = (linux_logo_bw[i] & (7 - j)) ?
- ((needs_logo == 1) ? 1 : 0) :
- ((needs_logo == 1) ? 0 : 1);
- break;
+ for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
+ u8 d = linux_logo_bw[i];
+ for (j = 0; j < 8; j++, d <<= 1)
+ logo[i*8+j] = (((d ^ needs_logo) >> 7) & 1) ?
+ mask : 0;
+ }
+ break;
}
}
diff -Naur linux-2.5.54/drivers/video/i810/i810_accel.c linux/drivers/video/i810/i810_accel.c
--- linux-2.5.54/drivers/video/i810/i810_accel.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/i810/i810_accel.c 2003-01-07 15:45:47.000000000 +0000
@@ -404,7 +404,7 @@
return;
}
- if (par->depth == 4 || image->depth != 1) {
+ if (par->depth == 4 || image->depth != 0) {
wait_for_engine_idle(par);
cfb_imageblit(p, image);
return;
diff -Naur linux-2.5.54/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.54/drivers/video/riva/fbdev.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2003-01-07 15:47:28.000000000 +0000
@@ -1323,7 +1323,7 @@
volatile u32 *d;
int i, j, size;
- if (image->depth != 1) {
+ if (image->depth != 0) {
wait_for_idle(par);
cfb_imageblit(info, image);
return;
diff -Naur linux-2.5.54/drivers/video/skeletonfb.c linux/drivers/video/skeletonfb.c
--- linux-2.5.54/drivers/video/skeletonfb.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/skeletonfb.c 2003-01-07 15:59:33.000000000 +0000
@@ -445,9 +445,14 @@
* @fg_color: For mono bitmap images this is color data for
* @bg_color: the foreground and background of the image to
* write directly to the frmaebuffer.
- * @depth: How many bits represent a single pixel for this image.
+ * @depth: This will be zero (0) if color expanding (character drawing).
+ * If nonzero, this represent the pixel depth of the data.
* @data: The actual data used to construct the image on the display.
- * @cmap: The colormap used for color images.
+ * It is a monochrome bitmap if color expanding. For image
+ * drawing, each byte of data represents 1 pixel irrespective
+ * of the framebuffer depth. The byte is either an index to the
+ * pseudo_palette for directcolor and truecolor, or the
+ * actual pixel written to the framebuffer.
*/
}
diff -Naur linux-2.5.54/drivers/video/softcursor.c linux/drivers/video/softcursor.c
--- linux-2.5.54/drivers/video/softcursor.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/softcursor.c 2003-01-07 15:39:15.000000000 +0000
@@ -47,7 +47,7 @@
image.dy = cursor->image.dy;
image.width = cursor->image.width;
image.height = cursor->image.height;
- image.depth = cursor->image.depth;
+ image.depth = 0;
image.data = data;
if (info->fbops->fb_imageblit)
diff -Naur linux-2.5.54/drivers/video/tdfxfb.c linux/drivers/video/tdfxfb.c
--- linux-2.5.54/drivers/video/tdfxfb.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/tdfxfb.c 2003-01-07 15:46:33.000000000 +0000
@@ -939,7 +939,7 @@
u8 *chardata = (u8 *) pixmap->data;
u32 srcfmt;
- if (pixmap->depth == 1) {
+ if (pixmap->depth == 0) {
banshee_make_room(par, 8 + ((size + 3) >> 2));
tdfx_outl(par, COLORFORE, pixmap->fg_color);
tdfx_outl(par, COLORBACK, pixmap->bg_color);
diff -Naur linux-2.5.54/drivers/video/tgafb.c linux/drivers/video/tgafb.c
--- linux-2.5.54/drivers/video/tgafb.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/tgafb.c 2003-01-07 15:44:35.000000000 +0000
@@ -572,7 +572,7 @@
can do better than the generic code. */
/* ??? There is a DMA write mode; I wonder if that could be
made to pull the data from the image buffer... */
- if (image->depth > 1) {
+ if (image->depth > 0) {
cfb_imageblit(info, image);
return;
}
diff -Naur linux-2.5.54/drivers/video/vga16fb.c linux/drivers/video/vga16fb.c
--- linux-2.5.54/drivers/video/vga16fb.c 2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/vga16fb.c 2003-01-07 15:50:49.000000000 +0000
@@ -1301,7 +1301,7 @@
void vga16fb_imageblit(struct fb_info *info, struct fb_image *image)
{
- if (image->depth == 1)
+ if (image->depth == 0)
vga_imageblit_expand(info, image);
else if (image->depth == info->var.bits_per_pixel)
vga_imageblit_color(info, image);
|
|
From: Geert U. <ge...@li...> - 2003-01-08 09:55:56
|
On 8 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > monochrome cards and correct initialization of palette_cmap.transp.
> >
> > I'll have to do some more fixes there, since the monochrome logo is used not
> > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > correct `black' and `white' colors on such displays.
> >
> > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > entries of {red,green,blue}8[] in fbcmap.c.
> >
>
> Hmm, I see. I think only linux_logo_bw will be the only one affected,
> since linux_logo_16 happens to match the console palette and in
> linux_logo, we either reset the palette and/or the cmap.
Indeed.
> Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> monochrome data, white is 0 and black is 0xff.
For bpp=8 that won't work, since we have 16 console colors only :-)
But for bpp=[1-3] that's OK, cfr. fbcmap.c.
BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
pixel values to the logo conversion routine? Preferably through a 2-element
array, so we can index it with the logo data bit value instead of using
tests/branches. Then we'd have:
- mono01: black = (1<<bits_per_pixel)-1, white = 0
- mono10: black = 0, white = (1<<bits_per_pixel)-1
- pseudocolor depth 1: black = 0, white = 1
- pseudocolor depth 2: black = 0, white = 3
- pseudocolor depth 3: black = 0, white (actually light grey) = 7
And thanks to the `(1<<depth)-1' instead of `1' for the mono* cases, monochrome
with bits_per_pixel = e.g. 8 will work as well.
What do you think?
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: Antonino D. <ad...@po...> - 2003-01-08 16:37:34
|
On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> On 8 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > > monochrome cards and correct initialization of palette_cmap.transp.
> > >
> > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > correct `black' and `white' colors on such displays.
> > >
> > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > entries of {red,green,blue}8[] in fbcmap.c.
> > >
> >
> > Hmm, I see. I think only linux_logo_bw will be the only one affected,
> > since linux_logo_16 happens to match the console palette and in
> > linux_logo, we either reset the palette and/or the cmap.
>
> Indeed.
>
> > Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> > monochrome data, white is 0 and black is 0xff.
>
> For bpp=8 that won't work, since we have 16 console colors only :-)
>
Of course :-)
> But for bpp=[1-3] that's OK, cfr. fbcmap.c.
>
> BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> pixel values to the logo conversion routine? Preferably through a 2-element
> array, so we can index it with the logo data bit value instead of using
> tests/branches. Then we'd have:
>
Something like this?
static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
{
int i, j;
u8 mask[2] = {0,0};
switch (needs_logo) {
case 4:
for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
logo[i*2] = linux_logo16[i] >> 4;
logo[(i*2)+1] = linux_logo16[i] & 0xf;
}
break;
case 1:
case ~1:
mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
u8 d = linux_logo_bw[i];
for (j = 0; j < 8; j++, d <<= 1)
logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
}
break;
}
}
Tony
|
|
From: Geert U. <ge...@li...> - 2003-01-08 16:53:26
|
On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > > > monochrome cards and correct initialization of palette_cmap.transp.
> > > >
> > > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > > correct `black' and `white' colors on such displays.
> > > >
> > > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > > entries of {red,green,blue}8[] in fbcmap.c.
> > > >
> > >
> > > Hmm, I see. I think only linux_logo_bw will be the only one affected,
> > > since linux_logo_16 happens to match the console palette and in
> > > linux_logo, we either reset the palette and/or the cmap.
> >
> > Indeed.
> >
> > > Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> > > monochrome data, white is 0 and black is 0xff.
> >
> > For bpp=8 that won't work, since we have 16 console colors only :-)
> >
>
> Of course :-)
>
> > But for bpp=[1-3] that's OK, cfr. fbcmap.c.
> >
> > BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> > pixel values to the logo conversion routine? Preferably through a 2-element
> > array, so we can index it with the logo data bit value instead of using
> > tests/branches. Then we'd have:
> >
>
> Something like this?
>
> static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
> {
> int i, j;
> u8 mask[2] = {0,0};
>
> switch (needs_logo) {
> case 4:
> for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
> logo[i*2] = linux_logo16[i] >> 4;
> logo[(i*2)+1] = linux_logo16[i] & 0xf;
> }
> break;
> case 1:
> case ~1:
> mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
> for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
> u8 d = linux_logo_bw[i];
> for (j = 0; j < 8; j++, d <<= 1)
> logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
> }
> break;
> }
> }
Yes, looks ok.
BTW, you can get rid of the `d ^ needs_logo' inside the loop by initializing
mask[] based on the value of needs_logo.
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: James S. <jsi...@in...> - 2003-01-10 19:28:36
|
> I think we still have several corner cases, such as TRUECOLOR with bpp
> <= 8, I'm not sure if that works.
The matorx millenium has such a mode. So such things do exist.
> - if (image->depth == 1) {
> + if (image->depth == 0) {
P.S
I'm just not to crazy about the depth equal zero thing. I just pitcure
developers having a hard time with it.
|
|
From: Geert U. <ge...@li...> - 2003-01-10 19:45:14
|
On Fri, 10 Jan 2003, James Simmons wrote:
> > I think we still have several corner cases, such as TRUECOLOR with bpp
> > <= 8, I'm not sure if that works.
>
> The matorx millenium has such a mode. So such things do exist.
>
> > - if (image->depth == 1) {
> > + if (image->depth == 0) {
>
> P.S
>
> I'm just not to crazy about the depth equal zero thing. I just pitcure
> developers having a hard time with it.
Monochrome color expansion just works differently: it expands the zeroes and
ones in a bitmap based on fg_color and bg_color, while image drawing draws an
image containing colormap indices to the frame buffer.
Do you have a better suggestion?
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: Antonino D. <ad...@po...> - 2003-01-11 05:20:48
|
On Sat, 2003-01-11 at 03:43, Geert Uytterhoeven wrote:
> On Fri, 10 Jan 2003, James Simmons wrote:
> > > I think we still have several corner cases, such as TRUECOLOR with bpp
> > > <= 8, I'm not sure if that works.
> >
> > The matorx millenium has such a mode. So such things do exist.
> >
> > > - if (image->depth == 1) {
> > > + if (image->depth == 0) {
> >
> > P.S
> >
> > I'm just not to crazy about the depth equal zero thing. I just pitcure
> > developers having a hard time with it.
>
> Monochrome color expansion just works differently: it expands the zeroes and
> ones in a bitmap based on fg_color and bg_color, while image drawing draws an
> image containing colormap indices to the frame buffer.
>
> Do you have a better suggestion?
>
If James is a bit skeptical about this, how about doing it this way:
If image.fg_color and image.bg_color == 0, then each byte of image.data
is an index to the pseudo_palette, or the actual pixel, whatever the
case may be. Otherwise, image.data is a monochrome bitmap that should
be expanded using fg_color and bg_color.
No other changes will be needed except that mono cards have to test for
fg_color and bg_color, and we need to memset the fb_image structure to 0
in fb_set_logo(). Non-mono cards will continue testing for image.depth.
Do you think this will work? The only problem I can think of is a color
expansion request where both bg and fg is 0.
Or to totally eliminate the above possibility, add an extra field in
struct fb_image to denote color expansion vs logo drawing. Again, only
mono cards will need to do this test.
Tony
|
|
From: Geert U. <ge...@li...> - 2003-01-11 13:25:54
|
On 11 Jan 2003, Antonino Daplas wrote:
> On Sat, 2003-01-11 at 03:43, Geert Uytterhoeven wrote:
> > On Fri, 10 Jan 2003, James Simmons wrote:
> > > I'm just not to crazy about the depth equal zero thing. I just pitcure
> > > developers having a hard time with it.
> >
> > Monochrome color expansion just works differently: it expands the zeroes and
> > ones in a bitmap based on fg_color and bg_color, while image drawing draws an
> > image containing colormap indices to the frame buffer.
> >
> > Do you have a better suggestion?
> >
>
> If James is a bit skeptical about this, how about doing it this way:
>
> If image.fg_color and image.bg_color == 0, then each byte of image.data
> is an index to the pseudo_palette, or the actual pixel, whatever the
> case may be. Otherwise, image.data is a monochrome bitmap that should
> be expanded using fg_color and bg_color.
>
> No other changes will be needed except that mono cards have to test for
> fg_color and bg_color, and we need to memset the fb_image structure to 0
> in fb_set_logo(). Non-mono cards will continue testing for image.depth.
>
> Do you think this will work? The only problem I can think of is a color
> expansion request where both bg and fg is 0.
And that can happen, try <ESC>[31m<ESC>[41m to set both to red.
> Or to totally eliminate the above possibility, add an extra field in
> struct fb_image to denote color expansion vs logo drawing. Again, only
> mono cards will need to do this test.
Ugh, why invent a new field if we can use an existing field? depth == 0 is
invalid for image blitting anyway.
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: Antonino D. <ad...@po...> - 2003-01-11 13:57:34
|
On Sat, 2003-01-11 at 21:24, Geert Uytterhoeven wrote: > > > > Do you think this will work? The only problem I can think of is a color > > expansion request where both bg and fg is 0. > > And that can happen, try <ESC>[31m<ESC>[41m to set both to red. > > > Or to totally eliminate the above possibility, add an extra field in > > struct fb_image to denote color expansion vs logo drawing. Again, only > > mono cards will need to do this test. > > Ugh, why invent a new field if we can use an existing field? depth == 0 is > invalid for image blitting anyway. > No argument here. Tony |
|
From: Geert U. <ge...@li...> - 2003-02-05 15:05:06
|
On 8 Jan 2003, Antonino Daplas wrote:
> 1. Changed meaning of image.depth. If image.depth == 0, it flags for
> color expansion, otherwise, it flags for image drawing (without color
> expansion). This change is to accomodate monochrome cards so they can
> differentiate character drawing from logo drawing.
What's the status of this issue? Monochrome is still broken due to this.
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: Antonino D. <ad...@po...> - 2003-02-06 07:30:36
|
On Wed, 2003-02-05 at 23:03, Geert Uytterhoeven wrote: > On 8 Jan 2003, Antonino Daplas wrote: > > 1. Changed meaning of image.depth. If image.depth == 0, it flags for > > color expansion, otherwise, it flags for image drawing (without color > > expansion). This change is to accomodate monochrome cards so they can > > differentiate character drawing from logo drawing. > > What's the status of this issue? Monochrome is still broken due to this. > It's still the same :-( Tony |
|
From: James S. <jsi...@in...> - 2003-02-12 20:51:13
|
> > 1. Changed meaning of image.depth. If image.depth == 0, it flags for > > color expansion, otherwise, it flags for image drawing (without color > > expansion). This change is to accomodate monochrome cards so they can > > differentiate character drawing from logo drawing. > > What's the status of this issue? Monochrome is still broken due to this. Ug. There are a few issues left to deal with. 1) The cursor issue. We need to add in the cusor ioctl call for people to use. Theortically there should be no issues with using soft_cursor with full color images with xxfb_imageblit. I like to see dest go away in struct fb_cursor. It's a matter of taking advantage of the upper console layer here. We shouldn't have any static variables in accel_cursor because if we have multiple cards we have problems. I plan to work on that. 2) Tileblits and stuff. I have been thinking about this and I really like to make it even more generic. We also have seperate buffers for textures for example which could also be used to draw fonts. The first thing is allocating or retreiving memory space for where to store the images. Second is to draw it. I guess a index of position would be used. |
|
From: Antonino D. <ad...@po...> - 2003-02-12 23:37:37
|
On Thu, 2003-02-13 at 04:50, James Simmons wrote:
>
> > > 1. Changed meaning of image.depth. If image.depth == 0, it flags for
> > > color expansion, otherwise, it flags for image drawing (without color
> > > expansion). This change is to accomodate monochrome cards so they can
> > > differentiate character drawing from logo drawing.
> >
> > What's the status of this issue? Monochrome is still broken due to this.
>
How about assigning fb_image.{bg_color,fg_color} to -1 if not color
expanding? Since the pseudo_palette will not exceed 255, this should be
safe.
> Ug. There are a few issues left to deal with.
>
> 1) The cursor issue. We need to add in the cusor ioctl call for people to
> use. Theortically there should be no issues with using soft_cursor with
> full color images with xxfb_imageblit. I like to see dest go away in
In order to do this, fb_imageblit has to support transparency (using a
transparency bitmask). Userland apps will rarely have rectangular mouse
cursor pointers. Also, it will need to support ROP's invert and copy.
This will break fb_imageblit.
Also, we have to double-buffer what's underneath the cursor.
Tony
|
|
From: Geert U. <ge...@li...> - 2003-02-13 09:34:17
|
On 13 Feb 2003, Antonino Daplas wrote:
> On Thu, 2003-02-13 at 04:50, James Simmons wrote:
> > > > 1. Changed meaning of image.depth. If image.depth == 0, it flags for
> > > > color expansion, otherwise, it flags for image drawing (without color
> > > > expansion). This change is to accomodate monochrome cards so they can
> > > > differentiate character drawing from logo drawing.
> > >
> > > What's the status of this issue? Monochrome is still broken due to this.
>
> How about assigning fb_image.{bg_color,fg_color} to -1 if not color
> expanding? Since the pseudo_palette will not exceed 255, this should be
> safe.
Unless we ever want to support colors > 256 (or real pixel values)?
Alternatively, we can split imageblit in two routines, one for image drawing,
and one for color expansion.
So we now have 3 options:
1. image.depth = 0 means color expansion,
2. fb_image.{bg_color,fg_color} = -1 means color expansion,
3. separate functions for image drawing and color expansion.
I still favor solution 1, since image.depth = 0 is not possible for images,
while fb_image.{bg_color,fg_color} = -1 (= 0xffffffff) may become valid in the
future, and the last one is more work to adapt the current drivers.
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
|
Thanks for helping keep SourceForge clean.
X