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

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

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

> In 2.5, in contrast with the 2.4 fbdev framework, any changes in the
> fbdev layer will not reflect in the upper console layer, except during
> initialization of fbcon.  So using fbset to change the resolution will
> produce unexpected results. If my understanding is correct, the
> relationship between console and fbdev is now master (console) and slave
> (fbdev).  If this is true, then console changes must become visible to
> fbcon/fbdev.  This is easily accomplished by adding a csw->con_resize()
> hook to fbcon.

Correct to the above. I applied your patch.

> The tty/console layer has several ioctl's that will allow changing of
> the console window size (VT_RESIZE, VT_RESIZEX, TIOCSWINSZ, etc). So
> using:
> 
> stty cols 128 rows 48
> 
> will change the fb resolution to 1024x768 if using an 8x16 font.
> 
> One advantage of this approach is that the changes are preserved per
> console (in contrast to using fbset which sets all consoles).

Yeap. TIOCSWINSZ is per VC. VT_RESIZE and VT_RESIZEX affect all VCs. 
They should work as well.

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

> User-entered timings are always preferred, so these are validated
> first.  If the timings are not valid, then they will be computed. So,
> here are 2 new functions:
> 
> 1. fb_validate_mode(fb_var_screeninfo *var, fb_info *info)
> 
> 2. fb_get_mode(u32 refresh, fb_var_screeninfo *var, fb_info *info)
> 
> It's in fb_get_mode() where the GTF is implemented.  The 'refresh'
> parameter is optional, and if == 0, the vertical refresh rate will be
> maximized.
> 
> Anyway, using fb_get_mode(), I was able to generate working video modes from as low as
> 300x300@60 to as high as 1600x1200@85.  I've also experimented with
> unusual modes, such as 1600x480.
> 
> Comments?

Nice. The only thing is i like to see monitor stuff end up in fbmon.c. I 
will apply your patch.

[Linux-fbdev-devel] Re: [PATCH] C99 initializers for drivers/video/console

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

> Here are patches for two files in drivers/video/console that switch the
> files to use C99 initializers. The patches are against 2.5.54.

Applied.

Re: [Linux-fbdev-devel] i810fb: trivial fixes and cleanups

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

> Attached is a diff against linux-2.5.54.
> 
> 1. i810fb_par should be built inf fb_set_par() instead of
> fb_check_var().
> 2. changed __devinit*/__devexit* to __init/__exit.
> 3. removed unused/redundant variables

 Applied.

[Linux-fbdev-devel] Re: [PATCH] [FBDEV]: accel_putcs() buffer overflow fix

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

> 1. If size of bitmap exceeds size of pixmap buffer, subdivide and do
> multiple imageblits.
> 
> 2. Use generic fb_pan_display() instead of info->fbops->fb_pan_display()
> in update_var()

Applied.

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

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

Hi,

In 2.5, in contrast with the 2.4 fbdev framework, any changes in the
fbdev layer will not reflect in the upper console layer, except during
initialization of fbcon.  So using fbset to change the resolution will
produce unexpected results. If my understanding is correct, the
relationship between console and fbdev is now master (console) and slave
(fbdev).  If this is true, then console changes must become visible to
fbcon/fbdev.  This is easily accomplished by adding a csw->con_resize()
hook to fbcon.

<-- BEGIN -->
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-04 21:58:47.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-06 13:31:34.000000000 +0000
@@ -1871,6 +1871,25 @@
 }
 

+static int fbcon_resize(struct vc_data *vc, unsigned int width, 
+			unsigned int height)
+{
+	struct display *p = &fb_display[vc->vc_num];
+	struct fb_info *info = p->fb_info;
+	struct fb_var_screeninfo var = info->var;
+	int err;
+
+	var.xres = width * vc->vc_font.width;
+	var.yres = height * vc->vc_font.height;
+	var.activate = FB_ACTIVATE_NOW;
+
+	err = fb_set_var(&var, info);
+
+	return (err || info->var.xres/vc->vc_font.width != width ||
+		info->var.yres/vc->vc_font.height != height) ?
+		-EINVAL : 0;
+}
+
 static int fbcon_switch(struct vc_data *vc)
 {
 	int unit = vc->vc_num;
@@ -1920,6 +1939,7 @@
 
 	info->currcon = unit;
 	
+        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	update_var(unit, info);
 	
 	if (vt_cons[unit]->vc_mode == KD_TEXT)
@@ -2537,6 +2557,7 @@
 	.con_invert_region 	= fbcon_invert_region,
 	.con_screen_pos 	= fbcon_screen_pos,
 	.con_getxy 		= fbcon_getxy,
+	.con_resize             = fbcon_resize,
 };
 
 int __init fb_console_init(void)

