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

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel

[Petr V. <VAN...@vc...>]

On  7 May 02 at 21:26, Antonino Daplas wrote:
> > And set_par() could do some optimizations based on a shadow map of the register
> > contents, also to avoid artefacts when switching to a different VC with the
> > same video timings. Like:
> > 
> >   write_reg(reg, val)
> >   {
> >       if (shadow[reg] != val) {
> >   shadow[reg] = val;
> >   hardware[reg] = val;
> >       }
> >   }

I was doing that long ago in matroxfb, and it simple does not work :-(
There is too many applications which programs video hardware directly.
So currently matroxfb always reprogram most of registers, and for
critical ones (PLL) it reads back value from hardware, and not from some
shadow area. Speed difference is invisible and reliability is much better.
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...
                                                     

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

On Tue, 2002-05-07 at 16:00, Geert Uytterhoeven wrote:
> > I was talking of X running with it's own accelerated drivers.  I have
> > checked most of the X accelerated drivers, and most will just attempt to
> > restore the VGA registers and some when switching to the console.  I
> > think this is not just enough, since fb drivers require more than that. 
> 
> If you run an application that's not fbdev aware, behavior has always been
> undefined.
> 

In the same token, then the kernel should be made as robust as
possible.  I would rather have a user app crash than have it lock-up the
hardware or corrupt the display.
 
> > Simiarly, I have also looked at some of the fbdev drivers that are not
> > using the gen_* interface (nvidia, ati, matrox), and they will also
> > unconditially set the hardware during switches/set_var. The
> > fbgen_switch() function also calls fbhw->set_par() within do_set_var().
> 
> And set_par() could do some optimizations based on a shadow map of the register
> contents, also to avoid artefacts when switching to a different VC with the
> same video timings. Like:
> 
>   write_reg(reg, val)
>   {
>       if (shadow[reg] != val) {
> 	shadow[reg] = val;
> 	hardware[reg] = val;
>       }
>   }
> 

Actually, What I'm trying to point out is that gen_set_var() is not even
given a chance to call set_par().  If the generic interface is to be
adopted, it has to satisfy the requirements of most, if not all cards.

My current thinking is to let gen_set_var() call set_par()
unconditionally and at the same time pass a parameter or set a flag.
This flag or parameter can be something like, "yes, you really need to
set the hardware" or "no, var has not changed but you have the option to
set the hardware or not." Something to this effect:

if (memcmp(oldvar, newvar, sizeof(struct fb_var_screeninfo)))
	info->fbops->fb_set_par(info, 1);
else 
	info->fbops->fb_set_par(info, 0);

> > I think if the gen_* interface is to be adopted, it will become a
> > problem. Detection is the best solution, but right now X and DRI do not
> > know that fb even exist so we can't get X to detect fb unless we
> > persuade the X people to do that.  I have tried X detection before by
> > checking the previous console number.  If the previous number is not a
> > valid console, we can presume that a non-console app used that.  But
> > this is not clean and there are too many conditions where this check
> > will fail. But then, I really don't understand the underlying console
> > interface, so an easier and more effective way may exist that I don't
> > know about.
> 
> The problem is that most drivers in XFree86 don't _want_ to be fbdev compliant.
> The solution is to convince the hardcode anti-fbdev XFree86 guys to use the

I can't agree with you more.  When I was writing the i810/i815 fb
driver, I also modified the XFree86 i810 driver so it is fbdev-aware.
The "fbdev-awareness" is not a requirement, but it solves a lot of
problems and lessened code bloat.

But as you've said, they're hardcore :)

> fbdev if it's present. Fbdev is part of the kernel API. Circumventing the API
> is bad behavior.
> 

Which is why I abandoned that idea. 

Tony

[Linux-fbdev-devel] fbcon_show_logo using imageblit

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

Hi,

I was trying to test the imageblit function to draw images, and while
doing that, I thought maybe I can use the fbcon_show_logo function for
testing.  I copied fbcon_show_logo as fbcon_show_logo_accel and slightly
modified the code so it uses imageblit instead. I only included
truecolor and psuedocolor at 8bpp since I don't have the hardware to
test other formats.

The code is probably suboptimal, but I would like to know if the
concept/format for using imageblit is correct. It does work on testing
though.

I included a diff for 2.5.13 + fbdev_fixs.diff (James Simmons).

Tony

--- fbcon.c.orig	Tue May  7 20:53:04 2002
+++ fbcon.c	Tue May  7 21:04:20 2002
@@ -215,6 +215,9 @@
 			    int height, int width, u_int y_break);
 
 static int fbcon_show_logo(void);
+#ifdef CONFIG_FBCON_ACCEL
+static int fbcon_show_logo_accel(void);
+#endif
 
 #ifdef CONFIG_MAC
 /*
@@ -1541,6 +1544,9 @@
 	p->dispsw->clear_margins(conp, p, 0);
     if (logo_shown == -2) {
 	logo_shown = fg_console;
+#ifdef CONFIG_FBCON_ACCEL
+	if (!(fbcon_show_logo_accel()))
+#endif
 	fbcon_show_logo(); /* This is protected above by initmem_freed */
 	update_region(fg_console,
 		      conp->vc_origin + conp->vc_size_row * conp->vc_top,
@@ -2447,6 +2453,143 @@
 
     return done ? (LOGO_H + fontheight(p) - 1) / fontheight(p) : 0 ;
 }
