linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] [PATCH (2.4.10 ) + Questions]

[James S. <jsi...@tr...>]

> 1)    I'd like to code a driver for my ProSavage card, i got the X-server
> but i've no technical specifications... could someone help me (i don't want
> to reverse engineering that server) with specs, code, everything ???

This is a S3 card right? I know a few people have done scattered work on
this chipset. 

> 2)    I did a patch for 2.4.10 tree to include a new 8x16 font (it's "c"
> font that you could find in all Slackware distributions), it's tiny (15,6 Kb
> only) and pretty to see... do you think it could be reasonable to submit it.

The tendency to limit the number of fonts into kernel space but instead
use the userland utility setfont to change the font displayed from
userland.

Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> Commited. It uses a couple custom struct, I didn't see anything
> reasonably similar in fb.h ?

Nope. Only thing I have is fb_image. I moved the stuff together for
userland to use. I have ROP_X in the kernel section. Now it is useable to
userland. We could extend it to support image drawing as well. Draw
writers can see if they get the penguin when insmoding.

Re: [Linux-fbdev-devel] unified accerated interface

[<dol...@cl...>]

> I don't know about it being added into the linus tree but it would be
> really helpful for debugging. Add it anyways. I kind of provided the
> structs for it anyways.

Commited. It uses a couple custom struct, I didn't see anything
reasonably similar in fb.h ?

Note: it compiles, but hasn't been tested. Should work with any driver,
it's just 2 wrappers around fb_ops->fb_fillrect and fb_ops->fb_copyarea.

--=20
Romain DOLBEAU               | Ce que l'on con=E7oit bien s'=E9nonce
ENS Cachan / Ker Lann        | clairement, et les mots pour le dire
Thesard IRISA / CAPS         | arrivent ais=E9ment.
dol...@cl...    |       -- Nicolas Boileau

Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> My comments apply to the new "Ruby" framework, not to the current
> 2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one
> character), where Ruby use pixel-based copy and fill, much more
> flexible.
> 
> I've hacked a patch to add the two IOCTLS (for fillrect and copyarea),
> it's less than 90 lines. Maybe it's worth adding to Ruby ?

I don't know about it being added into the linus tree but it would be
really helpful for debugging. Add it anyways. I kind of provided the
structs for it anyways.

Re: [Linux-fbdev-devel] unified accerated interface

[<dol...@cl...>]

Chris Wright wrote:

> is there a standard way to access hardware acceleration without needing
> root privs or X? (sort of like accessing framebuffer before /dev/fb, you
> needed svgalib (root), or some X based library).

Romain Dolbeau answered:

> It could be done to add ioctl to allow app access to fb_fillrect and
> fb_copyarea, and maybe fb_imageblit. But I'm not sure it could make it to
> the Linux tree...

Oups, I forgot to check the header, and thought the original message was
on linux-console, not linux-fbdev.

My comments apply to the new "Ruby" framework, not to the current
2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one
character), where Ruby use pixel-based copy and fill, much more
flexible.

I've hacked a patch to add the two IOCTLS (for fillrect and copyarea),
it's less than 90 lines. Maybe it's worth adding to Ruby ?

-- 
DOLBEAU Romain               | The Gods made Heavy Metal
ENS Cachan / Ker Lann        |     and it's never gonna die
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |    'The Gods made Heavy Metal'

Re: [Linux-fbdev-devel] unified accerated interface

[Romain D. <do...@ir...>]

Chris Wright wrote:

> is there a standard way to access hardware acceleration without needing
> root privs or X? (sort of like accessing framebuffer before /dev/fb, you
> needed svgalib (root), or some X based library).

Not yet, I believe.

> if there isn't a way (dri is X only afaik), hows the forecast for creating
> a kernel level hardware acceleration overlay, with software fallbacks?
> (i am guessing this really wont put much code into the kernel, but will
> have lots of modules etc).

DRI is a 3D-on-XFree86 thing.

It could be done to add ioctl to allow app access to fb_fillrect
and fb_copyarea, and maybe fb_imageblit. But I'm not sure it could
make it to the Linux tree...

Yet it might worth talking about it. Stuff like microwindows
could probably use it.

It would be a simple ioctl wrapper around the fb_* stuff,
as those are mandatory (either HW-accel or using the supplied
generic functions).

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
                             |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

[Linux-fbdev-devel] unified accerated interface

[Chris W. <cw...@so...>]

Hello!

is there a standard way to access hardware acceleration without needing
root privs or X? (sort of like accessing framebuffer before /dev/fb, you
needed svgalib (root), or some X based library).

if there isn't a way (dri is X only afaik), hows the forecast for creating
a kernel level hardware acceleration overlay, with software fallbacks?
(i am guessing this really wont put much code into the kernel, but will
have lots of modules etc).

thanks for your time =)
chris

	Computers are useless.  They can only give you answers.
        	        -- Pablo Picasso

[Linux-fbdev-devel] [PATCH (2.4.10 ) + Questions]

[Francesco S. <f.s...@cp...>]

Hi to all,
    I've some question

1)    I'd like to code a driver for my ProSavage card, i got the X-server
but i've no technical specifications... could someone help me (i don't want
to reverse engineering that server) with specs, code, everything ???

2)    I did a patch for 2.4.10 tree to include a new 8x16 font (it's "c"
font that you could find in all Slackware distributions), it's tiny (15,6 Kb
only) and pretty to see... do you think it could be reasonable to submit it.

    Thank you.
        Francesco Salvestrini

[Linux-fbdev-devel] Re: scr_*() audit

[Geert U. <ge...@li...>]

On Wed, 22 Aug 2001, Geert Uytterhoeven wrote:
> Since there are still some issues left with the scr_*() functions on
> big-endian platforms that can have both VGA and frame buffer consoles, I
> decided to spent some precious time on auditing the usage of these functions.

And here are the optimizations (I split them off from the bug fixes because
they are not that critical).

Should apply cleanly to any recent 2.4.x[-ac] kernel.

--- linux-2.4.10/drivers/video/cgsixfb.c	Tue Sep 25 10:15:11 2001
+++ scr-audit-2.4.10/drivers/video/cgsixfb.c	Sat Sep 29 17:50:23 2001
@@ -364,13 +364,15 @@
 	unsigned long flags;
 	int i, x, y;
 	u8 *fd1, *fd2, *fd3, *fd4;
+	u16 c;
 
 	spin_lock_irqsave(&fb->lock, flags);
 	do {
 		i = sbus_readl(&fbc->s);
 	} while (i & 0x10000000);
-	sbus_writel(attr_fgcol(p, scr_readw(s)), &fbc->fg);
-	sbus_writel(attr_bgcol(p, scr_readw(s)), &fbc->bg);
+	c = scr_readw(s);
+	sbus_writel(attr_fgcol(p, c), &fbc->fg);
+	sbus_writel(attr_bgcol(p, c), &fbc->bg);
 	sbus_writel(0x140000, &fbc->mode);
 	sbus_writel(0xe880fc30, &fbc->alu);
 	sbus_writel(~0, &fbc->pixelm);
--- linux-2.4.10/drivers/video/creatorfb.c	Tue Sep 25 10:15:11 2001
+++ scr-audit-2.4.10/drivers/video/creatorfb.c	Sat Sep 29 17:50:23 2001
@@ -475,11 +475,13 @@
 	unsigned long flags;
 	int i, xy;
 	u8 *fd1, *fd2, *fd3, *fd4;
+	u16 c;
 	u64 fgbg;
 
 	spin_lock_irqsave(&fb->lock, flags);