<-- END -->

The tty/console layer has several ioctl's that will allow changing of
the console window size (VT_RESIZE, VT_RESIZEX, TIOCSWINSZ, etc). So
using:

stty cols 128 rows 48

will change the fb resolution to 1024x768 if using an 8x16 font.

One advantage of this approach is that the changes are preserved per
console (in contrast to using fbset which sets all consoles).

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.  

With the current approach, this "assistance" is gone. When a window size
change is requested, the fbdev driver is left on its own to find the
correct timing values for the video mode.  

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.

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)

2. entered as a boot/module option

3. ?ioctl to upload monitor info to fbdev.

(As a side note, should we also add pixclock_min and pixclock_max to
info->monspecs?).

User-entered timings are always preferred, so these are validated
first.  If the timings are not valid, then they will be computed. So,
here are 2 new functions:

1. fb_validate_mode(fb_var_screeninfo *var, fb_info *info)

2. fb_get_mode(u32 refresh, fb_var_screeninfo *var, fb_info *info)

It's in fb_get_mode() where the GTF is implemented.  The 'refresh'
parameter is optional, and if == 0, the vertical refresh rate will be
maximized.

Anyway, using fb_get_mode(), I was able to generate working video modes from as low as
300x300@60 to as high as 1600x1200@85.  I've also experimented with
unusual modes, such as 1600x480.

Comments?

Tony

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:36:08.000000000 +0000
+++ linux/drivers/video/modedb.c	2003-01-06 13:34:50.000000000 +0000
@@ -423,4 +423,245 @@
     return 0;
 }
 