+
+#ifdef CONFIG_FBCON_ACCEL
+static int __init fbcon_show_logo_accel( void )
+{
+	struct display *p = &fb_display[fg_console]; /* draw to vt in foreground */
+	struct fb_image image;
+	int depth = p->var.bits_per_pixel;
+	unsigned char *logo;
+	unsigned char *dst, *src = 0, *data, *dat;
+	int i, j, n, x1, y1, x = 0;
+	int logo_depth, done = 0;
+	
+	if (!(p->fb_info->fbops->fb_imageblit))
+		return 0;
+	dat = (u8 *) (vmalloc(LOGO_W * LOGO_H * ((depth + 7) >> 3)));
+	if (dat == NULL) 
+		return 0;
+	data = dat;
+	/*
+	 * Set colors if visual is PSEUDOCOLOR and we have enough colors, or for
+	 * DIRECTCOLOR
+	 * We don't have to set the colors for the 16-color logo, since that logo
+	 * uses the standard VGA text console palette
+	 */
+	if ((p->visual == FB_VISUAL_PSEUDOCOLOR && depth >= 8) ||
+	    (p->visual == FB_VISUAL_DIRECTCOLOR && depth >= 24))
+		for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
+			n = LINUX_LOGO_COLORS - i;
+			if (n > 16)
+				/* palette_cmap provides space for only 16 colors at once */
+				n = 16;
+			palette_cmap.start = 32 + i;
+			palette_cmap.len   = n;
+			for( j = 0; j < n; ++j ) {
+				palette_cmap.red[j]   = (linux_logo_red[i+j] << 8) |
+					linux_logo_red[i+j];
+				palette_cmap.green[j] = (linux_logo_green[i+j] << 8) |
+					linux_logo_green[i+j];
+				palette_cmap.blue[j]  = (linux_logo_blue[i+j] << 8) |
+					linux_logo_blue[i+j];
+			}
+			p->fb_info->fbops->fb_set_cmap(&palette_cmap, 1, fg_console,
+						       p->fb_info);
+		}
+	
+	if (depth >= 8) {
+		logo = linux_logo;
+		logo_depth = 8;
+	}
+	else if (depth >= 4) {
+		logo = linux_logo16;
+		logo_depth = 4;
+	}
+	else {
+		logo = linux_logo_bw;
+		logo_depth = 1;
+	}
+	
+	if (p->fb_info->fbops->fb_rasterimg)
+		p->fb_info->fbops->fb_rasterimg(p->fb_info, 1);
+	
+#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
+    defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
+	if ((depth % 8 == 0) && (p->visual == FB_VISUAL_TRUECOLOR)) {
+	    /* Modes without color mapping, needs special data transformation... */
+		unsigned int val;		/* max. depth 32! */
+		int bdepth = depth/8;
+		unsigned char redmask, greenmask, bluemask;
+		int redshift, greenshift, blueshift;
+		unsigned char mask[9] = { 0,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe,0xff };
+		
+		/* Bug: Doesn't obey msb_right ... (who needs that?) */
+		redmask   = mask[p->var.red.length   < 8 ? p->var.red.length   : 8];
+		greenmask = mask[p->var.green.length < 8 ? p->var.green.length : 8];
+		bluemask  = mask[p->var.blue.length  < 8 ? p->var.blue.length  : 8];
+		redshift   = p->var.red.offset   - (8-p->var.red.length);
+		greenshift = p->var.green.offset - (8-p->var.green.length);
+		blueshift  = p->var.blue.offset  - (8-p->var.blue.length);
+		
+		src = logo;
+		for( y1 = 0; y1 < LOGO_H; y1++ ) {
+			dst = data + y1*LOGO_W*bdepth;
+			for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
+				val = safe_shift((linux_logo_red[*src-32]   & redmask), redshift) |
+					safe_shift((linux_logo_green[*src-32] & greenmask), greenshift) |
+					safe_shift((linux_logo_blue[*src-32]  & bluemask), blueshift);
+				if (bdepth == 4 && !((long)dst & 3)) {
+					/* Some cards require 32bit access */
+					fb_writel (val, dst);
+					dst += 4;
+				} else if (bdepth == 2 && !((long)dst & 1)) {
+					/* others require 16bit access */
+					fb_writew (val,dst);
+					dst +=2;
+				} else {
+#ifdef __LITTLE_ENDIAN
+					for( i = 0; i < bdepth; ++i )
+#else
+					for( i = bdepth-1; i >= 0; --i )
+#endif
+						fb_writeb (val >> (i*8), dst++);
+				}
+			}
+		}
+		done = 1;
+	}
+#endif
+#if defined(CONFIG_FBCON_CFB8) || defined(CONFIG_FB_SBUS)
+	if (depth == 8 && p->type == FB_TYPE_PACKED_PIXELS) {
+		/* depth 8 or more, packed, with color registers */
+		data = logo;
+		done = 1;
+	}
+#endif
+	if (done) {
+		image.dy = 0;
+		image.height = LOGO_H;
+		image.width = LOGO_W;
+		image.depth = depth;
+		image.data = data;
+		for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
+			     x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
+			image.dx = x;
+			p->fb_info->fbops->fb_imageblit(p->fb_info, &image);
+		}
+	}
+	vfree(dat);
+	
+	if (p->fb_info->fbops->fb_rasterimg)
+		p->fb_info->fbops->fb_rasterimg(p->fb_info, 0);
+	
+    /* Modes not yet supported: packed pixels with depth != 8 (does such a
+     * thing exist in reality?) */
+	
+	return done ? (LOGO_H + fontheight(p) - 1) / fontheight(p) : 0 ;
+}
+#endif
 
 /*
  *  The console `switch' structure for the frame buffer based console

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

On 7 May 2002, Antonino Daplas wrote:
> On Tue, 2002-05-07 at 06:24, Michel D=E4nzer wrote:
> > On Sat, 2002-05-04 at 20:01, Antonino Daplas wrote:=20
> > > On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> > > >=20
> > > > > I have a few observations on fbgen and fbcon-accel.
> > >=20
> > > One more thing I've noticed with gen_set_var.  Basically, gen_set_v=
ar
> > > will proceed if it satisfies 2 conditions -- during initialization =
(con
> > > < 0) and if the new var is different from the old var. =20
> > >=20
> > > The above is fine if everything is done in the console.  However,
> > > problems may arise if an app that touches the graphics hardware (ie=
 X)
> > > is launched.  From the point of view of fbcon, the hardware state h=
asn't
> > > changed (compare of newvar with oldvar is false) when display is
> > > switched back to console.  And if that app did not fully restore th=
e
> > > hardware state,  we will be left with a corrupted display.
> > >=20
> > > So, it's probably better if set_par() and pan_display() are allowed=
 to
> > > proceed unconditionally within gen_set_var.  It might take a few mo=
re
> > > milliseconds to switch consoles each time, but we are assured that =
the
> > > hardware state is always coherent with the current var.

Which can be visible, especially if you reprogram the PLL...

> > > What do you think?
> >=20
> > I think this is giving away an advantage. The X server is a bad examp=
le
> > as it can use the framebuffer device fine.

Indeed.

> I was talking of X running with it's own accelerated drivers.  I have
> checked most of the X accelerated drivers, and most will just attempt t=
o
> restore the VGA registers and some when switching to the console.  I
> think this is not just enough, since fb drivers require more than that.=
=20

If you run an application that's not fbdev aware, behavior has always bee=
n
undefined.

> Simiarly, I have also looked at some of the fbdev drivers that are not
> using the gen_* interface (nvidia, ati, matrox), and they will also
> unconditially set the hardware during switches/set_var. The
> fbgen_switch() function also calls fbhw->set_par() within do_set_var().

And set_par() could do some optimizations based on a shadow map of the re=
gister
contents, also to avoid artefacts when switching to a different VC with t=
he
same video timings. Like:

  write_reg(reg, val)
  {
      if (shadow[reg] !=3D val) {
	shadow[reg] =3D val;
	hardware[reg] =3D val;
      }
  }

> > If it's really a problem, maybe we could figure out a way to detect w=
hen
> > it's safe to optimize stuff away or as a last resort make it an optio=
n?
> >=20
> I think if the gen_* interface is to be adopted, it will become a
> problem. Detection is the best solution, but right now X and DRI do not
> know that fb even exist so we can't get X to detect fb unless we
> persuade the X people to do that.  I have tried X detection before by
> checking the previous console number.  If the previous number is not a
> valid console, we can presume that a non-console app used that.  But
> this is not clean and there are too many conditions where this check
> will fail. But then, I really don't understand the underlying console
> interface, so an easier and more effective way may exist that I don't
> know about.

The problem is that most drivers in XFree86 don't _want_ to be fbdev comp=
liant.
The solution is to convince the hardcode anti-fbdev XFree86 guys to use t=
he
fbdev if it's present. Fbdev is part of the kernel API. Circumventing the=
 API
is bad behavior.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

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] Comments on fbgen.c and fbcon-accel.c

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

On Tue, 2002-05-07 at 06:24, Michel D=E4nzer wrote:
> On Sat, 2002-05-04 at 20:01, Antonino Daplas wrote:=20
> > On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> > >=20
> > > > I have a few observations on fbgen and fbcon-accel.
> >=20
> > One more thing I've noticed with gen_set_var.  Basically, gen_set_var
> > will proceed if it satisfies 2 conditions -- during initialization (con
> > < 0) and if the new var is different from the old var. =20
> >=20
> > The above is fine if everything is done in the console.  However,
> > problems may arise if an app that touches the graphics hardware (ie X)
> > is launched.  From the point of view of fbcon, the hardware state hasn'=
t
> > changed (compare of newvar with oldvar is false) when display is
> > switched back to console.  And if that app did not fully restore the
> > hardware state,  we will be left with a corrupted display.
> >=20
> > So, it's probably better if set_par() and pan_display() are allowed to
> > proceed unconditionally within gen_set_var.  It might take a few more
> > milliseconds to switch consoles each time, but we are assured that the
> > hardware state is always coherent with the current var.
> >=20
> > What do you think?
>=20
> I think this is giving away an advantage. The X server is a bad example
> as it can use the framebuffer device fine.
I was talking of X running with it's own accelerated drivers.  I have
checked most of the X accelerated drivers, and most will just attempt to
restore the VGA registers and some when switching to the console.  I
think this is not just enough, since fb drivers require more than that.=20
Simiarly, I have also looked at some of the fbdev drivers that are not
using the gen_* interface (nvidia, ati, matrox), and they will also
unconditially set the hardware during switches/set_var. The
fbgen_switch() function also calls fbhw->set_par() within do_set_var().
>=20
> If it's really a problem, maybe we could figure out a way to detect when
> it's safe to optimize stuff away or as a last resort make it an option?
>=20
I think if the gen_* interface is to be adopted, it will become a
problem. Detection is the best solution, but right now X and DRI do not
know that fb even exist so we can't get X to detect fb unless we
persuade the X people to do that.  I have tried X detection before by
checking the previous console number.  If the previous number is not a
valid console, we can presume that a non-console app used that.  But
this is not clean and there are too many conditions where this check
will fail. But then, I really don't understand the underlying console
interface, so an easier and more effective way may exist that I don't
know about.

Tony

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

[Michel <mi...@da...>]

On Sat, 2002-05-04 at 20:01, Antonino Daplas wrote:=20
> On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> >=20
> > > I have a few observations on fbgen and fbcon-accel.
>=20
> One more thing I've noticed with gen_set_var.  Basically, gen_set_var
> will proceed if it satisfies 2 conditions -- during initialization (con
> < 0) and if the new var is different from the old var. =20
>=20
> The above is fine if everything is done in the console.  However,
> problems may arise if an app that touches the graphics hardware (ie X)
> is launched.  From the point of view of fbcon, the hardware state hasn't
> changed (compare of newvar with oldvar is false) when display is
> switched back to console.  And if that app did not fully restore the
> hardware state,  we will be left with a corrupted display.
>=20
> So, it's probably better if set_par() and pan_display() are allowed to
> proceed unconditionally within gen_set_var.  It might take a few more
> milliseconds to switch consoles each time, but we are assured that the
> hardware state is always coherent with the current var.
>=20
> What do you think?

I think this is giving away an advantage. The X server is a bad example
as it can use the framebuffer device fine.

If it's really a problem, maybe we could figure out a way to detect when
it's safe to optimize stuff away or as a last resort make it an option?


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

[Linux-fbdev-devel] 2.5.14 oops in fb_copy_cmap

[Greg KH <gr...@kr...>]

I get the oops below at boot time if "vga=0x0305" is on the command
line.  If I take it off, I can boot just fine.

CONFIG_FB sections in my .config are:
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=y
CONFIG_VIDEO_SELECT=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_VGA_PLANES=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

More info or debugging can be done if requested.

thanks,

greg k-h


ksymoops 2.4.5 on i686 2.5.14.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.14/ (default)
     -m /boot/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000040
c01d6806
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01d6806>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: c027222c   ebx: 00000020   ecx: 00000008   edx: 00000000
esi: c02e1a40   edi: 00000040   ebp: 00000040   esp: cfe63e08
ds: 0018   es: 0018   ss: 0018
Stack: 00000008 00005656 00005656 00000030 00000010 c02e1d28 00000000 00000000 
       c02e1c00 c01db3ac c027222c c02e1d28 00000000 00000010 00000010 00000010 
       00000010 c0288015 c027222c 00000001 00000000 c02e1c00 c01dbf41 0000000f 
Call Trace: [<c01db3ac>] [<c01dbf41>] [<c01d6c44>] [<c01d977d>] [<c019d1d9>] 
   [<c01a0dbc>] [<c01d65bb>] [<c0105000>] [<c0105029>] [<c0105000>] [<c0105596>] 
   [<c0105020>] 
Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 8b 44 24 2c 89 


>>EIP; c01d6806 <fb_copy_cmap+96/260>   <=====

>>eax; c027222c <palette_cmap+0/34>
>>esi; c02e1a40 <palette_red+0/20>
>>esp; cfe63e08 <_end+fb7e5d4/1056b7cc>

Trace; c01db3ac <gen_set_cmap+8c/a0>
Trace; c01dbf41 <vesafb_setcolreg+61/e0>
Trace; c01d6c44 <fb_set_cmap+104/130>
Trace; c01d977d <fbcon_switch+17d/1c0>
Trace; c019d1d9 <redraw_screen+c9/140>
Trace; c01a0dbc <take_over_console+ec/180>
Trace; c01d65bb <register_framebuffer+fb/130>
Trace; c0105000 <_stext+0/0>
Trace; c0105029 <init+9/140>
Trace; c0105000 <_stext+0/0>
Trace; c0105596 <kernel_thread+26/30>
Trace; c0105020 <init+0/140>

Code;  c01d6806 <fb_copy_cmap+96/260>
00000000 <_EIP>:
Code;  c01d6806 <fb_copy_cmap+96/260>   <=====
   0:   f3 a5                     repz movsl %ds:(%esi),%es:(%edi)   <=====
Code;  c01d6808 <fb_copy_cmap+98/260>
   2:   f6 c3 02                  test   $0x2,%bl
Code;  c01d680b <fb_copy_cmap+9b/260>
   5:   74 02                     je     9 <_EIP+0x9> c01d680f <fb_copy_cmap+9f/260>
Code;  c01d680d <fb_copy_cmap+9d/260>
   7:   66 a5                     movsw  %ds:(%esi),%es:(%edi)
Code;  c01d680f <fb_copy_cmap+9f/260>
   9:   f6 c3 01                  test   $0x1,%bl
Code;  c01d6812 <fb_copy_cmap+a2/260>
   c:   74 01                     je     f <_EIP+0xf> c01d6815 <fb_copy_cmap+a5/260>
Code;  c01d6814 <fb_copy_cmap+a4/260>
   e:   a4                        movsb  %ds:(%esi),%es:(%edi)
Code;  c01d6815 <fb_copy_cmap+a5/260>
   f:   8b 44 24 2c               mov    0x2c(%esp,1),%eax
Code;  c01d6819 <fb_copy_cmap+a9/260>
  13:   89 00                     mov    %eax,(%eax)

 <0>Kernel panic: Attempted to kill init!

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> 
> > I have a few observations on fbgen and fbcon-accel.
> 

One more thing I've noticed with gen_set_var.  Basically, gen_set_var
will proceed if it satisfies 2 conditions -- during initialization (con
< 0) and if the new var is different from the old var.  

The above is fine if everything is done in the console.  However,
problems may arise if an app that touches the graphics hardware (ie X)
is launched.  From the point of view of fbcon, the hardware state hasn't
changed (compare of newvar with oldvar is false) when display is
switched back to console.  And if that app did not fully restore the
hardware state,  we will be left with a corrupted display.

So, it's probably better if set_par() and pan_display() are allowed to
proceed unconditionally within gen_set_var.  It might take a few more
milliseconds to switch consoles each time, but we are assured that the
hardware state is always coherent with the current var.

What do you think?

Tony

--- fbgen.c.orig	Sun May  5 01:38:57 2002
+++ fbgen.c	Sun May  5 01:38:55 2002
@@ -172,14 +172,8 @@
 
 		if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
 			info->var = *var;
-			
-			if (con == info->currcon) {
-				if (info->fbops->fb_set_par)
-					info->fbops->fb_set_par(info);
-
-				if (info->fbops->fb_pan_display)
-					info->fbops->fb_pan_display(&info->var, con, info);
 
+			if (con == info->currcon) {
 				gen_set_disp(con, info);
 				fb_set_cmap(&info->cmap, 1, info);
 			}
@@ -187,6 +181,13 @@
 			if (info->changevar)
 				info->changevar(con);
 		}
+	}
+	if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW &&
+	    con == info->currcon) {
+		if (info->fbops->fb_set_par)
+			info->fbops->fb_set_par(info);
+		if (info->fbops->fb_pan_display)
+			info->fbops->fb_pan_display(&info->var, con, info);
 	}
 	return 0;
 }

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> 
> > I have a few observations on fbgen and fbcon-accel.
> 
> Don't mix fbgen with fbcon-accel. The new gen_* stuff in fbgen.c is meant
> to replace the old fbgen_* stuff. That is why the below doesn't work.
>  
Okay, I've succeeded in rewriting the i810/i815 driver to use the gen_*
stuff instead of fbgen_*.  As far as I can tell everything works :) --
y-panning, accel, etc -- although gen_update_var() may not work
properly.  I'm still getting incorrect cursor colors in 8 bpp, but
that's probably my fault.  And you're right, it's actually easier to
write the driver using the gen_* stuff.  

> 
> > 2. Also, fbgen_switch basically just do an fbgen_do_set_var()
> > (decode_var(), followed by set_par()).  This is okay most times, but
> > it's probably better if fbgen_switch also does an encode_fix() since
> > fbcon's drawing functions also rely on fix->line_length.
> 
> Most likely that is also broken. I haven't thought about it since I plan
> to make all the old fbgen_* functions go away.
> 
fb_gen_switch may be broken, but I think gen_switch works just okay as
long as info->fix is updated in set_par().

> > If an fb_fix_screeninfo is not updated, display corruption occurs when
> > switching to another display with a different pixelformat.
> 
> Correct. That is why I require info->fix to be updated when set_par is
> called.
> 
Right.

The i810fb patch is at
http://prdownloads.sourceforge.net/i810fb/linux-2.5.13-i810fb.tar.bz2.

Tony

--- fbgen.c.orig	Sat May  4 14:35:32 2002
+++ fbgen.c	Sat May  4 15:02:37 2002
@@ -514,7 +514,8 @@
     
 	if (con == info->currcon) {
 		if (info->fbops->fb_pan_display) {
-			if ((err = info->fbops->fb_pan_display(&info->var, con, info)))
+		        /* Tony: offsets are still in disp->var, not info->var */
+			if ((err = info->fbops->fb_pan_display(&fb_display[con].var, con, info)))
 				return err;
 		}
 	}	

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> 
> > I have a few observations on fbgen and fbcon-accel.
> 
> Don't mix fbgen with fbcon-accel. The new gen_* stuff in fbgen.c is meant
> to replace the old fbgen_* stuff. That is why the below doesn't work.
>  