-	fgbg = (((u64)(((u32 *)p->dispsw_data)[attr_fgcol(p,scr_readw(s))])) << 32) |
-	       ((u32 *)p->dispsw_data)[attr_bgcol(p,scr_readw(s))];
+	c = scr_readw(s);
+	fgbg = (((u64)(((u32 *)p->dispsw_data)[attr_fgcol(p, c)])) << 32) |
+	       ((u32 *)p->dispsw_data)[attr_bgcol(p, c)];
 	if (fgbg != *(u64 *)&fb->s.ffb.fg_cache) {
 		FFBFifo(fb, 2);
 		upa_writeq(fgbg, &fbc->fg);
--- linux-2.4.10/drivers/video/fbcon-afb.c	Thu Sep 13 10:37:10 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-afb.c	Sat Sep 29 17:50:23 2001
@@ -290,8 +290,9 @@
     int fg0, bg0, fg, bg;
 
     dest0 = p->screen_base+yy*fontheight(p)*p->next_line+xx;
-    fg0 = attr_fgcol(p, scr_readw(s));
-    bg0 = attr_bgcol(p, scr_readw(s));
+    c1 = scr_readw(s);
+    fg0 = attr_fgcol(p, c1);
+    bg0 = attr_bgcol(p, c1);
 
     while (count--)
 	if (xx&3 || count < 3) {	/* Slow version */
--- linux-2.4.10/drivers/video/fbcon-cfb16.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb16.c	Sat Sep 29 17:50:23 2001
@@ -178,8 +178,9 @@
     u32 eorx, fgx, bgx;
 
     dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p) * 2;
-    fgx = ((u16 *)p->dispsw_data)[attr_fgcol(p, scr_readw(s))];
-    bgx = ((u16 *)p->dispsw_data)[attr_bgcol(p, scr_readw(s))];
+    c = scr_readw(s);
+    fgx = ((u16 *)p->dispsw_data)[attr_fgcol(p, c)];
+    bgx = ((u16 *)p->dispsw_data)[attr_bgcol(p, c)];
     fgx |= (fgx << 16);
     bgx |= (bgx << 16);
     eorx = fgx ^ bgx;
--- linux-2.4.10/drivers/video/fbcon-cfb2.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb2.c	Sat Sep 29 17:50:23 2001
@@ -154,8 +154,9 @@
 	u32 eorx, fgx, bgx;
 
 	dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * 2;
-	fgx=3/*attr_fgcol(p,scr_readw(s))*/;
-	bgx=attr_bgcol(p,scr_readw(s));
+	c = scr_readw(s);
+	fgx = 3/*attr_fgcol(p, c)*/;
+	bgx = attr_bgcol(p, c);
 	fgx |= (fgx << 2);
 	fgx |= (fgx << 4);
 	bgx |= (bgx << 2);
--- linux-2.4.10/drivers/video/fbcon-cfb24.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb24.c	Sat Sep 29 17:50:23 2001
@@ -191,8 +191,9 @@
     u32 eorx, fgx, bgx, d1, d2, d3, d4;
 
     dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p) * 3;
-    fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p, scr_readw(s))];
-    bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p, scr_readw(s))];
+    c = scr_readw(s);
+    fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p, c)];
+    bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p, c)];
     eorx = fgx ^ bgx;
     while (count--) {
 	c = scr_readw(s++) & p->charmask;
--- linux-2.4.10/drivers/video/fbcon-cfb32.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb32.c	Sat Sep 29 17:50:23 2001
@@ -164,8 +164,9 @@
     u32 eorx, fgx, bgx, *pt;
 
     dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p) * 4;
-    fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p, scr_readw(s))];
-    bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p, scr_readw(s))];
+    c = scr_readw(s);
+    fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p, c)];
+    bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p, c)];
     eorx = fgx ^ bgx;
     while (count--) {
 	c = scr_readw(s++) & p->charmask;
--- linux-2.4.10/drivers/video/fbcon-cfb4.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb4.c	Sat Sep 29 17:50:23 2001
@@ -156,8 +156,9 @@
 	u32 eorx, fgx, bgx;
 
 	dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * 4;
-	fgx=attr_fgcol(p,scr_readw(s));
-	bgx=attr_bgcol(p,scr_readw(s));
+	c = scr_readw(s);
+	fgx = attr_fgcol(p, c);
+	bgx = attr_bgcol(p, c);
 	fgx |= (fgx << 4);
 	fgx |= (fgx << 8);
 	fgx |= (fgx << 16);
--- linux-2.4.10/drivers/video/fbcon-cfb8.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-cfb8.c	Sat Sep 29 17:50:24 2001
@@ -163,8 +163,9 @@
     u32 eorx, fgx, bgx;
 
     dest0 = p->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p);
-    fgx=attr_fgcol(p,scr_readw(s));
-    bgx=attr_bgcol(p,scr_readw(s));
+    c = scr_readw(s);
+    fgx = attr_fgcol(p, c);
+    bgx = attr_bgcol(p, c);
     fgx |= (fgx << 8);
     fgx |= (fgx << 16);
     bgx |= (bgx << 8);
--- linux-2.4.10/drivers/video/fbcon-hga.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-hga.c	Sat Sep 29 17:50:24 2001
@@ -148,9 +148,10 @@
 	u8 d;
 	u16 c;
 	