+#define FLYBACK                     550
+#define V_FRONTPORCH                1
+#define H_OFFSET                    40
+#define H_SCALEFACTOR               20
+#define H_BLANKSCALE                128
+#define H_GRADIENT                  600
+
+/**
+ * fb_get_vblank - get vertical blank time
+ * @hfreq: horizontal freq
+ *
+ * DESCRIPTION:
+ * vblank = right_margin + vsync_len + left_margin 
+ *
+ *    given: right_margin = 1 (V_FRONTPORCH)
+ *           vsync_len    = 3
+ *           flyback      = 550
+ *
+ *                          flyback * hfreq
+ *           left_margin  = --------------- - vsync_len
+ *                           1000000
+ */
+static u32 fb_get_vblank(u32 hfreq)
+{
+	u32 vblank;
+
+	vblank = (hfreq * FLYBACK)/1000; 
+	vblank = (vblank + 500)/1000;
+	return (vblank + V_FRONTPORCH);
+}
+
+/** 
+ * fb_get_hblank - get horizontal blank time
+ * @hfreq: horizontal freq
+ * @xres: horizontal resolution in pixels
+ *
+ * DESCRIPTION:
+ *
+ *           xres * duty_cycle
+ * hblank = ------------------
+ *           100 - duty_cycle
+ *
+ * duty cycle = percent of htotal assigned to inactive display
+ * duty cycle = C - (M/Hfreq)
+ *
+ * where: C = ((offset - scale factor) * blank_scale)
+ *            -------------------------------------- + scale factor
+ *                        256 
+ *        M = blank_scale * gradient
+ *
+ */
+static u32 fb_get_hblank(u32 hfreq, u32 xres)
+{
+	u32 c_val, m_val, duty_cycle, hblank;
+
+	c_val = (((H_OFFSET - H_SCALEFACTOR) * H_BLANKSCALE)/256 + 
+		 H_SCALEFACTOR) * 1000;
+	m_val = (H_BLANKSCALE * H_GRADIENT)/256;
+	m_val = (m_val * 1000000)/hfreq;
+	duty_cycle = c_val - m_val;
+	hblank = (xres * duty_cycle)/(100000 - duty_cycle);
+	return (hblank);
+}
+
+/**
+ * fb_get_hfreq - estimate hsync
+ * @vfreq: vertical refresh rate
+ * @yres: vertical resolution
+ *
+ * DESCRIPTION:
+ *
+ *          (yres + front_port) * vfreq * 1000000
+ * hfreq = -------------------------------------
+ *          (1000000 - (vfreq * FLYBACK)
+ * 
+ */
+
+static u32 fb_get_hfreq(u32 vfreq, u32 yres)
+{
+	u32 divisor, hfreq;
+	
+	divisor = (1000000 - (vfreq * FLYBACK))/1000;
+	hfreq = (yres + V_FRONTPORCH) * vfreq  * 1000;
+	return (hfreq/divisor);
+}
+
+/*
+ * fb_get_mode - calculates video mode using VESA GTF
+ * @refresh: if 0, maximize vertical refresh
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Calculates video mode based on monitor specs using VESA GTF. 
+ * The GTF is best for VESA GTF compliant monitors but is 
+ * specifically formulated to work for older monitors as well.
+ *
+ * If @refresh==0, the function will attempt to maximize the 
+ * refresh rate, otherwise, it will calculate timings based on
+ * this value.  However, it's preferable to just clamp 
+ * info->monspecs.vfmin/vfmax to desired refresh.  
+ *
+ * All calculations are based on the VESA GTF Spreadsheet
+ * available at VESA's public ftp (http://www.vesa.org).
+ * 
+ * NOTES:
+ * The timings generated by the GTF will be different from VESA
+ * DMT.  It might be a good idea to keep a table of standard
+ * VESA modes as well.  The GTF may also not work for some displays,
+ * such as, and especially, analog TV.
+ *   
+ * REQUIRES:
+ * A valid info->monspecs, otherwise 'safe numbers' will be used.
+ */ 
+int fb_get_mode(u32 vrefresh, struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	u32 htotal = 0, vtotal, hfreq, vfreq = 0, hblank, vblank; 
+	u32 dclk, interlace = 1, dscan = 1, yres = var->yres, xres = var->xres;
+	u32 hfmin, hfmax, vfmin, vfmax;
+
+	/* 
+	 * If monspecs are invalid, use values that are enough
+	 * for 640x480@60
+	 */
+	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	    info->monspecs.hfmax < info->monspecs.hfmin ||
+	    info->monspecs.vfmax < info->monspecs.vfmin) {
+		hfmin = 29; hfmax = 30;
+		vfmin = 60; vfmax = 60;
+	} else {
+		hfmin = info->monspecs.hfmin;
+		hfmax = info->monspecs.hfmax;
+		vfmin = info->monspecs.vfmin;
+		vfmax = info->monspecs.vfmax;
+	}
+
+	if (var->vmode & FB_VMODE_INTERLACED) { 
+		yres /= 2;
+		interlace = 2;
+	}
+	if (var->vmode & FB_VMODE_DOUBLE) {
+		yres *= 2;
+		dscan = 2;
+	}
+
+	if (vrefresh) {
+		vfreq = vrefresh;
+		hfreq = fb_get_hfreq(vfreq, yres);
+		vblank = fb_get_vblank(hfreq);
+		vtotal = yres + vblank;
+	} else {
+		hfreq = hfmax;
+		vblank = fb_get_vblank(hfreq);
+		vtotal = yres + vblank;
+		vfreq = hfreq/vtotal;
+		if (vfreq > vfmax) {
+			vfreq = vfmax;
+			hfreq = fb_get_hfreq(vfreq, yres);
+			vblank = fb_get_vblank(hfreq);
+			vtotal = yres + vblank;
+		}
+	} 
+	
+	if (vfreq < vfmin || vfreq > vfmax || 
+	    hfreq < hfmin || hfreq > hfmax)
+		return -EINVAL;
+
+	hblank = fb_get_hblank(hfreq, xres);
+	htotal = xres + hblank;
+	dclk = htotal * hfreq;
+
+	var->pixclock = KHZ2PICOS(dclk/1000);
+	var->hsync_len = (htotal * 8)/100;
+	var->right_margin = (hblank/2) - var->hsync_len;
+	var->left_margin = hblank - var->right_margin - var->hsync_len;
+	
+	var->vsync_len = (3 * interlace)/dscan;
+	var->lower_margin = (1 * interlace)/dscan;
+	var->upper_margin = (vblank * interlace)/dscan - 
+		(var->vsync_len + var->lower_margin);
+	
+	return 0;
+}
+	
+/*
+ * fb_validate_mode - validates var against monitor capabilities
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Validates video mode against monitor capabilities specified in
+ * info->monspecs.
+ *
+ * REQUIRES:
+ * A valid info->monspecs.
+ */
+int fb_validate_mode(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	u32 hfreq, vfreq, htotal, vtotal, pixclock;
+	u32 hfmin, hfmax, vfmin, vfmax;
+
+	/* 
+	 * If monspecs are invalid, use values that are enough
+	 * for 640x480@60
+	 */
+	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	    info->monspecs.hfmax < info->monspecs.hfmin ||
+	    info->monspecs.vfmax < info->monspecs.vfmin) {
+		hfmin = 29; hfmax = 30;
+		vfmin = 60; vfmax = 60;
+	} else {
+		hfmin = info->monspecs.hfmin;
+		hfmax = info->monspecs.hfmax;
+		vfmin = info->monspecs.vfmin;
+		vfmax = info->monspecs.vfmax;
+	}
+
+	if (!var->pixclock)
+		return -EINVAL;
+	pixclock = PICOS2KHZ(var->pixclock) * 1000;
+	   
+	htotal = var->xres + var->right_margin + var->hsync_len + 
+		var->left_margin;
+	vtotal = var->yres + var->lower_margin + var->vsync_len + 
+		var->upper_margin;
+
+	if (var->vmode & FB_VMODE_INTERLACED)
+		vtotal /= 2;
+	if (var->vmode & FB_VMODE_DOUBLE)
+		vtotal *= 2;
+
+	hfreq = pixclock/htotal;
+	vfreq = hfreq/vtotal;
+
+	return (vfreq < vfmin || vfreq > vfmax || 
+		hfreq < hfmin || hfreq > hfmax) ?
+		-EINVAL : 0;
+}
+
 EXPORT_SYMBOL(__fb_try_mode);