I see now :)

I'll incorport all gen_* functions as you along adding them and let you
know.

Thanks!

Tony

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

> I have a few observations on fbgen and fbcon-accel.

Don't mix fbgen with fbcon-accel. The new gen_* stuff in fbgen.c is meant
to replace the old fbgen_* stuff. That is why the below doesn't work.
 
> 1.  fbcon_accel_clear_margins may not work correctly with fbgen since
> fbcon_accel will use the xoffset and yoffset values from info->var.  
> 
>     void fbcon_accel_clear_margins(struct vc_data *vc, struct display
>     *p,
>     			       int bottom_only)
>     {
>     	<<<snip>>> 
>     
>     	if (bh) {
>     		region.dx = info->var.xoffset;
>                     region.dy = info->var.yoffset + bs;
>                     region.width  = rs;
>                     region.height = bh;
>     		info->fbops->fb_fillrect(info, &region);
>     	}
>     }
> 
> However fbgen_pan_display updates the xoffset and yoffset in
> fb_display[con].var. So margins don't get cleared if the driver supports
> y-panning or y-wrapping.
> 
>     int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
>     		      struct fb_info *info)
>     {
>     	<<< snip >>>
>     
>         if (con == info->currcon) {
>     	if (fbhw->pan_display) {
>     	    if ((err = fbhw->pan_display(var, info2)))
>     		return err;
>     	} else
>     	    return -EINVAL;
>         }
>         fb_display[con].var.xoffset = var->xoffset;
>         fb_display[con].var.yoffset = var->yoffset;
>     
>     	<<< snip >>>
>     }