-	bold = attr_bold(p,scr_readw(s));
-	revs = attr_reverse(p,scr_readw(s));
-	underl = attr_underline(p,scr_readw(s));
+	c = scr_readw(s);
+	bold = attr_bold(p, c);
+	revs = attr_reverse(p, c);
+	underl = attr_underline(p, c);
 	y0 = yy*fontheight(p);
 
 	while (count--) {
--- linux-2.4.10/drivers/video/fbcon-ilbm.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-ilbm.c	Sat Sep 29 17:50:24 2001
@@ -154,8 +154,9 @@
     int fg0, bg0, fg, bg;
 
     dest0 = p->screen_base+yy*fontheight(p)*p->next_line+xx;
-    fg0 = attr_fgcol(p,scr_readw(s));
-    bg0 = attr_bgcol(p,scr_readw(s));
+    c1 = scr_readw(s);
+    fg0 = attr_fgcol(p, c1);
+    bg0 = attr_bgcol(p, c1);
 
     while (count--)
 	if (xx&3 || count < 3) {	/* Slow version */
--- linux-2.4.10/drivers/video/fbcon-iplan2p2.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-iplan2p2.c	Sat Sep 29 17:50:24 2001
@@ -364,8 +364,9 @@
     else
 	dest0 = (p->screen_base + yy * bytes * fontheight(p) +
 		 (xx>>1)*4 + (xx & 1));
-    fgx = expand2w(COLOR_2P(attr_fgcol(p,scr_readw(s))));
-    bgx = expand2w(COLOR_2P(attr_bgcol(p,scr_readw(s))));
+    c = scr_readw(s);
+    fgx = expand2w(COLOR_2P(attr_fgcol(p, c)));
+    bgx = expand2w(COLOR_2P(attr_bgcol(p, c)));
     eorx = fgx ^ bgx;
 
     while (count--) {
--- linux-2.4.10/drivers/video/fbcon-iplan2p4.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-iplan2p4.c	Sat Sep 29 17:50:24 2001
@@ -374,8 +374,9 @@
     else
 	dest0 = (p->screen_base + yy * bytes * fontheight(p) +
 		 (xx>>1)*8 + (xx & 1));
-    fgx = expand4l(attr_fgcol(p,scr_readw(s)));
-    bgx = expand4l(attr_bgcol(p,scr_readw(s)));
+    c = scr_readw(s);
+    fgx = expand4l(attr_fgcol(p, c));
+    bgx = expand4l(attr_bgcol(p, c));
     eorx = fgx ^ bgx;
 
     while (count--) {
--- linux-2.4.10/drivers/video/fbcon-iplan2p8.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-iplan2p8.c	Sat Sep 29 17:50:24 2001
@@ -407,8 +407,9 @@
 	dest0 = (p->screen_base + yy * bytes * fontheight(p) +
 		 (xx>>1)*16 + (xx & 1));
 
-    expand8dl(attr_fgcol(p,scr_readw(s)), &fgx1, &fgx2);
-    expand8dl(attr_bgcol(p,scr_readw(s)), &bgx1, &bgx2);
+    c = scr_readw(s);
+    expand8dl(attr_fgcol(p, c), &fgx1, &fgx2);
+    expand8dl(attr_bgcol(p, c), &bgx1, &bgx2);
     eorx1 = fgx1 ^ bgx1; eorx2  = fgx2 ^ bgx2;
 
     while (count--) {
--- linux-2.4.10/drivers/video/fbcon-mfb.c	Thu Sep 13 10:37:11 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-mfb.c	Sat Sep 29 17:50:24 2001
@@ -117,9 +117,10 @@
     u16 c;
 
     dest0 = p->screen_base+yy*fontheight(p)*p->next_line+xx;
-    bold = attr_bold(p,scr_readw(s));
-    revs = attr_reverse(p,scr_readw(s));
-    underl = attr_underline(p,scr_readw(s));
+    c = scr_readw(s);
+    bold = attr_bold(p, c);
+    revs = attr_reverse(p, c);
+    underl = attr_underline(p, c);
 
     while (count--) {
 	c = scr_readw(s++) & p->charmask;
--- linux-2.4.10/drivers/video/fbcon-sti.c	Thu Sep 13 10:37:12 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-sti.c	Sat Sep 29 17:50:24 2001
@@ -257,9 +257,10 @@
 		return;
 	}	
 
-	bold = attr_bold(p,scr_readw(s));
-	revs = attr_reverse(p,scr_readw(s));
-	underl = attr_underline(p,scr_readw(s));
+	c = scr_readw(s);
+	bold = attr_bold(p, c);
+	revs = attr_reverse(p, c);
+	underl = attr_underline(p, c);
 
 	while (count--) {
 		c = scr_readw(s++) & p->charmask;
--- linux-2.4.10/drivers/video/fbcon-vga-planes.c	Thu Sep 13 10:37:12 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-vga-planes.c	Sat Sep 29 17:50:24 2001
@@ -236,8 +236,9 @@
 void fbcon_ega_planes_putcs(struct vc_data *conp, struct display *p, const unsigned short *s,
 		   int count, int yy, int xx)
 {
-	int fg = attr_fgcol(p,scr_readw(s));
-	int bg = attr_bgcol(p,scr_readw(s));
+	u16 c = scr_readw(s);
+	int fg = attr_fgcol(p, c);
+	int bg = attr_bgcol(p, c);
 
 	char *where;
 	int n;
--- linux-2.4.10/drivers/video/leofb.c	Tue Sep 25 10:15:12 2001
+++ scr-audit-2.4.10/drivers/video/leofb.c	Sat Sep 29 17:50:24 2001
@@ -285,14 +285,16 @@
 	unsigned long flags;
 	int i, x, y;
 	u8 *fd1, *fd2, *fd3, *fd4;
+	u16 c;
 	u32 *u;
 
 	spin_lock_irqsave(&fb->lock, flags);
 	do {
 		i = sbus_readl(&us->csr);
 	} while (i & 0x20000000);
-	sbus_writel(attr_fgcol(p,scr_readw(s)) << 24, &ss->fg);
-	sbus_writel(attr_bgcol(p,scr_readw(s)) << 24, &ss->bg);
+	c = scr_readw(s);
+	sbus_writel(attr_fgcol(p, c) << 24, &ss->fg);
+	sbus_writel(attr_bgcol(p, c) << 24, &ss->bg);
 	sbus_writel(0xFFFFFFFF<<(32-fontwidth(p)), &us->fontmsk);
 	if (fontwidthlog(p))
 		x = (xx << fontwidthlog(p));
--- linux-2.4.10/drivers/video/matrox/matroxfb_accel.c	Wed Jun 20 11:06:14 2001
+++ scr-audit-2.4.10/drivers/video/matrox/matroxfb_accel.c	Sat Sep 29 17:50:24 2001
@@ -654,13 +654,15 @@
 
 #ifdef FBCON_HAS_CFB8
 static void matrox_cfb8_putcs(struct vc_data* conp, struct display* p, const unsigned short* s, int count, int yy, int xx) {
+	u_int16_t c;
 	u_int32_t fgx, bgx;
 	MINFO_FROM_DISP(p);
 
 	DBG_HEAVY("matroxfb_cfb8_putcs");
 
-	fgx = attr_fgcol(p, scr_readw(s));
-	bgx = attr_bgcol(p, scr_readw(s));
+	c = scr_readw(s);
+	fgx = attr_fgcol(p, c);
+	bgx = attr_bgcol(p, c);
 	fgx |= (fgx << 8);
 	fgx |= (fgx << 16);
 	bgx |= (bgx << 8);
@@ -671,13 +673,15 @@
 
 #ifdef FBCON_HAS_CFB16
 static void matrox_cfb16_putcs(struct vc_data* conp, struct display* p, const unsigned short* s, int count, int yy, int xx) {
+	u_int16_t c;
 	u_int32_t fgx, bgx;
 	MINFO_FROM_DISP(p);
 
 	DBG_HEAVY("matroxfb_cfb16_putcs");
 
-	fgx = ((u_int16_t*)p->dispsw_data)[attr_fgcol(p, scr_readw(s))];
-	bgx = ((u_int16_t*)p->dispsw_data)[attr_bgcol(p, scr_readw(s))];
+	c = scr_readw(s);
+	fgx = ((u_int16_t*)p->dispsw_data)[attr_fgcol(p, c)];
+	bgx = ((u_int16_t*)p->dispsw_data)[attr_bgcol(p, c)];
 	fgx |= (fgx << 16);
 	bgx |= (bgx << 16);
 	ACCESS_FBINFO(curr.putcs)(fgx, bgx, p, s, count, yy, xx);
@@ -686,13 +690,15 @@
 
 #if defined(FBCON_HAS_CFB32) || defined(FBCON_HAS_CFB24)
 static void matrox_cfb32_putcs(struct vc_data* conp, struct display* p, const unsigned short* s, int count, int yy, int xx) {
+	u_int16_t c;
 	u_int32_t fgx, bgx;
 	MINFO_FROM_DISP(p);
 
 	DBG_HEAVY("matroxfb_cfb32_putcs");
 
-	fgx = ((u_int32_t*)p->dispsw_data)[attr_fgcol(p, scr_readw(s))];
-	bgx = ((u_int32_t*)p->dispsw_data)[attr_bgcol(p, scr_readw(s))];
+	c = scr_readw(s);
+	fgx = ((u_int32_t*)p->dispsw_data)[attr_fgcol(p, c)];
+	bgx = ((u_int32_t*)p->dispsw_data)[attr_bgcol(p, c)];
 	ACCESS_FBINFO(curr.putcs)(fgx, bgx, p, s, count, yy, xx);
 }
 #endif
@@ -900,12 +906,14 @@
 	unsigned int offs;
 	unsigned int attr;
 	unsigned int step;
+	u_int16_t c;
 	CRITFLAGS
 	MINFO_FROM_DISP(p);
 
 	step = ACCESS_FBINFO(devflags.textstep);
 	offs = yy * p->next_line + xx * step;
-	attr = attr_fgcol(p, scr_readw(s)) | (attr_bgcol(p, scr_readw(s)) << 4);
+	c = scr_readw(s);
+	attr = attr_fgcol(p, c) | (attr_bgcol(p, c) << 4);
 
 	CRITBEGIN
 
--- linux-2.4.10/drivers/video/riva/accel.c	Mon Feb 19 10:37:00 2001
+++ scr-audit-2.4.10/drivers/video/riva/accel.c	Sat Sep 29 17:50:24 2001
@@ -207,10 +207,11 @@
 	xx *= fontwidth(p);
 	yy *= fontheight(p);
 
+	c = scr_readw(s);
+	fgx = attr_fgcol(p, c);
+	bgx = attr_bgcol(p, c);
 	while (count--) {
 		c = scr_readw(s++);
-		fgx = attr_fgcol(p,c);
-		bgx = attr_bgcol(p,c);
 		fbcon_riva_writechr(conp, p, c, fgx, bgx, yy, xx);
 		xx += fontwidth(p);
 	}
@@ -321,12 +322,13 @@
 	xx *= fontwidth(p);
 	yy *= fontheight(p);
 
+	c = scr_readw(s);
+	fgx = ((u16 *)p->dispsw_data)[attr_fgcol(p, c)];
+	bgx = ((u16 *)p->dispsw_data)[attr_bgcol(p, c)];
+	if (p->var.green.length == 6)
+		convert_bgcolor_16(&bgx);
 	while (count--) {
 		c = scr_readw(s++);
-		fgx = ((u16 *)p->dispsw_data)[attr_fgcol(p,c)];
-		bgx = ((u16 *)p->dispsw_data)[attr_bgcol(p,c)];
-		if (p->var.green.length == 6)
-			convert_bgcolor_16(&bgx);
 		fbcon_riva_writechr(conp, p, c, fgx, bgx, yy, xx);
 		xx += fontwidth(p);
 	}
@@ -396,10 +398,11 @@
 	xx *= fontwidth(p);
 	yy *= fontheight(p);
 
+	c = scr_readw(s);
+	fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p, c)];
+	bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p, c)];
 	while (count--) {
 		c = scr_readw(s++);
-		fgx = ((u32 *)p->dispsw_data)[attr_fgcol(p,c)];
-		bgx = ((u32 *)p->dispsw_data)[attr_bgcol(p,c)];
 		fbcon_riva_writechr(conp, p, c, fgx, bgx, yy, xx);
 		xx += fontwidth(p);
 	}

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

[Linux-fbdev-devel] Re: scr_*() audit

[Geert U. <ge...@li...>]

On Wed, 22 Aug 2001, Geert Uytterhoeven wrote:
> Since there are still some issues left with the scr_*() functions on
> big-endian platforms that can have both VGA and frame buffer consoles, I
> decided to spent some precious time on auditing the usage of these functions.

So here are the (updated) fixes. They are most critical for big-endian machines
that can have real VGA text hardware and frame buffer devices. Little-endian
machines are immune since VGA text is little-endian anyway.

Changes since previous version:
  - Fix missing semicolon in console.c
  - Fix pointer arithmetic in hgafb.c
  - Remove scr_memcpyw_{from,to}() since they are no longer used

The patch should apply cleanly to all recent 2.4.x[-ac] kernels.

Alan, please apply.

--- linux-2.4.10/drivers/char/console.c	Tue Sep 25 10:14:43 2001
+++ scr-audit-2.4.10/drivers/char/console.c	Sat Sep 29 19:30:08 2001
@@ -399,20 +399,28 @@
 	else {
 		u16 *q = p;
 		int cnt = count;
+		u16 a;
 
 		if (!can_do_color) {
-			while (cnt--) *q++ ^= 0x0800;
+			while (cnt--) {
+			    a = scr_readw(q);
+			    a ^= 0x0800;
+			    scr_writew(a, q);
+			    q++;
+			}
 		} else if (hi_font_mask == 0x100) {
 			while (cnt--) {
-				u16 a = *q;
+				a = scr_readw(q);
 				a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
-				*q++ = a;
+				scr_writew(a, q);
+				q++;
 			}
 		} else {
 			while (cnt--) {
-				u16 a = *q;
+				a = scr_readw(q);
 				a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
-				*q++ = a;
+				scr_writew(a, q);
+				q++;
 			}
 		}
 	}
--- linux-2.4.10/drivers/video/dn_cfb8.c	Thu Sep 13 10:37:10 2001
+++ scr-audit-2.4.10/drivers/video/dn_cfb8.c	Sat Sep 29 17:50:23 2001
@@ -518,7 +518,7 @@
     underl = attr_underline(p,conp);
 
     while (count--) {
-	c = *s++;
+	c = scr_readw(s++);
 	dest = dest0++;
 	cdat = p->fontdata+c*p->fontheight;
 	for (rows = p->fontheight; rows--; dest += p->next_line) {
--- linux-2.4.10/drivers/video/fbcon-vga-planes.c	Thu Sep 13 10:37:12 2001
+++ scr-audit-2.4.10/drivers/video/fbcon-vga-planes.c	Sat Sep 29 17:50:24 2001
@@ -274,8 +275,9 @@
 void fbcon_vga_planes_putcs(struct vc_data *conp, struct display *p, const unsigned short *s,
 		   int count, int yy, int xx)
 {
-	int fg = attr_fgcol(p,*s);
-	int bg = attr_bgcol(p,*s);
+	u16 c = scr_readw(s);
+	int fg = attr_fgcol(p, c);
+	int bg = attr_bgcol(p, c);
 
 	char *where;
 	int n;
@@ -295,7 +297,7 @@
 	wmb();
 	for (n = 0; n < count; n++) {
 		int y;
-		int c = *s++ & p->charmask;
+		int c = scr_readw(s++) & p->charmask;
 		u8 *cdat = p->fontdata + (c & p->charmask) * fontheight(p);
 
 		for (y = 0; y < fontheight(p); y++, cdat++) {
--- linux-2.4.10/drivers/video/fbcon.c	Thu Sep 13 10:37:12 2001
+++ scr-audit-2.4.10/drivers/video/fbcon.c	Sat Sep 29 17:50:24 2001
@@ -664,7 +664,7 @@
     	    	scr_memsetw(save, conp->vc_video_erase_char, logo_lines * nr_cols * 2);
     	    	r = q - step;
     	    	for (cnt = 0; cnt < logo_lines; cnt++, r += i)
-    	    		scr_memcpyw_from(save + cnt * nr_cols, r, 2 * i);
+    	    		scr_memcpyw(save + cnt * nr_cols, r, 2 * i);
     	    	r = q;
     	    }
     	}
@@ -682,7 +682,7 @@
     	}
     	scr_memsetw((unsigned short *)conp->vc_origin,
 		    conp->vc_video_erase_char, 
-    		conp->vc_size_row * logo_lines);
+		    conp->vc_size_row * logo_lines);
     }
     
     /*
@@ -2010,17 +2010,14 @@
 static void fbcon_invert_region(struct vc_data *conp, u16 *p, int cnt)
 {
     while (cnt--) {
+	u16 a = scr_readw(p);
 	if (!conp->vc_can_do_color)
-	    *p++ ^= 0x0800;
-	else if (conp->vc_hi_font_mask == 0x100) {
-	    u16 a = *p;
+	    a ^= 0x0800;
+	else if (conp->vc_hi_font_mask == 0x100)
 	    a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
-	    *p++ = a;
-	} else {
-	    u16 a = *p;
+	else
 	    a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
-	    *p++ = a;
-	}
+	scr_writew(a, p++);
 	if (p == (u16 *)softback_end)
 	    p = (u16 *)softback_buf;
 	if (p == (u16 *)softback_in)
--- linux-2.4.10/drivers/video/hgafb.c	Tue Sep 25 10:15:12 2001
+++ scr-audit-2.4.10/drivers/video/hgafb.c	Sat Sep 29 19:30:08 2001
@@ -203,7 +203,7 @@
 		fillchar = 0x00;
 	spin_unlock_irqrestore(&hga_reg_lock, flags);
 	if (fillchar != 0xbf)
-		memset((char *)hga_vram_base, fillchar, hga_vram_len);
+		isa_memset_io(hga_vram_base, fillchar, hga_vram_len);
 }
 
 
@@ -275,11 +275,12 @@
 static void hga_show_logo(void)
 {
 	int x, y;
-	char *dest = (char *)hga_vram_base;
+	unsigned long dest = hga_vram_base;
 	char *logo = linux_logo_bw;
 	for (y = 134; y < 134 + 80 ; y++) /* this needs some cleanup */
 		for (x = 0; x < 10 ; x++)
-			*(dest + (y%4)*8192 + (y>>2)*90 + x + 40) = ~*(logo++);
+			isa_writeb(~*(logo++),
+				   (dest + (y%4)*8192 + (y>>2)*90 + x + 40));
 }
 #endif /* MODULE */	
 
--- linux-2.4.10/drivers/video/newport_con.c	Thu Sep 13 10:37:13 2001
+++ scr-audit-2.4.10/drivers/video/newport_con.c	Sat Sep 29 17:53:29 2001
@@ -379,7 +379,7 @@
 	int charattr;
 	unsigned char *p;
 
-	charattr = (*s >> 8) & 0xff;
+	charattr = (scr_readw(s) >> 8) & 0xff;
 
 	xpos <<= 3;
 	ypos <<= 4;
@@ -399,7 +399,7 @@
 				 NPORT_DMODE0_L32);
 
 	for (i = 0; i < count; i++, xpos += 8) {
-		p = &font_data[vc->vc_num][(s[i] & 0xff) << 4];
+		p = &font_data[vc->vc_num][(scr_readw(s++) & 0xff) << 4];
 
 		newport_wait();
 
--- linux-2.4.10/drivers/video/promcon.c	Mon Feb 19 10:37:00 2001
+++ scr-audit-2.4.10/drivers/video/promcon.c	Sat Sep 29 17:50:24 2001
@@ -51,27 +51,30 @@
 {
 	unsigned short *s = (unsigned short *)
 			(conp->vc_origin + py * conp->vc_size_row + (px << 1));
+	u16 cs;
 
+	cs = scr_readw(s);
 	if (px == pw) {
 		unsigned short *t = s - 1;
+		u16 ct = scr_readw(t);
 
-		if (inverted(*s) && inverted(*t))
-			return sprintf(b, "\b\033[7m%c\b\033[@%c\033[m",
-				       *s, *t);
-		else if (inverted(*s))
-			return sprintf(b, "\b\033[7m%c\033[m\b\033[@%c",
-				       *s, *t);
-		else if (inverted(*t))
-			return sprintf(b, "\b%c\b\033[@\033[7m%c\033[m",
-				       *s, *t);
+		if (inverted(cs) && inverted(ct))
+			return sprintf(b, "\b\033[7m%c\b\033[@%c\033[m", cs,
+				       ct);
+		else if (inverted(cs))
+			return sprintf(b, "\b\033[7m%c\033[m\b\033[@%c", cs,
+				       ct);
+		else if (inverted(ct))
+			return sprintf(b, "\b%c\b\033[@\033[7m%c\033[m", cs,
+				       ct);
 		else
-			return sprintf(b, "\b%c\b\033[@%c", *s, *t);
+			return sprintf(b, "\b%c\b\033[@%c", cs, ct);
 	}
 
-	if (inverted(*s))
-		return sprintf(b, "\033[7m%c\033[m\b", *s);
+	if (inverted(cs))
+		return sprintf(b, "\033[7m%c\033[m\b", cs);
 	else
-		return sprintf(b, "%c\b", *s);
+		return sprintf(b, "%c\b", cs);
 }
 
 static int
@@ -80,27 +83,30 @@
 	unsigned short *s = (unsigned short *)
 			(conp->vc_origin + py * conp->vc_size_row + (px << 1));
 	char *p = b;
+	u16 cs;
 
 	b += sprintf(b, "\033[%d;%dH", py + 1, px + 1);
 
+	cs = scr_readw(s);
 	if (px == pw) {
 		unsigned short *t = s - 1;
+		u16 ct = scr_readw(t);
 
-		if (inverted(*s) && inverted(*t))
-			b += sprintf(b, "\b%c\b\033[@\033[7m%c\033[m", *s, *t);
-		else if (inverted(*s))
-			b += sprintf(b, "\b%c\b\033[@%c", *s, *t);
-		else if (inverted(*t))
-			b += sprintf(b, "\b\033[7m%c\b\033[@%c\033[m", *s, *t);
+		if (inverted(cs) && inverted(ct))
+			b += sprintf(b, "\b%c\b\033[@\033[7m%c\033[m", cs, ct);
+		else if (inverted(cs))
+			b += sprintf(b, "\b%c\b\033[@%c", cs, ct);
+		else if (inverted(ct))
+			b += sprintf(b, "\b\033[7m%c\b\033[@%c\033[m", cs, ct);
 		else
-			b += sprintf(b, "\b\033[7m%c\033[m\b\033[@%c", *s, *t);
+			b += sprintf(b, "\b\033[7m%c\033[m\b\033[@%c", cs, ct);
 		return b - p;
 	}
 
-	if (inverted(*s))
-		b += sprintf(b, "%c\b", *s);
+	if (inverted(cs))
+		b += sprintf(b, "%c\b", cs);
 	else
-		b += sprintf(b, "\033[7m%c\033[m\b", *s);
+		b += sprintf(b, "\033[7m%c\033[m\b", cs);
 	return b - p;
 }
 
@@ -206,8 +212,9 @@
 	unsigned char *b = *bp;
 
 	while (cnt--) {
-		if (attr != inverted(*s)) {
-			attr = inverted(*s);
+		u16 c = scr_readw(s);
+		if (attr != inverted(c)) {
+			attr = inverted(c);
 			if (attr) {
 				strcpy (b, "\033[7m");
 				b += 4;
@@ -216,7 +223,8 @@
 				b += 3;
 			}
 		}
-		*b++ = *s++;
+		*b++ = c;
+		s++;
 		if (b - buf >= 224) {
 			promcon_puts(buf, b - buf);
 			b = buf;
@@ -246,9 +254,9 @@
 	if (x + count >= pw + 1) {
 		if (count == 1) {
 			x -= 1;
-			save = *(unsigned short *)(conp->vc_origin
+			save = scr_readw((unsigned short *)(conp->vc_origin
 						   + y * conp->vc_size_row
-						   + (x << 1));
+						   + (x << 1)));
 
 			if (px != x || py != y) {
 				b += sprintf(b, "\033[%d;%dH", y + 1, x + 1);
--- linux-2.4.10/drivers/video/sticon-bmode.c	Thu Sep 13 10:37:15 2001
+++ scr-audit-2.4.10/drivers/video/sticon-bmode.c	Sat Sep 29 17:50:24 2001
@@ -318,7 +318,7 @@
 	int count, int ypos, int xpos)
 {
 	while(count--) {
-		sti_putc(&default_sti, *s++, ypos, xpos++);
+		sti_putc(&default_sti, scr_readw(s++), ypos, xpos++);
 	}
 }
 
@@ -402,16 +402,6 @@
 	return 0;
 }
 
-static u16 *sticon_screen_pos(struct vc_data *conp, int offset)
-{
-	return NULL;
-}
-
-static unsigned long sticon_getxy(struct vc_data *conp, unsigned long pos, int *px, int *py)
-{
-	return 0;
-}
-
 static u8 sticon_build_attr(struct vc_data *conp, u8 color, u8 intens, u8 blink, u8 underline, u8 reverse)
 {
 	u8 attr = ((color & 0x70) >> 1) | ((color & 7));
@@ -440,11 +430,7 @@
 	con_set_palette:	sticon_set_palette,
 	con_scrolldelta:	sticon_scrolldelta,
 	con_set_origin: 	sticon_set_origin,
-	con_save_screen:	NULL,
 	con_build_attr:		sticon_build_attr,
-	con_invert_region:	NULL,
-	con_screen_pos:		sticon_screen_pos,
-	con_getxy:		sticon_getxy,
 };
 
 #include <asm/pgalloc.h>	/* need cache flush routines */
--- linux-2.4.10/drivers/video/sticon.c	Tue Dec  5 21:29:39 2000
+++ scr-audit-2.4.10/drivers/video/sticon.c	Sat Sep 29 17:50:24 2001
@@ -86,7 +86,7 @@
 	int count, int ypos, int xpos)
 {
 	while(count--) {
-		sti_putc(&default_sti, *s++, ypos, xpos++);
+		sti_putc(&default_sti, scr_readw(s++), ypos, xpos++);
 	}
 }
 
@@ -170,16 +170,6 @@
 	return 0;
 }
 
-static u16 *sticon_screen_pos(struct vc_data *conp, int offset)
-{
-	return NULL;
-}
-
-static unsigned long sticon_getxy(struct vc_data *conp, unsigned long pos, int *px, int *py)
-{
-	return 0;
-}
-
 static u8 sticon_build_attr(struct vc_data *conp, u8 color, u8 intens, u8 blink, u8 underline, u8 reverse)
 {
 	u8 attr = ((color & 0x70) >> 1) | ((color & 7));
@@ -208,11 +198,7 @@
 	con_set_palette:	sticon_set_palette,
 	con_scrolldelta:	sticon_scrolldelta,
 	con_set_origin: 	sticon_set_origin,
-	con_save_screen:	NULL,
 	con_build_attr:		sticon_build_attr,
-	con_invert_region:	NULL,
-	con_screen_pos:		sticon_screen_pos,
-	con_getxy:		sticon_getxy,
 };
 
 static int __init sti_init(void)
--- linux-2.4.10/drivers/video/tdfxfb.c	Thu Sep 13 08:41:26 2001
+++ scr-audit-2.4.10/drivers/video/tdfxfb.c	Sat Sep 29 17:50:25 2001
@@ -1088,27 +1088,27 @@
 			    struct display* p,
 			    const unsigned short *s,int count,int yy,int xx)
 {
-   u32 fgx,bgx;
-   fgx=attr_fgcol(p, *s);
-   bgx=attr_bgcol(p, *s);
+   u16 c = scr_readw(s);
+   u32 fgx = attr_fgcol(p, c);
+   u32 bgx = attr_bgcol(p, c);
    do_putcs( fgx,bgx,p,s,count,yy,xx );
 }
 static void tdfx_cfb16_putcs(struct vc_data* conp,
 			    struct display* p,
 			    const unsigned short *s,int count,int yy,int xx)
 {
-   u32 fgx,bgx;
-   fgx=((u16*)p->dispsw_data)[attr_fgcol(p,*s)];
-   bgx=((u16*)p->dispsw_data)[attr_bgcol(p,*s)];
+   u16 c = scr_readw(s);
+   u32 fgx = ((u16*)p->dispsw_data)[attr_fgcol(p, c)];
+   u32 bgx = ((u16*)p->dispsw_data)[attr_bgcol(p, c)];
    do_putcs( fgx,bgx,p,s,count,yy,xx );
 }
 static void tdfx_cfb32_putcs(struct vc_data* conp,
 			    struct display* p,
 			    const unsigned short *s,int count,int yy,int xx)
 {
-   u32 fgx,bgx;
-   fgx=((u32*)p->dispsw_data)[attr_fgcol(p,*s)];
-   bgx=((u32*)p->dispsw_data)[attr_bgcol(p,*s)];
+   u16 c = scr_readw(s);
+   u32 fgx = ((u32*)p->dispsw_data)[attr_fgcol(p, c)];
+   u32 bgx = ((u32*)p->dispsw_data)[attr_bgcol(p, c)];
    do_putcs( fgx,bgx,p,s,count,yy,xx );
 }
 
--- linux-2.4.10/drivers/video/vgacon.c	Thu Sep 13 10:37:16 2001
+++ scr-audit-2.4.10/drivers/video/vgacon.c	Sat Sep 29 17:50:25 2001
@@ -487,7 +487,7 @@
 	vga_video_num_columns = c->vc_cols;
 	vga_video_num_lines = c->vc_rows;
 	if (!vga_is_gfx)
-		scr_memcpyw_to((u16 *) c->vc_origin, (u16 *) c->vc_screenbuf, c->vc_screenbuf_size);
+		scr_memcpyw((u16 *) c->vc_origin, (u16 *) c->vc_screenbuf, c->vc_screenbuf_size);
 	return 0;	/* Redrawing not needed */
 }
 
@@ -978,7 +978,7 @@
 		c->vc_y = ORIG_Y;
 	}
 	if (!vga_is_gfx)
-		scr_memcpyw_from((u16 *) c->vc_screenbuf, (u16 *) c->vc_origin, c->vc_screenbuf_size);
+		scr_memcpyw((u16 *) c->vc_screenbuf, (u16 *) c->vc_origin, c->vc_screenbuf_size);
 }
 
 static int vgacon_scroll(struct vc_data *c, int t, int b, int dir, int lines)
--- linux-2.4.10/include/asm-alpha/vga.h	Fri Mar 17 22:01:38 2000
+++ scr-audit-2.4.10/include/asm-alpha/vga.h	Sat Sep 29 19:59:57 2001
@@ -12,7 +12,6 @@
 #define VT_BUF_HAVE_RW
 #define VT_BUF_HAVE_MEMSETW
 #define VT_BUF_HAVE_MEMCPYW
-#define VT_BUF_HAVE_MEMCPYF
 
 extern inline void scr_writew(u16 val, volatile u16 *addr)
 {
@@ -40,8 +39,6 @@
 
 /* Do not trust that the usage will be correct; analyze the arguments.  */
 extern void scr_memcpyw(u16 *d, const u16 *s, unsigned int count);
-#define scr_memcpyw_from scr_memcpyw
-#define scr_memcpyw_to   scr_memcpyw
 
 /* ??? These are currently only used for downloading character sets.  As
    such, they don't need memory barriers.  Is this all they are intended
--- linux-2.4.10/include/linux/vt_buffer.h	Thu Jan  4 23:51:24 2001
+++ scr-audit-2.4.10/include/linux/vt_buffer.h	Sat Sep 29 20:00:36 2001
@@ -26,9 +26,6 @@
 #define scr_memmovew(d, s, c) memmove(d, s, c)
 #define VT_BUF_HAVE_MEMCPYW
 #define VT_BUF_HAVE_MEMMOVEW
-#define scr_memcpyw_from(d, s, c) memcpy(d, s, c)
-#define scr_memcpyw_to(d, s, c) memcpy(d, s, c)
-#define VT_BUF_HAVE_MEMCPYF
 #endif
 
 #ifndef VT_BUF_HAVE_MEMSETW
@@ -61,22 +58,6 @@
 		while (count--)
 			scr_writew(scr_readw(--s), --d);
 	}
-}
-#endif
-
-#ifndef VT_BUF_HAVE_MEMCPYF
-static inline void scr_memcpyw_from(u16 *d, const u16 *s, unsigned int count)
-{
-	count /= 2;
-	while (count--)
-		*d++ = scr_readw(s++);
-}
-
-static inline void scr_memcpyw_to(u16 *d, const u16 *s, unsigned int count)
-{
-	count /= 2;
-	while (count--)
-		scr_writew(*s++, d++);
 }
 #endif
 

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

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[James S. <jsi...@tr...>]

> That said, i guess the problem here would be the same as for generic accels in
> the kernel, that is it will not go in. Most probably, a userland library would
> need to be created which could cooperate with the fbdev driver.

I agree. I think only support for hardware overlays should be. Most
hardware even for embedded devices support overlays. As for mpeg coding
that is a userland issue.

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Michel <mic...@ii...>]

Sven wrote:

> > I'm not sure - but what about having a support of hardware accelerated
> > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so
> > on)
> > Unfortunatelly I never saw any opensource project which has implementation
> > of such things but if you know how it should be implemented then such
> > extensions are gladly accepted too.
> 
> mmm, The Xv extension to X does this.

No, all it can do is colorspace conversion and scaling.

The brand new XvMC extension does this, the problem is the lack of
documentation. There is only one implementation for i81x (done by an Intel
employee) and no players support it yet.


> That said, i guess the problem here would be the same as for generic accels
> in the kernel, that is it will not go in. Most probably, a userland library
> would need to be created which could cooperate with the fbdev driver.

Like http://directfb.org ?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> But in this case fbdev will useless and meaningless toy which was
> born only for linux-logo :(

No, fbdev is required as a system console on many system ;
I _believe_ Geert wrote the original FB code so that some
m68k boxes may have a console. It's mandatory at least
on linux/mac68k and linux/*ppc...

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

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello, Romain!
On Fri, 28 Sep 2001 10:06:48 +0200, you wrote:

> Nick Kurshev wrote:
> 
> > I'm not sure - but what about having a support of hardware accelerated
> > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> > Unfortunatelly I never saw any opensource project which has implementation
> > of such things but if you know how it should be implemented then such extensions
> > are gladly accepted too.
> 
> I don't know how to, as I don't have knowledge of MPEG decoding, and
> the card I own can't do it anyway (maybe It can, but I don't have
> the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't
> answer my mail - I thought things were going well when they
> suddenly stopped to answer my mail...)
> 
> Anyway, I'm not sure adding all and every possible features
> to the FB driver will be seen kindly by those-in-charge
> (aka Linus T. and maybe Alan C.) I'm not even sure they'll
> agree on video overlay...
> 
But in this case fbdev will useless and meaningless toy which was
born only for linux-logo :(
But Linux-logo could be displayed through vesafb without native
drivers and NLS problems. Simply because after displaying logo
vesafb should be terminated.

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


Best regards! Nick

Re: [Linux-fbdev-devel] The future of framebuffer

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> These things could be handled by vesafb which can't be compiled as module.
> AFAIK VBE3.0 already have standardized such things as DGA, video extensions
> and even audio interface. Althrough exist cards which don't support VESA
> but such cards may not support graphics modes too.

Nope. All video card on Mac (m68k or PPC) are purely graphics
(no text mode), and none of them support directly VGA/VESA/
whatever from the x86 world. I'm sure there's similar
situation on other architecture.

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

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello, Sven!
On Fri, 28 Sep 2001 08:28:50 +0200, you wrote:

> On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote:
> > > Huh, why move all the fbdev out, the only thing you need to modularize is the
> > > fonts used, not the fbdev.
> > > 
> > Because it can be compiled independedly from kernel. Because it is like mini-X.
> > IMHO kernel should have only minimal part of drivers. (finely only set of drivers which
> > should be compiled into kernel for normal working) but such thing as framebuffer, audio
> > drivers and many other things could be safety moved from kernel out and be as satellite
> > projects.
> 
> Ah, but if you remove the fbdev from the kernel, many arches have no more
> console, in particular all those laking vga hardware.
> 
> Also you loose the hability to get the penguin logo at boot time, or any other
> graphic that is, which would be a shame.
> 
These things could be handled by vesafb which can't be compiled as module.
AFAIK VBE3.0 already have standardized such things as DGA, video extensions
and even audio interface. Althrough exist cards which don't support VESA
but such cards may not support graphics modes too.
> Finally, removing many dirvers from the kernel and having them as external
> projects is only asking for problems, incompatibilities and bugs. It is not a
> nice thing to do. 
> 
There may be incompatibility but only if linux internal interface is changed
but independed projects will not depend on it. Except case when major version of
linux will changed but this situation is similar to having different drivers
for Win95 and Win2000.
In addition it will give possibility to update such drivers without updating
the kernel and vice versa.
> > > BTW, can't we generate the fonts from the ones used by vgacon ?
> > > 
> > As I've found that linux doesn't contain character images except framebuffer's font files.
> > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system
> > DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of
> > X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly
> > from Linux with iconv functionallity.
> 
> Err, not sure i follow you here, but were are the dos.cpi info stored, in the
> vga card rom ? on the vfat filesystem ? in the bios ?
> 
On vfat. But IMHO each computer had preinstalled DOS as they have preinstalled Win9x now.
Anyway exist FreeDOS and other similar systems where such files could be taken.
> Friendly,
> 
> Sven Luther
> 


Best regards! Nick

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> I'm not sure - but what about having a support of hardware accelerated
> decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> Unfortunatelly I never saw any opensource project which has implementation
> of such things but if you know how it should be implemented then such extensions
> are gladly accepted too.

I don't know how to, as I don't have knowledge of MPEG decoding, and
the card I own can't do it anyway (maybe It can, but I don't have
the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't
answer my mail - I thought things were going well when they
suddenly stopped to answer my mail...)

Anyway, I'm not sure adding all and every possible features
to the FB driver will be seen kindly by those-in-charge
(aka Linus T. and maybe Alan C.) I'm not even sure they'll
agree on video overlay...

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

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Sven <lu...@dp...>]

On Fri, Sep 28, 2001 at 09:48:52AM +0400, Nick Kurshev wrote:
> Hello, Romain!
> On Thu, 27 Sep 2001 11:31:25 +0200, you wrote:
> 
> > Romain Dolbeau wrote:
> > 
> > > Still, I guess I should use them ; I think I could add
> > > a 'number of FOURCC supported' field in the
> > > "struct fb_vidoverlay_avail", and add (yet) another
> > > ioctl to get only the variable-length FOURCC list.
> > 
> > F-up myself, here's an updated file. The sample implementation
> > in pm3fb compile (not near thebox, can't test it yet :-)
> > 
> > Any comment/criticism/improvement/advice very much 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
> Well, it seems - o'k.
> I'm not sure - but what about having a support of hardware accelerated
> decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> Unfortunatelly I never saw any opensource project which has implementation
> of such things but if you know how it should be implemented then such extensions
> are gladly accepted too.

mmm, The Xv extension to X does this.

That said, i guess the problem here would be the same as for generic accels in
the kernel, that is it will not go in. Most probably, a userland library would
need to be created which could cooperate with the fbdev driver.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] The future of framebuffer

[Sven <lu...@dp...>]

On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote:
> > Huh, why move all the fbdev out, the only thing you need to modularize is the
> > fonts used, not the fbdev.
> > 
> Because it can be compiled independedly from kernel. Because it is like mini-X.
> IMHO kernel should have only minimal part of drivers. (finely only set of drivers which
> should be compiled into kernel for normal working) but such thing as framebuffer, audio
> drivers and many other things could be safety moved from kernel out and be as satellite
> projects.

Ah, but if you remove the fbdev from the kernel, many arches have no more
console, in particular all those laking vga hardware.

Also you loose the hability to get the penguin logo at boot time, or any other
graphic that is, which would be a shame.

Finally, removing many dirvers from the kernel and having them as external
projects is only asking for problems, incompatibilities and bugs. It is not a
nice thing to do. 

> > BTW, can't we generate the fonts from the ones used by vgacon ?
> > 
> As I've found that linux doesn't contain character images except framebuffer's font files.
> But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system
> DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of
> X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly
> from Linux with iconv functionallity.

Err, not sure i follow you here, but were are the dos.cpi info stored, in the
vga card rom ? on the vfat filesystem ? in the bios ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello, Sven!
On Thu, 27 Sep 2001 15:47:20 +0200, you wrote:

> On Thu, Sep 27, 2001 at 02:09:56PM +0400, Nick Kurshev wrote:
> > Hello, GOTO!
> > On Thu, 27 Sep 2001 18:25:19 +0900, you wrote:
> > 
> > > Hi, 
> > > 
> > > At Thu, 27 Sep 2001 09:59:52 +0400,
> > > Nick Kurshev <nic...@ma...> wrote:
> > > > > At Wed, 26 Sep 2001 12:40:47 +0400,
> > > > > Nick Kurshev <nic...@ma...> wrote:
> > > > > > 2. What about NLS support?
> > > > > > Since I have localized linux distribution - I can not read
> > > > > > any messages which is written not in English.
> > > > > 
> > > > > Is this console program or kernel issue?
> > > > > fbcon is ready for single byte characters, and
> > > > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > > > Also console-tools is becoming ready for single byte characters and
> > > > > UTF-8. But I've never seen multibyte characters with default
> > > > > terminal (with console-tools).
> > > > > 
> > > > > -- gotom
> > > > > 
> > > > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > > > Curently Linux has only english version of these files.
> > > 
> > > Right. Currently there is only ISO-8859-1 characters.
> > > Is it useful to add more characters for ISO-8859-x or
> > > KOI-8 people ?
> > > I'm interesting, but I don't know whether there are some demands or not.
> > > 
> > > But, adding more complex characters like EUC and ISO-2022
> > > is more difficult, because they are multibyte characters.
> > > Handling them is some more hack.
> > > Their character file is very big because their font have
> > > more than 30000. Full or partial UTF-8 support invites
> > > this problem. These days linux has large nls file in fs/nls,
> > > so I think it's ok, but someone complain about this issue...
> > > 
> > > -- gotom
> > > 
> > I guess - it's big problem. Indeed linux should has full collections
> > of different fonts. But it will make distributive too huge.
> > IMHO it would be better to move out such packages (like fbdev) from kernel
> 
> Huh, why move all the fbdev out, the only thing you need to modularize is the
> fonts used, not the fbdev.
> 
Because it can be compiled independedly from kernel. Because it is like mini-X.
IMHO kernel should have only minimal part of drivers. (finely only set of drivers which
should be compiled into kernel for normal working) but such thing as framebuffer, audio
drivers and many other things could be safety moved from kernel out and be as satellite
projects.

> BTW, can't we generate the fonts from the ones used by vgacon ?
> 
As I've found that linux doesn't contain character images except framebuffer's font files.
But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system
DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of
X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly
from Linux with iconv functionallity.
> Friendly,
> 
> Sven Luther
> 


Best regards! Nick

[Linux-fbdev-devel] Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello, Romain!
On Thu, 27 Sep 2001 11:31:25 +0200, you wrote:

> Romain Dolbeau wrote:
> 
> > Still, I guess I should use them ; I think I could add
> > a 'number of FOURCC supported' field in the
> > "struct fb_vidoverlay_avail", and add (yet) another
> > ioctl to get only the variable-length FOURCC list.
> 
> F-up myself, here's an updated file. The sample implementation
> in pm3fb compile (not near thebox, can't test it yet :-)
> 
> Any comment/criticism/improvement/advice very much 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
Well, it seems - o'k.
I'm not sure - but what about having a support of hardware accelerated
decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
Unfortunatelly I never saw any opensource project which has implementation
of such things but if you know how it should be implemented then such extensions
are gladly accepted too.

Best regards! Nick

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The future of framebuffer)

[James S. <jsi...@tr...>]

> I'll try to add some more explanations/comments and I'll commit the
> stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from
> regular pm3fb... and hope other drivers will follow ;-)

Great! I look forward to it.

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The future of framebuffer)

[<dol...@cl...>]

> I have no problem with it. This way it can evolve a little bit before it
> becomes part of the main stream.

I'll try to add some more explanations/comments and I'll commit the
stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from
regular pm3fb... and hope other drivers will follow ;-)

-- 
Romain DOLBEAU               |  Energy derives from both
ENS Cachan / Ker Lann        |    the plus and negative
Thesard IRISA / CAPS         |       -- Metallica
dol...@cl...    |        in 'Eye of the Beholder'

Re: [Linux-fbdev-devel] The future of framebuffer

[James S. <jsi...@tr...>]

> > > Is this console program or kernel issue?
> > > fbcon is ready for single byte characters, and
> > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > Also console-tools is becoming ready for single byte characters and
> > > UTF-8. But I've never seen multibyte characters with default
> > > terminal (with console-tools).
> > > 
> > > -- gotom
> > > 
> > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > Curently Linux has only english version of these files.
> 
> Right. Currently there is only ISO-8859-1 characters.
> Is it useful to add more characters for ISO-8859-x or
> KOI-8 people ?
> I'm interesting, but I don't know whether there are some demands or not.
> 
> But, adding more complex characters like EUC and ISO-2022
> is more difficult, because they are multibyte characters.
> Handling them is some more hack.
> Their character file is very big because their font have
> more than 30000. Full or partial UTF-8 support invites
> this problem. These days linux has large nls file in fs/nls,
> so I think it's ok, but someone complain about this issue...

The linux console is based VGA text hardware which can only do 8 bit fonts
and only display at most 512 different fonts. So the very backbone of the
console system is limited. I like to see this expanded for 2.5.X. The
framebuffer system could handle it very nicely. Just systems like MDA and
VGA couldn't. Now I don't advocate placing 10,000 characters in the
kernel. I do support have support for them and then having userland tools
that can load such font sets for use. 

[Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The future of framebuffer)

[James S. <jsi...@tr...>]

> BTW, what do the linux-console folks think of adding
> video overlay support to Ruby ?

I have no problem with it. This way it can evolve a little bit before it
becomes part of the main stream.