+EXPORT_SYMBOL(fb_get_mode);
+EXPORT_SYMBOL(fb_validate_mode);
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h	2003-01-06 13:36:22.000000000 +0000
+++ linux/include/linux/fb.h	2003-01-06 13:35:35.000000000 +0000
@@ -494,6 +494,10 @@
     u32 vmode;
 };
 
+extern int fb_get_mode(u32 refresh, struct fb_var_screeninfo *var,
+		       struct fb_info *info);
+extern int fb_validate_mode(struct fb_var_screeninfo *var,
+			    struct fb_info *info);
 #ifdef MODULE
 static inline int fb_find_mode(struct fb_var_screeninfo *var,
 			       struct fb_info *info, const char *mode_option,

[Linux-fbdev-devel] [FB PATCH] fix alpha boot oops

[Richard H. <rt...@tw...>]

Oops in fb_set_cmap caused by palette_cmap.transp uninitialized.
By inspection, fb_blank appears to have the same problem.


r~


===== fbmem.c 1.49 vs edited =====
--- 1.49/drivers/video/fbmem.c	Tue Dec 31 18:08:48 2002
+++ edited/fbmem.c	Mon Jan  6 01:07:03 2003
@@ -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;
@@ -767,6 +768,7 @@
 int
 fb_blank(int blank, struct fb_info *info)
 {	
+	/* ??? Varible sized stack allocation.  */
 	u16 black[info->cmap.len];
 	struct fb_cmap cmap;
 	
@@ -775,8 +777,7 @@
 	if (blank) { 
 		memset(black, 0, info->cmap.len * sizeof(u16));
 		cmap.red = cmap.green = cmap.blue = black;
-		if (info->cmap.transp)
-			cmap.transp = black;
+		cmap.transp = info->cmap.transp ? black : NULL;
 		cmap.start = info->cmap.start;
 		cmap.len = info->cmap.len;
 	} else

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

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

> It needs a copy_to_user too to work. Probably doesn't
> need the copy_from_user.
> 
> Is the right fix?
> 
> 	case FBIOGETCMAP:
> 		fb_copy_cmap(&info->cmap, &cmap, 0);
> 		if (copy_to_user((void *) arg, &cmap, sizeof(cmap)))
> 			return -EFAULT;
> 		return 0;

Oops. I see the problem. It should be 

  fb_copy_cmap(&info->cmap, &cmap, 2);

This tells it to use copy_to_user. I see a few mistakes here. Fixing...

There are several bugs here. I have to cleanup it up. FOr example in 
fb_copy_cmap there is test for a EFAULT for any copy_* function. This is 
just broken. It has been broken for a long time. Will fix. Will you test 
my patch as soon as it is ready?

[Linux-fbdev-devel] Re: new logo drawing code

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

On Sun, 29 Dec 2002, Geert Uytterhoeven wrote:

>   - Replace conditionals by straight code without branches (bit 7 of needs_logo
>     is either 0 (normal) or 1 (reverse), and perhaps we should kill the default
>     case?).

Applied.

> BTW, most of the new fbdev code looks really ugly in vim with `let
> c_space_errors=1', due to the exorbitant use of superfluous whitespace
> characters.

??? I use indent -kr -i8 to handle indenting.

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

[Jon S. <jon...@ya...>]

It needs a copy_to_user too to work. Probably doesn't
need the copy_from_user.

Is the right fix?

	case FBIOGETCMAP:
		fb_copy_cmap(&info->cmap, &cmap, 0);
		if (copy_to_user((void *) arg, &cmap, sizeof(cmap)))
			return -EFAULT;
		return 0;


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] [PATCH] Logo crash

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

> The local variable palette_cmap.transp is not initialized, so it can contain
> garbage, causing a crash during logo drawing.
> 
> --- linux-2.5.54/drivers/video/fbmem.c	Thu Jan  2 12:54:58 2003
> +++ linux-m68k-2.5.54/drivers/video/fbmem.c	Sun Jan  5 17:22:57 2003
> @@ -386,6 +386,7 @@
>  	palette_cmap.red = palette_red;
>  	palette_cmap.green = palette_green;
>  	palette_cmap.blue = palette_blue;
> +	palette_cmap.transp = 0;
>  
>  	for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
>  		n = LINUX_LOGO_COLORS - i;

Applied.

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

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

> I'm using 2.53 and I ran into this when running
> fbtest. It looks like a return went missing.
> 
> 	case FBIOGETCMAP:
> 		if (copy_from_user(&cmap, (void *) arg,
> sizeof(cmap)))
> 			return -EFAULT;
> 		fb_copy_cmap(&info->cmap, &cmap, 0);
> 	case FBIOPAN_DISPLAY:
> 
> In 2.4 it looked like this:
> 
> 	case FBIOGETCMAP:
> 		if (copy_from_user(&cmap, (void *) arg,
> sizeof(cmap)))
> 			return -EFAULT;
> 		return (fb->fb_get_cmap(&cmap, 0,
> PROC_CONSOLE(info), info));
> 	case FBIOPAN_DISPLAY:

In the latest code there is a return 0 after fb_copy_cmap. So it is fixed 
with the latest tree.

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

[Jon S. <jon...@ya...>]

I'm using 2.53 and I ran into this when running
fbtest. It looks like a return went missing.

	case FBIOGETCMAP:
		if (copy_from_user(&cmap, (void *) arg,
sizeof(cmap)))
			return -EFAULT;
		fb_copy_cmap(&info->cmap, &cmap, 0);
	case FBIOPAN_DISPLAY:

In 2.4 it looked like this:

	case FBIOGETCMAP:
		if (copy_from_user(&cmap, (void *) arg,
sizeof(cmap)))
			return -EFAULT;
		return (fb->fb_get_cmap(&cmap, 0,
PROC_CONSOLE(info), info));
	case FBIOPAN_DISPLAY:


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

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

On 6 Jan 2003, Antonino Daplas wrote:
> On Mon, 2003-01-06 at 00:38, Geert Uytterhoeven wrote:
> > 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.

Yes, that's reasonable.

> >     However, I do see one good reason: it makes life easier for planar
> >     displays, since a fast c2p (chunky-to-planar) convertor doesn't have to
> >     care about the image depth, the source data is always 1 byte per pixel.
> > 
> >  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 :-)

I didn't think about that as well, until I tried all possible depths (1-8) with
amifb.

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

OK.

> to mean color expansion is more appropriate. Drivers that will need

OK.

> trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
> and of course cfb_imgblt.c, softcursor.c and fbcon.c.
> 
> I'll submit a patch if everyone agrees.  

Thanks!

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] fb_imageblit()

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

On Mon, 2003-01-06 at 00:38, Geert Uytterhoeven wrote:
> 
> 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.

>     However, I do see one good reason: it makes life easier for planar
>     displays, since a fast c2p (chunky-to-planar) convertor doesn't have to
>     care about the image depth, the source data is always 1 byte per pixel.
> 
>  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.

I'll submit a patch if everyone agrees.  

Tony

[Linux-fbdev-devel] [PATCH] Logo crash

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

The local variable palette_cmap.transp is not initialized, so it can contain
garbage, causing a crash during logo drawing.

--- linux-2.5.54/drivers/video/fbmem.c	Thu Jan  2 12:54:58 2003
+++ linux-m68k-2.5.54/drivers/video/fbmem.c	Sun Jan  5 17:22:57 2003
@@ -386,6 +386,7 @@
 	palette_cmap.red = palette_red;
 	palette_cmap.green = palette_green;
 	palette_cmap.blue = palette_blue;
+	palette_cmap.transp = 0;
 
 	for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
 		n = LINUX_LOGO_COLORS - i;

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] fb_imageblit()

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

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.

    However, I do see one good reason: it makes life easier for planar
    displays, since a fast c2p (chunky-to-planar) convertor doesn't have to
    care about the image depth, the source data is always 1 byte per pixel.

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

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

[Nico S. <sch...@wd...>]

Hello dear list!

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

Greetings,

Nico

--=20
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt ma=
ils
to mailing list!). If you don't know what pgp is visit www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)

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

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

On Sat, Jan 04, 2003 at 09:07:29PM +0000, James Simmons wrote:
> 
> Rejected. I have put thought into it and the whole point was to not allow 
> the fbdev layer to touch console data. I stand firm on this!!! The reason 
> being is the core console layer is going to change the next development 
> cycle. We have to change to deal with things like the PC9800 type hardware 
> that support more than 512 fonts. Do we realy want to break every fbdev 
> driver again. This way the breakage is once and for all. Its is also a 

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.

> pandoras box. If we place these hooks in we end up with the same crappy 
> driver problem we had before. I never heard anyone every say the old api 
> we clean. 

I believe that I repeatedly said that I see no problem with old API which
cannot be solved by incremental updates and without removing functionality.

It is like with modules - some believe in evolution, and some in revolution...
Fortunately modules situation finally settled down and it is enough just install
new app to handle module loading/unloading. With current fbdev even trivial
console resizing does not do anything useful (thanks, Antonio).
						Best regards,
							Petr Vandrovec
							van...@vc...

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

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

On Sat, Jan 04, 2003 at 09:12:24PM +0000, James Simmons wrote:
> 
> > 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...
 
> > could decide on case-by-case basis whether it will use its own code or 
> > generic without touching pointer (without modifying potentially constant
> > fb_ops structure common to all fbdev instances).
> 
> The patch was rejected. I working on your driver. I can throw in a text 
> mode driver as well. 

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.
						Best regards,
							Petr Vandrovec
							van...@vc...
 

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

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

On Sun, 2003-01-05 at 05:07, James Simmons wrote:
> 
> Rejected. I have put thought into it and the whole point was to not allow 

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

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)

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.

Tony 

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-04 21:58:47.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-04 21:58:24.000000000 +0000
@@ -1871,6 +1871,25 @@
 }
 

+static int fbcon_resize(struct vc_data *vc, unsigned int width, 
+			unsigned int height)
+{
+	struct display *p = &fb_display[vc->vc_num];
+	struct fb_info *info = p->fb_info;
+	struct fb_var_screeninfo var = info->var;
+	int err;
+
+	var.xres = width * vc->vc_font.width;
+	var.yres = height * vc->vc_font.height;
+	var.activate = FB_ACTIVATE_NOW;
+
+	err = fb_set_var(&var, info);
+	return  (err || var.xres != info->var.xres ||
+		 var.yres != info->var.yres) ?
+		-EINVAL : 0;
+	  
+}
+
 static int fbcon_switch(struct vc_data *vc)
 {
 	int unit = vc->vc_num;
@@ -1920,6 +1939,7 @@
 
 	info->currcon = unit;
 	
+        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	update_var(unit, info);
 	
 	if (vt_cons[unit]->vc_mode == KD_TEXT)
@@ -2537,6 +2557,7 @@
 	.con_invert_region 	= fbcon_invert_region,
 	.con_screen_pos 	= fbcon_screen_pos,
 	.con_getxy 		= fbcon_getxy,
+	.con_resize             = fbcon_resize,
 };
 
 int __init fb_console_init(void)

[Linux-fbdev-devel] Re: [OOPS] Linux v2.5.54 Riva Framebuffer

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

I'm working on a new imporve driver right now. Can you give me another 
day.

[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

> could decide on case-by-case basis whether it will use its own code or 
> generic without touching pointer (without modifying potentially constant
> fb_ops structure common to all fbdev instances).

The patch was rejected. I working on your driver. I can throw in a text 
mode driver as well. 

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

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

> > Attached is a patch against 2.5.54 in an attempt to add putcs() and
> > setfont() methods for fbdev drivers that require them:
> > 
> And those drivers would be the matrox framebuffer drivers, for example?
> 
> That would be really great!

I'm porting this driver to the new api. I'm alomst finished with the 
nvidia driver. Once I'm done on that the matrox driver is next. Sorry it 
is taking so long but I have alot of drivers to deal with.

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

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

Rejected. I have put thought into it and the whole point was to not allow 
the fbdev layer to touch console data. I stand firm on this!!! The reason 
being is the core console layer is going to change the next development 
cycle. We have to change to deal with things like the PC9800 type hardware 
that support more than 512 fonts. Do we realy want to break every fbdev 
driver again. This way the breakage is once and for all. Its is also a 
pandoras box. If we place these hooks in we end up with the same crappy 
driver problem we had before. I never heard anyone every say the old api 
we clean. 

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

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

On Sat, Jan 04, 2003 at 05:25:14PM +0800, Antonino Daplas wrote:
> Attached is a patch against 2.5.54 in an attempt to add putcs() and
> setfont() methods for fbdev drivers that require them:

Looks good.
 
> ...
> struct fb_char {
> 	__u32 dx;               /* where to place chars, in pixels */
> 	__u32 dy;               /* where to place chars, in scanline */

These two are questionable. I do not know what DaveM will need, but
I'll be happier with character coordinates for text mode. So for me it is
just question whether I'll do divide by width/height stored from setfont
in text mode, or multiply when in graphics mode. So I must remember
character cell size in any case. But having multiply in matroxfb could 
save multiply here in generic code.

I have strong feeling that doing multiply in generic code, and then divide
in fbdev driver is waste of time, but if Dave is happier with pixel
coordinates, I can definitely live with it.

> 	__u32 len;              /* number of characters */
> 	__u32 fg_color;
> 	__u32 bg_color;        
> 	__u32 *data;            /* array of indices to fontdata */
> };
> 
> struct fb_fontdata {
> 	__u32 width;            /* font width */
> 	__u32 height;           /* font height */
> 	__u32 len;              /* number of characters */
> 	__u8  *data;            /* character map */
> };
> 
> ...
> 
>     /* upload character map */
>     int (*fb_setfont)(struct fb_info *info, const struct fb_fontdata
> *font);
>     /* write characters */
>     int (*fb_putcs)(struct fb_info *info, const struct fb_char *chars);
> 

It would be nice to have old accel_putcs() available for modules, so driver 
could decide on case-by-case basis whether it will use its own code or 
generic without touching pointer (without modifying potentially constant
fb_ops structure common to all fbdev instances).
						Thanks,
							Petr Vandrovec
							van...@vc...