> 2. Also, fbgen_switch basically just do an fbgen_do_set_var()
> (decode_var(), followed by set_par()).  This is okay most times, but
> it's probably better if fbgen_switch also does an encode_fix() since
> fbcon's drawing functions also rely on fix->line_length.

Most likely that is also broken. I haven't thought about it since I plan
to make all the old fbgen_* functions go away.

> If an fb_fix_screeninfo is not updated, display corruption occurs when
> switching to another display with a different pixelformat.

Correct. That is why I require info->fix to be updated when set_par is
called.

Re: [Linux-fbdev-devel] Question on imageblit

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

> >   To draw the pengiun using the accel wrapper I need to set the color map
> > to the what the penguin needs. Then I create fb_image where each piece of 
> > data in char* field are a value that represents where in the struct
> > fb_cmap that data is. I think this is the best approach to that. Any
> > suggestions other wise?
> > 
> 
> I think that will be a good idea.  I have heard of graphics cards that
> will lock-up if a read/write to graphics memory and a hardware operation
> such as a blit occured simultaneously.  Using either pure accel or pure
> software rendering to draw to the framebuffer will make it easier for
> the driver to watch out for those.

Yes. That was the idea.
 
> Which refers again to my previous question --  So basically, imageblit
> has to support functions other than conversion from monochrome ->
> framebuffer pixelformat.  But I don't think not all cards will support
> other forms of color conversions.  In that case, imageblit will be
> better supported by hardware by restricting it to:
> 
> 	1. copy from monochrome->higher pixel formats (for drawing 	   text);
> and
> 	2. copy where the src and destination have the same pixelformat 	  
> (much like copyarea -- for drawing images).

