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

Re: [Linux-fbdev-devel] Radeonfb in 2.5.54bk

[Joshua K. <jo...@lu...>]

Latest patch? If it's the one you pushed to BK a day or two ago, that is
what I used in the compilation of my kernel. Hence it doesn't quite
work.

(to be precise, i issued:
bk clone http://linux.bkbits.net:8080/linux-2.5
bk -r get
bk pull http://fbdev.bkbits.net:8080/fbdev-2.5)

Anything wrong there? Do I have to bk -r get again?

Looks like I am subscribing to this list then. Sigh... too many lists to
take care of!! :(

Regards
Josh

Rabid cheeseburgers forced
James Simmons<jsi...@in...> to write this on Tue, 7 Jan 2003
22:26:09 +0000(GMT):	

> 
> > My 2.5.54 build instantly switches to the right res, 1024x768.
> > However I do see all the initial junk on the screen. Everything else
> > seems to work well, however. Does the initial junk show up on other
> > fb devices? The same junk would show up in 2.5.54 release but it
> > would switch resolutions and kill init.
> 
> Hm. I never ran into the intial junk stuff. I have had issues when
> going from vgacon at 80x30 to neofb at 160x48. The resize didn't
> change the data in struct vc_data. The latest patch shoudl fix that.
> 
> 
> 


-- 
Joshua Kwan
jo...@ms...
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
 
It's hard to keep your shirt on when you're getting something off your
chest.

[Linux-fbdev-devel] rotation.

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

I'm about to implement rotation which is needed for devices like the ipaq. 
The question is do we flip the xres and yres values depending on the 
rotation or do we just alter the data that will be drawn to make the 
screen appear to rotate. How does hardware rotate view the x and y axis?
Are they rotated or does just the data get rotated? 

Re: [Linux-fbdev-devel] fbmem.c : FBIOGETCMAP

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

> I can run the fb color map tests now if you had a
> chance to fix the code.
> 
> I am just running fbtest from the sourceforge fb cvs.

I'm CC the fbdev list because the fb color map code is a mess. I like to 
know what the best approach would be to clean it up.

FIrst the main bug. In fb_copy_cmap we should be testing to see if 
copy_from[to]_user fails. We don't. The other issue is for fb_copy_cmap
We handle memcpy, copy_from_user, and copy)to_user. Now in fb_set_cmap
we use get_user also without any checks. 

So we could have fb_copy_cmap keep handling all these issues and remove 
get_user from fb_set_cmap. We would just pass in fbcmap we got from 
fb_copy_cmap and pass into fb_set_cmap. The other approach is to 
remove copy_from_user in fb_copy_cmap and place it int fb_set_cmap. 

What do you think is the best approach to this?

Re: [Linux-fbdev-devel] Radeonfb in 2.5.54bk

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

> My 2.5.54 build instantly switches to the right res, 1024x768. However
> I do see all the initial junk on the screen. Everything else seems to
> work well, however. Does the initial junk show up on other fb devices?
> The same junk would show up in 2.5.54 release but it would switch resolutions
> and kill init.

Hm. I never ran into the intial junk stuff. I have had issues when going 
from vgacon at 80x30 to neofb at 160x48. The resize didn't change the data 
in struct vc_data. The latest patch shoudl fix that.

Re: [Linux-fbdev-devel] fb_imageblit()

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

> > I have a few questions and comments related to fb_imageblit().
> > 
> >  1. Why is the logo data in fb_image.data stored in an `unpacked' way? I.e.
> >     each byte of the logo data corresponds to one pixel of the image,
> >     irrespective of the depth of the image.
> > 
> I asked before what would be the content of the logo data and it was
> agreed that the logo data would either contain indices to the
> pseudo_palette for truecolor and directcolor or the pixel itself for the
> rest so it's consistent with the rest of the soft accel functions. 
> Fixing the minimum unit to one byte seems a reasonable compromise
> between maximum number of colors available and size of logo data.  Plus,
> it would be simpler to code.

I didn't realize that the data for the logo was unpacked. The imageblit 
blit function that I have written always assumes its packed data. This 
explains why sometimes I get weird effects. I don't mind if the logo image 
is restricked to 256 colors. Have a 65K color image would add alot fo 
bloat to the kernel image.

> >  2. If fb_image.depth == 1, how can fb_imageblit() distinguish between drawing
> >     a monochrome image (e.g. penguin logo) and color expanding a monochrome
> >     image (e.g. drawing text)? It's not possible to handle them the same, since
> >     image data for color expansion is packed, while image data for monochrome
> >     image drawing is not.
> I noticed this before but completely forgot about it because I have no
> monochrome graphics card to test :-)

> >     
> >     If monochrome image data would be packed as well, it could be handled by
> >     setting fb_image.fg_color = 1 and fb_image.bg_color = 0 (or vice versa for
> >     mono10), and fb_set_logo() becomes simpler as well.
> > 
> >     If we retain the unpacked data for images, we need some other flag to
> >     indicate color expansion. Perhaps setting fb_image.depth to 0?
> > 
> If we change the contents of the logo data, then it makes sense to pack
> the logo data also.  However, if we stick to indices, we might as well
> retain the "unpacked" 8-bit format.  I think setting fb_image.depth to 0
> to mean color expansion is more appropriate. Drivers that will need
> trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
> and of course cfb_imgblt.c, softcursor.c and fbcon.c.

The requirement I made of imageblit was to always use packed data. What 
the indices approach was to to always use a struct fb_cmap. This way it 
didn't matter if used a pseudocolor mode or a directcolor mode.

Re: [Linux-fbdev-devel] atyfb: 2.5.54

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

On Tue, 7 Jan 2003, James Simmons wrote:
> > Atyfb is known not to work on some Rage Mobility P/M (incl. the one in my Vaio
> > :-(
> 
> A have a few patchs for atyfb that I haven't got around to applying just 
> yet. One is Popov non BIOS patch for some cards. I have another patch for 
> a new DAC for older MACH 64 cards. The big issue I like to see solved is 
> to us ethe hardware cursor. Right now I have it disabled, its using 
> soft_cursor. I haven't had the time to look at teh specs for how the data 
> is layed out for the cursor image. We have in atyfb.h
> 
> struct aty_cursor {
> 	u8 bits[8][64];
> 	u8 mask[8][64];
> 	u8 *ram;
> }
> 
> This is really weird. I like to translate to the new api.

Each pixel in the Mach64 cursor has 4 possible values: transparent, inverting,
color0, or color1. It's size is 64x64, i.e. 64 rows of 8 bits per plane.

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

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

> > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > Personally, I don't think we need clipping.  I tried removing it before
> > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > var->yres_virtual.  I haven't tried this again with the newest
> > framebuffer framework though.
> 
> Any definitive answer on this?
> 
> What happens if you resize the VT to such a large size that columns*fontwidth >
> xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> crash there?

Correct. Actually fbcon_resize checks to make sure the user doesn't do 
something stupid like this. So we might not needed. Hm.

Re: [Linux-fbdev-devel] atyfb: 2.5.54

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

> Atyfb is known not to work on some Rage Mobility P/M (incl. the one in my Vaio
> :-(

A have a few patchs for atyfb that I haven't got around to applying just 
yet. One is Popov non BIOS patch for some cards. I have another patch for 
a new DAC for older MACH 64 cards. The big issue I like to see solved is 
to us ethe hardware cursor. Right now I have it disabled, its using 
soft_cursor. I haven't had the time to look at teh specs for how the data 
is layed out for the cursor image. We have in atyfb.h

struct aty_cursor {
	u8 bits[8][64];
	u8 mask[8][64];
	u8 *ram;
}

This is really weird. I like to translate to the new api.

Re: [Linux-fbdev-devel] atyfb: 2.5.54

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

On Tue, 7 Jan 2003, James Simmons wrote:
> > With 2.5.54 there is something like success with my hardware.
> > Now I get a cursor at the right position. I can't see what I type,
> > but I see the cursor moving correctly.
> > After unloading atyfb the console still behaves this way, nothing
> > changes.
> > 
> > Are there some options I should set ? I am currently just loading
> > atyfb (with recognizes my card as PCI although it's AGP; seen in dmesg).
> 
> Can do post your dmesg.

Atyfb is known not to work on some Rage Mobility P/M (incl. the one in my Vaio
:-(

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] atyfb: 2.5.54

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

> With 2.5.54 there is something like success with my hardware.
> Now I get a cursor at the right position. I can't see what I type,
> but I see the cursor moving correctly.
> After unloading atyfb the console still behaves this way, nothing
> changes.
> 
> Are there some options I should set ? I am currently just loading
> atyfb (with recognizes my card as PCI although it's AGP; seen in dmesg).

Can do post your dmesg.

Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

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

> Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
> anywhere in new code. And in old code it is there only because of passed
> data are only 16bit, not 32bit wide... With simple search&replace you can
> extend it to any size you want, as long as you'll not use sparse font
> bitmap.

The current "core" console code screen_buf layout is designed after VGA 
text mode. 16 bits which only 8 bits are used to represent a character, 9 
if you have high_fonts flag set. The other 8,7 bits are for attributes. 
This is very limiting and it does effect fbcon.c :-( I like to the console
system remove these awful limitation in the future. This why I like to see 
fbdev drivers avoid touching strings from the console layer.

Re: [Linux-fbdev-devel] Re: [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

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

> > > I'll be happier with character coordinates for text mode. 
> > 
> > Yuck!! Using fbcon for text modes is just bloat. For hardware text mode it 
> > is much better to write a nice small console driver like newport_con.c
> 
> When I said before christmas that I'll have to write matroxcon to get
> reasonable functionality, you laughed... Now, it is clear that there is
> no other way...

No I didn't laugh. I didn't like the idea of another fbcon like system 
being developed just to support this text mode. I have no problem with 
a matroxcon. 

> You can throw anything in and out, of course... It is GPL, after all.
> Only question left is whether I'll be satisfied with functionality you
> offer.

:-) I'm working on your driver the latest few days. I managed to shrink 
most of the accel code into one common base.I still have alot to go tho.
You have a matroxfb_check_var which makes my life much easier. 

Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

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

> Personally, that's fine by me since I have no need for those 2
> extensions.  But please apply the accel_putcs() buffer overrun patch.

Applied. 

> BTW, attached is another patch that will change the resolution of the
> console via tty ioctl TIOCSWINSZ.  I'm not sure if this is the correct
> solution, but it's the only one I can think of without really adding a
> lot of extra code.  This is implemented by adding a con_resize() hook to
> fbcon, so the window size can be changed such as by using:
>
> stty cols 128 rows 48 (1024x768 with font 8x16)

Yes this is the correct approach.
 
> The new window size should also be preserved per console.  Still, there
> are other fb parameters that can screw up the console (such as changing
> yres_virtual and bits_per_pixel) but the window size is the most
> important.

Updatevar in fbcon.c should handle yres_virtual properly. The scrolling 
code needs alot of work. It is a mess. Bits_per_pixel will be trickier to 
handle. 

[Linux-fbdev-devel] Re: 2.5.54: radeonfb almost works

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

> Just booting with video=radeon gives me a 640x400
> mode.  There's some initial garbage (looks like early boot
> messages converted to graphichs at the wrong resolution)
> on the screen, but that isn't a problem.  The low resolution
> is, though.

640x480 is normal. 

 
> I first tried "fbset 1280x1024-60", which changed
> the resolution, but the console was still a
> small 640x400 thing in the upper left corner of
> the 1280x1024 display.  Not very useful.

Because fbset is only useful for setting /dev/fb. You want to use stty
to set the resolution now. The advantage of this is we don't end up
with a console mode of 80 3/4 columns by 30 1/4 rows. 
Try

stty cols 160 rows 64 

assuming you are using 8x16 fonts.
 
> So I tried booting with video=radeon:1280x1024-32@60
> That gave me a blank screen, the monitor complained
> about "no signal".
> 
> But I logged in blind, and ran fbset 1280x1024-60
> again.  This gave me the console I want.
> 1280x1024 resolution, with 160x64 characters.

Sounds like a monitor timings issue. fbset cheats by taking
times from the /etc/fb.mods file. I'm working on patch 
that was sent to me to deal with this.

> Another problem comes up when running X.  Switching
> from X to some virtual console always gives me the
> "no signal" thing, and I have to type the fbset
> command blind before the console becomes
> visible.  Switching back to X is never a problem.

Same problem again. It is a monitor timings issue. 
We are working on this.

Re: [Linux-fbdev-devel] const fb_{fillrect,copyarea,image}?

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

On Tue, 7 Jan 2003, James Simmons wrote:
> > Wouldn't it make sense to make the fb_{fillrect,copyarea,image} parameters of
> > the fb_ops.fb_{fillrect,copyarea,image}() operations const? This would protect
> > us against side effects when reusing the fb_{fillrect,copyarea,image} structs
> > without reinitializing their contents (as is currently done by the logo drawing
> > code in fbcon_show_logo() on SMP).
> 
> Where is this exactly?

drivers/video/fbmem.c:fb_show_logo() initializes only image.dx in each loop
iteration:

| for (x = 0; x < num_online_cpus() * (LOGO_W + 8) &&
|      x < info->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
|         image.dx = x;
|         info->fbops->fb_imageblit(info, &image);
|         done = 1;
| }

> > Of course this means that we have to modify the clipping code, which currently
> > just modifies the passed structure.
> 
> :-( That is done to prevent someone from passing data that is larger than 
> the framebuffer.

You can still do clipping without modifying the passed structure, right?

BTW, is it possible that someone passes data that is larger (except for bugs)?
We have control over what happens in the kernel. Data passed from userspace is
a different issue, of course.

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] const fb_{fillrect,copyarea,image}?

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

> Wouldn't it make sense to make the fb_{fillrect,copyarea,image} parameters of
> the fb_ops.fb_{fillrect,copyarea,image}() operations const? This would protect
> us against side effects when reusing the fb_{fillrect,copyarea,image} structs
> without reinitializing their contents (as is currently done by the logo drawing
> code in fbcon_show_logo() on SMP).

Where is this exactly?

> Of course this means that we have to modify the clipping code, which currently
> just modifies the passed structure.

:-( That is done to prevent someone from passing data that is larger than 
the framebuffer.

Re: [Linux-fbdev-devel] Mirrored Display?

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

> > I'm know a litte bit amazed about a rotation feature in next versions. Does 
> > this mean, that the buffer where user apps (or also the console) are writing 
> > there picture data is not directly the videobuffer anymore? Or how does this 
> > rotation feature works?
> I think the rotation hooks are console specific.  

Actually the low level drivers can use the hooks.

Re: [Linux-fbdev-devel] clipping

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

On 3 Jan 2003, Antonino Daplas wrote:
> On Mon, 2002-12-30 at 05:21, Geert Uytterhoeven wrote:
> > cfb_imageblit() takes care of clipping, but forgets to update fb_image.data if
> > fb_image.d[xy] was changed.
> > 
> > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> Personally, I don't think we need clipping.  I tried removing it before
> (circa linux-2.5.30+), but the console segfaults whenever I decrease
> var->yres_virtual.  I haven't tried this again with the newest
> framebuffer framework though.

Any definitive answer on this?

What happens if you resize the VT to such a large size that columns*fontwidth >
xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
crash there?

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: [PATCH]: image.depth fix to accomodate monochrome cards

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

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

[Linux-fbdev-devel] [PATCH]: image.depth fix to accomodate monochrome cards

[Antonino D. <ad...@po...>]

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

[Linux-fbdev-devel] Radeonfb in 2.5.54bk

[Joshua M. K. <jo...@lu...>]

I read Helge's message in the fbdev archives and decided to put my 2c in
regarding my experience with radeonfb in 2.5.54.

My 2.5.54 build instantly switches to the right res, 1024x768. However
I do see all the initial junk on the screen. Everything else seems to
work well, however. Does the initial junk show up on other fb devices?
The same junk would show up in 2.5.54 release but it would switch resolutions
and kill init.

But it's definitely come a long way! Great work.

Regards
-Josh

Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size

[Antonino D. <ad...@po...>]

On Tue, 2003-01-07 at 06:27, James Simmons wrote:

> 
> > This approach has one major problem though.  In the 2.4 interface, we
> > have fbset that basically "assists" fbdev with the changes.  The fbset
> > utility will fill up fb_var_screeninfo with correct information such as
> > video timings from /etc/fb.modes.  
> 
> I neved like the idea of fb.modes. We should be asking the hardware are 
> selves instead.Yes there are cases of really old hardware that lack this. 
> I think the below code will be usefull for these cases.
>  
That's true.  The VBEInfoBlock struct contains a far pointer to a list
of video modes supported, standard VESA DMT modes and OEM-specific
modes.  This is function 0x4F00 of VBE which unfortunately is accessible
only in 16-bit mode.  Maybe the EDID block also contains such
information?

Also, if the user wants to control the refresh rate, or use nonstandard
video modes, there's no choice but to have the timings generated even
for new hardware.  That's where the GTF is useful.

> > So, what's needed is a function that calculates timing parameters which
> > is generic enough to work with the most common monitors.  One solution
> > is to use VESA's GTF (Generalized Timing Formula).  Attached is a patch
> > that implements the formula.
> 
> Great!!!!
> 
> > The timings generated by GTF are different from the standard VESA
> > timings (DMT).  However, it should work for GTF compliant monitors and
> > is also specifically formulated to work with older monitors as well. 
> > Another advantage is that it can calculate the timings for any video
> > mode. It may not work for proprietary displays or TV displays.
> > 
> > One requirement of the GTF is that the monitor specs must be known, ie
> > info->monspecs must be valid.  This can be filled up several ways:
> > 
> > 1. VBE/DDC and EDID parsing (I see the beginnings of it already in
> > fbmon.c)
> 
> Yeap. We can parse the EDID block for data about the limits of your 
> monitor!!! 
> 
> > 2. entered as a boot/module option
> 
> Yuck! But I don't see much of a choose for modular drivers.

We do need to have the monitor's operational limits uploaded whatever
way and as early as possible so the user can boot to a high resolution
immediately.  Using VBE/DDC and parsing the EDID block may not work with
new, but cheap monitors.  I have one such monitor that is supposed to
support DDC2 but spits out a useless EDID block.  So passing it as a
boot option may be useful.  This is similar to XFree86 falling back to
/etc/X11/XF86Config's 'HorizSync' and 'VertRefresh' when the EDID info
is not available.

>  
> > 3. ?ioctl to upload monitor info to fbdev.
> > 
> > (As a side note, should we also add pixclock_min and pixclock_max to
> > info->monspecs?).
> 
> ioctl already exist for this. The only issue is fb_monspec good enough for 
> our needs.
> 
What's the ioctl by the way?

The GTF only requires xres, yres and one of the three:

horizontal scan rate
vertical refresh rate
pixelclock.

in order to generate timings. So adding minimum and maximum pixelclock
fields in info->monspecs will be useful.  Otherwise the GTF may generate
a pixelclock that is outside the graphics card's/monitor's capability. 

Secondly, the GTF function assumes the following:

hsync_len = 8% of htotal
left_margin = 1/2 of inactive frame length
right margin = remainder of htotal

vsync_len = 3
lower_margin = 1
upper margin = remainder of vtotal.

Anyway, the most critical part when computing timings information is the
inactive frame length (htotal - xres, vtotal - yres), which is hblank
and vblank in the fb_get_mode() function.

Finally, some of the fixed numbers I used in the GTF function is
supposedly for a monitor with US specifications:

#define FLYBACK                     550
#define V_FRONTPORCH                1
#define H_OFFSET                    40
#define H_SCALEFACTOR               20
#define H_BLANKSCALE                128
#define H_GRADIENT                  600

I'm not even sure about the meaning of some of them :-). We can add them
in the future if the above assumptions need to be changed.

Tony

PS:  The GTF patch is erroneous.  hfmin and hfmax must be in Hz and the 
boolean logic is incorrect.

diff -Naur linux-2.5.54/drivers/video/modedb.c linux/drivers/video/modedb.c
--- linux-2.5.54/drivers/video/modedb.c	2003-01-06 13:34:50.000000000 +0000
+++ linux/drivers/video/modedb.c	2003-01-07 03:29:59.000000000 +0000
@@ -547,10 +547,10 @@
 	 * If monspecs are invalid, use values that are enough
 	 * for 640x480@60
 	 */
-	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
 	    info->monspecs.hfmax < info->monspecs.hfmin ||
 	    info->monspecs.vfmax < info->monspecs.vfmin) {
-		hfmin = 29; hfmax = 30;
+		hfmin = 29000; hfmax = 30000;
 		vfmin = 60; vfmax = 60;
 	} else {
 		hfmin = info->monspecs.hfmin;
@@ -628,10 +628,10 @@
 	 * If monspecs are invalid, use values that are enough
 	 * for 640x480@60
 	 */
-	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
 	    info->monspecs.hfmax < info->monspecs.hfmin ||
 	    info->monspecs.vfmax < info->monspecs.vfmin) {
-		hfmin = 29; hfmax = 30;
+		hfmin = 29000; hfmax = 30000;
 		vfmin = 60; vfmax = 60;
 	} else {
 		hfmin = info->monspecs.hfmin;

[Linux-fbdev-devel] Re: [BK FBDEV updates]

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

> >>>>> "James" == James Simmons <jsi...@in...> writes:
> 
> James> Linus, please do a
> James> 	bk pull http://fbdev.bkbits.net:8080/fbdev-2.5
> James> This will update the following files:
> 
> James,
> 
> You seem to have forgotten to include the unified diff in your posting
> posting to the list. Would you mind putting it somewhere.

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

[Linux-fbdev-devel] Re: [BK FBDEV updates]

[Jes S. <je...@tr...>]

>>>>> "James" == James Simmons <jsi...@in...> writes:

James> Linus, please do a
James> 	bk pull http://fbdev.bkbits.net:8080/fbdev-2.5
James> This will update the following files:

James,

You seem to have forgotten to include the unified diff in your posting
posting to the list. Would you mind putting it somewhere.

Thanks,
Jes

[Linux-fbdev-devel] [BK FBDEV updates]

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

Linus, please do a

	bk pull http://fbdev.bkbits.net:8080/fbdev-2.5

This will update the following files:

 include/video/font.h            |   24
 arch/m68k/kernel/m68k_defs.c    |    2
 drivers/video/Makefile          |    3
 drivers/video/aty/atyfb_base.c  |    4
 drivers/video/console/fbcon.c   |   90 +-
 drivers/video/console/sticon.c  |   40 -
 drivers/video/console/sticore.c |    8
 drivers/video/fbmem.c           |    1
 drivers/video/i810/i810.h       |    2
 drivers/video/i810/i810_accel.c |   11
 drivers/video/i810/i810_dvt.c   |    2
 drivers/video/i810/i810_main.c  |   51 -
 drivers/video/i810/i810_main.h  |   79 --
 drivers/video/riva/Makefile     |    2
 drivers/video/riva/fbdev.c      | 1468 +++++++++++++++++++---------------------
 drivers/video/riva/nv_driver.c  |  212 +++++
 drivers/video/riva/riva_hw.c    |  350 +++++++--
 drivers/video/riva/rivafb.h     |   15
 drivers/video/sstfb.c           |  707 +++++++++----------
 drivers/video/sstfb.h           |   31
 include/linux/font.h            |   30
 21 files changed, 1725 insertions(+), 1407 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/01/06 1.972)
   [RIVA FBDEV] Driver now uses its own fb_open and fb_release function again.
   It has no ill effects. The drivers uses strickly hardware acceleration
   so we don't need cfb_fillrect and cfb_copyarea.

   Cleaned up font.h. Geerts orignal pacth broke them up into a font.h in
   video and one in linux. Now I put them back together again in
   include/linux. The m68k platform has been updated for this change.

<jsi...@ma...> (03/01/06 1.971)
   Added resize support for the framebuffer console. Now you can change the
   console size via stty. Also support for color palette changing on VC
   switch is supported.

<jsi...@ma...> (03/01/06 1.970)
   I810 fbdev updates. Cursor fix for ati mach 64 cards on big endian machines.
   Buffer over flow fix for fbcon putcs function. C99 initializers for the
   STI console drivers. Voodoo 1/2 and NVIDIA driver updates.