Yes. You have to limit imageblit because of this. Also we don't want to
color expansion for the software version of imageblit. Yuck!!! So yes the
src image MUST be the depth as the framebuffer. 

[Linux-fbdev-devel] [PATCH] fbdev updates.

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

The following link are for more fbdev updates from the PPC guys and a few
fixes.

diff: 
      http://www.transvirtual.com/~jsimmons/fbdev_fixs.diff

BK URL:
	
      http://fbdev.bkbits.net:8080/fbdev-2.5

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

[Linux-fbdev-devel] sstfb update for 2.4.18

[Ghozlane T. <gh...@sy...>]

Hi everybody,
After a long hiatus, I updated the now infamous sstfb Voodoo1/2 driver.

Nothing much changed relatively to features, but the driver should be now 
compliant with the "new Pci driver" specification, and use ressources 
managment.
It is also now capable of driving more than one voodoo (who beside me would 
do such a thing?) , and lastly it now works on alpha architecture.
Granted, it may not work on x86 anymore due to my lack of such machine at the 
time, so i'd be delighted if someone with the hardware could test it ...

I'm planning to finish adding doublescaning mode, and submitting to Marcello
if everything goes well.

The is under sourceforge cvs at http://sf.net/projects/sstfb/cvs


Thank you in advance .

Ghoz

Re: [Linux-fbdev-devel] 3DFX mmio code to test with

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

On Fri, 3 May 2002, Ani Joshi wrote:
> Ah, it seems I never paid much attention to mmio and /dev/fb.  So is this
> the suggested use rather then /dev/mem?

Yes.

It also means that the fbdev layer can keep track off who is using its MMIO.
Note that you cannot (error -EINVAL) mmap MMIO if var.accel_flags is set, to
prevent conflicts between accel engine accesses between user space and the
fbdev.

> On Fri, 3 May 2002, Geert Uytterhoeven wrote:
> > On Thu, 2 May 2002, Ani Joshi wrote:
> > > After further looking at your code, it seems you are mmaping /dev/fb for
> > > your MMIO.  Is this even possible?  Shouldn't you be mapping /dev/mem?
> > > Has someone changed the fbdev layer so you can mmap mmio via /dev/fb?
> >
> > That change was made many years ago :-)
> >
> > You have the frame buffer at offset 0...fix.smem_len-1, and the MMIO at
> > fix.smem_len...fix.smem_len+fix.mmio_len-1.

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] 3DFX mmio code to test with

[Ani J. <aj...@sh...>]

Ah, it seems I never paid much attention to mmio and /dev/fb.  So is this
the suggested use rather then /dev/mem?


ani

On Fri, 3 May 2002, Geert Uytterhoeven wrote:

> On Thu, 2 May 2002, Ani Joshi wrote:
> > After further looking at your code, it seems you are mmaping /dev/fb for
> > your MMIO.  Is this even possible?  Shouldn't you be mapping /dev/mem?
> > Has someone changed the fbdev layer so you can mmap mmio via /dev/fb?
>
> That change was made many years ago :-)
>
> You have the frame buffer at offset 0...fix.smem_len-1, and the MMIO at
> fix.smem_len...fix.smem_len+fix.mmio_len-1.
>
> 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] Comments on fbgen.c and fbcon-accel.c

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

Hi,

I have a few observations on fbgen and fbcon-accel.

1.  fbcon_accel_clear_margins may not work correctly with fbgen since
fbcon_accel will use the xoffset and yoffset values from info->var.  

    void fbcon_accel_clear_margins(struct vc_data *vc, struct display
    *p,
    			       int bottom_only)
    {
    	<<<snip>>> 
    
    	if (bh) {
    		region.dx = info->var.xoffset;
                    region.dy = info->var.yoffset + bs;
                    region.width  = rs;
                    region.height = bh;
    		info->fbops->fb_fillrect(info, &region);
    	}
    }

However fbgen_pan_display updates the xoffset and yoffset in
fb_display[con].var. So margins don't get cleared if the driver supports
y-panning or y-wrapping.

    int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
    		      struct fb_info *info)
    {
    	<<< snip >>>
    
        if (con == info->currcon) {
    	if (fbhw->pan_display) {
    	    if ((err = fbhw->pan_display(var, info2)))
    		return err;
    	} else
    	    return -EINVAL;
        }
        fb_display[con].var.xoffset = var->xoffset;
        fb_display[con].var.yoffset = var->yoffset;
    
    	<<< snip >>>
    }

2. Also, fbgen_switch basically just do an fbgen_do_set_var()
(decode_var(), followed by set_par()).  This is okay most times, but
it's probably better if fbgen_switch also does an encode_fix() since
fbcon's drawing functions also rely on fix->line_length.

If an fb_fix_screeninfo is not updated, display corruption occurs when
switching to another display with a different pixelformat.

Tony

 

Re: [Linux-fbdev-devel] 3DFX mmio code to test with

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

On Thu, 2 May 2002, Ani Joshi wrote:
> After further looking at your code, it seems you are mmaping /dev/fb for
> your MMIO.  Is this even possible?  Shouldn't you be mapping /dev/mem?
> Has someone changed the fbdev layer so you can mmap mmio via /dev/fb?

That change was made many years ago :-)

You have the frame buffer at offset 0...fix.smem_len-1, and the MMIO at
fix.smem_len...fix.smem_len+fix.mmio_len-1.

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] 3DFX mmio code to test with

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

On Thu, 2002-05-02 at 09:04, Antonino Daplas wrote:

> DirectFB mmaps mmio via /dev/fb.  For the first argument (length), you
> have to use a value <= fix.mmio_len, and for the last argument (offset),

Oops, I meant ...

... For the second argument (length), you ...

Tony

Re: [Linux-fbdev-devel] Question on imageblit

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

On Fri, 2002-05-03 at 04:06, James Simmons wrote:

>   To draw the pengiun using the accel wrapper I need to set the color map
> to the what the penguin needs. Then I create fb_image where each piece of 
> data in char* field are a value that represents where in the struct
> fb_cmap that data is. I think this is the best approach to that. Any
> suggestions other wise?
> 

I think that will be a good idea.  I have heard of graphics cards that
will lock-up if a read/write to graphics memory and a hardware operation
such as a blit occured simultaneously.  Using either pure accel or pure
software rendering to draw to the framebuffer will make it easier for
the driver to watch out for those.

Which refers again to my previous question --  So basically, imageblit
has to support functions other than conversion from monochrome ->
framebuffer pixelformat.  But I don't think not all cards will support
other forms of color conversions.  In that case, imageblit will be
better supported by hardware by restricting it to:

	1. copy from monochrome->higher pixel formats (for drawing 	   text);
and
	2. copy where the src and destination have the same pixelformat 	  
(much like copyarea -- for drawing images).
    
Tony

Re: [Linux-fbdev-devel] 3DFX mmio code to test with

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

On Fri, 2002-05-03 at 08:03, Ani Joshi wrote:
> 
> Well, I didn't try running this code, but its looks from your code below
> that your mmap() is wrong.  The first argument in mmap is rarely used and
> typically a hint.  You should be using the mmio address (fb_fix.mmio_start)
> in the last argument instead of the first, and have the first agrument 0.
> The last argument is the offset (in this case the physical offset in
> memory).
> 
> After further looking at your code, it seems you are mmaping /dev/fb for
> your MMIO.  Is this even possible?  Shouldn't you be mapping /dev/mem?
> Has someone changed the fbdev layer so you can mmap mmio via /dev/fb?
> 
> 
DirectFB mmaps mmio via /dev/fb.  For the first argument (length), you
have to use a value <= fix.mmio_len, and for the last argument (offset),
you have to use a value >= fix.smem_len.  At (offset == fix.smem_len),
the actual mmio offset mmaped is at 0.  

By the way, may have to generally use NULL for the first argument
(start).

Tony

> ani
> 
> 
> On Thu, 2 May 2002, James Simmons wrote:
> 
> > 	dst2 = mmap(fb_fix.mmio_start, fb_fix.mmio_len, PROT_WRITE,MAP_SHARED, fbd, 0);
> > 	if (!dst2) {
> > 		fprintf(stderr, "MMap of MMIO of /dev/fb%d failed\n", fbnum);
> > 		exit(1);
> > 	}
> 
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] 3DFX mmio code to test with

[Ani J. <aj...@sh...>]

Well, I didn't try running this code, but its looks from your code below
that your mmap() is wrong.  The first argument in mmap is rarely used and
typically a hint.  You should be using the mmio address (fb_fix.mmio_start)
in the last argument instead of the first, and have the first agrument 0.
The last argument is the offset (in this case the physical offset in
memory).

After further looking at your code, it seems you are mmaping /dev/fb for
your MMIO.  Is this even possible?  Shouldn't you be mapping /dev/mem?
Has someone changed the fbdev layer so you can mmap mmio via /dev/fb?


ani


On Thu, 2 May 2002, James Simmons wrote:

> 	dst2 = mmap(fb_fix.mmio_start, fb_fix.mmio_len, PROT_WRITE,MAP_SHARED, fbd, 0);
> 	if (!dst2) {
> 		fprintf(stderr, "MMap of MMIO of /dev/fb%d failed\n", fbnum);
> 		exit(1);
> 	}

[Linux-fbdev-devel] Re: 2.5.11 framebuffer compilation error

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

> James Simmons writes:
> 
> > Diff:
> > 
> > http://www.transvirtual.com/~jsimmons/fbdev_fixs.diff
> 
> I tried 2.5.12 with this patch on PPC, with most of the mac
> framebuffers selected, and got a few errors.  Here is a patch that
> fixes the compilation errors plus a few other things.

I applied your patch. Same place and I also applied to my BK tree. 
As for other changes. Alot of cleanups are going to happen. Soon you will
see with my new VESA framebuffer driver.

[Linux-fbdev-devel] 3DFX mmio code to test with

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

Here you go. Something to test it with. I like so see if anyone else is
also having this problem.

/*
 *  This file is subject to the terms and conditions of the GNU General Public
 *  License. See the file COPYING in the main directory of this archive for
 *  more details.
 */

#include <stdio.h>

#include <stdlib.h>
#include <unistd.h>
extern char *optarg;
extern int optind, opterr, optopt;

#include <errno.h>
int errno;

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <setjmp.h>
#include <sys/mman.h>
#include <asm/page.h>
#include <asm/byteorder.h>
#include <asm/bitops.h>

#include <linux/fb.h>

static unsigned char fontdata_8x16[4096] = {
	/* 65 0x41 'A' */
        0x00, /* 00000000 */
        0x00, /* 00000000 */
        0x10, /* 00010000 */
        0x38, /* 00111000 */
        0x6c, /* 01101100 */
        0xc6, /* 11000110 */
        0xc6, /* 11000110 */
        0xfe, /* 11111110 */
        0xc6, /* 11000110 */
        0xc6, /* 11000110 */
        0xc6, /* 11000110 */
        0xc6, /* 11000110 */
        0x00, /* 00000000 */
        0x00, /* 00000000 */
        0x00, /* 00000000 */
        0x00, /* 00000000 */
};

int
main(int argc, char **argv)
{
	unsigned long mask, eorx;
	int ppw, i, j, k, l;
	unsigned long fgx, bgx, fgcolor = 0xFFFFFFFF, bgcolor = 0;
	unsigned long *dst, *src = NULL;
	struct fb_var_screeninfo fb_var;
	struct fb_fix_screeninfo fb_fix;
	int fb_mem_offset = 0, fbd, r;
	char fbdevice[256];
	int height, width;
	unsigned long *dst1, *dst2, *src1;
	int fbnum = 0;
	int linesize;
	long tmp;
	
	fprintf(stderr, "Opening /dev/fb%d\n", fbnum);
	
	sprintf(fbdevice, "/dev/fb%d", fbnum);
	fbd = open(fbdevice, O_RDWR);
	
	if (fbd < 0)
	{
		fprintf(stderr, "Couldn't open /dev/fb%d; errno: %d (%s)\n", fbnum, errno, strerror(errno));
		exit(1);
	}
	r = ioctl(fbd, FBIOGET_VSCREENINFO, &fb_var);
	if (r < 0)
	{
		fprintf(stderr, "IOCTL FBIOGET_VSCREENINFO error: %d errno: %d (%s)\n", r, errno, strerror(errno));
		exit(1);
	}
	r = ioctl(fbd, FBIOGET_FSCREENINFO, &fb_fix);
	if (r < 0)
	{
		fprintf(stderr, "IOCTL FBIOGET_FSCREENINFO error: %d errno: %d (%s)\n", r, errno, strerror(errno));
		exit(1);
	}

 	tmp = -1 >> (32 - fb_var.bits_per_pixel);
	linesize = fb_fix.line_length;

	fprintf(stderr, "Screen depth is %d\n", fb_var.bits_per_pixel);
	/* map all FB memory */
	fb_mem_offset = (unsigned long)(fb_fix.smem_start) & (~PAGE_MASK);
	dst1 = mmap(NULL,fb_fix.smem_len+fb_mem_offset,PROT_WRITE,MAP_SHARED,fbd,0);
	if (!dst1) {
		fprintf(stderr, "MMap of /dev/fb%d failed\n", fbnum);
		exit(1);
	}

	dst2 = mmap(fb_fix.mmio_start, fb_fix.mmio_len, PROT_WRITE,MAP_SHARED, fbd, 0);
	if (!dst2) {
		fprintf(stderr, "MMap of MMIO of /dev/fb%d failed\n", fbnum);
		exit(1);
	}
	return(0);
}

[Linux-fbdev-devel] 3Dfx mmio problems.

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

I just attempted to write a simple program to mmap the MMIO region and I
coudln't do it. The mmap failed. Can some else tell me if they had the
same problem.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/