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

[Linux-fbdev-devel] New logo code

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

The current logo code is messy, complex, and inflexible. So I decided to
rewrite it. My goals were:
  - Logos must be accessible easily by an image editor (currently: hex C source
    data must be converted to another format first)
  - Logos must be stored in ASCII-form in the source tree
  - Support arbitrary logo sizes (currently: fixed 80x80)
  - Allow the logo to be selected statically (at compile time) and/or
    dynamically (at run-time, based on machine type) (currently: at compile
    time only).
  - Allow simple adition of new logos
  - Support grayscale logos (not used yet)

The patch achieves all of these. Logos are stored in ASCII PNM format in
drivers/video/logo/, and automatically converted to hex C source arrays using
scripts/pnmtologo. I chose ASCII PNM because (a) it's ASCII, (b) it's very
simple to parse without an external library (XPM is more difficult to parse),
and (c) it can be handled by many image manipulation programs.

Code that wants to display a logo just calls fb_find_logo(), specifying the
wanted logo type, and receives a pointer to a suitable logo (or NULL).

I also modified fb_show_logo() to return the number of scanlines that are used
by the logo, so fbcon knows how many lines to reserve.

So far I tested it on Amiga only (with amifb), using the standard 3 logos
(mono, vga16, and clut224, all 80x80), and using resized (171x171) versions of
the standard logos, to verify that arbitrary logo sizes are working.

Initial logo display is still a bit weird, because fbcon is initialized before
the logo is drawn. What you see is this:
  - Initial text screen contents are drawn, starting at the top of the screen,
  - The logo is drawn,
  - New kernel messages are printed, until the bottom of the screen is reached,
  - The logo is drawn again, and the top of the screen is reserved for the
    logo,
  - New kernel messages are printed, and scrolling scrolls the text part only,
    leaving the logo at the top

To do:
  - More testing
  - Clean ups:
      o Protect all drawing code by CONFIG_FB_LOGO
      o Move logo drawing code from fbmem.c to logo/logo.c?
      o Logo selection in Kconfig and logo.c?

Diffstat output:

 arch/mips64/Kconfig                        |    4 
 arch/ppc/syslib/prom.c                     |    3 
 arch/ppc/syslib/prom_init.c                |   28 
 arch/ppc64/kernel/prom.c                   |   27 
 drivers/video/Kconfig                      |    1 
 drivers/video/Makefile                     |    1 
 drivers/video/console/fbcon.c              |   11 
 drivers/video/console/newport_con.c        |   28 
 drivers/video/fbmem.c                      |  142 +-
 drivers/video/hgafb.c                      |   21 
 drivers/video/logo/Kconfig                 |   62 +
 drivers/video/logo/Makefile                |   26 
 drivers/video/logo/logo.c                  |   95 +
 drivers/video/logo/logo_dec_clut224.ppm    | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_linux_clut224.ppm  | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_linux_mono.pbm     |  202 +++
 drivers/video/logo/logo_linux_vga16.ppm    | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_mac_clut224.ppm    | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_sgi_clut224.ppm    | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_sun_clut224.ppm    | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_superh_clut224.ppm | 1603 +++++++++++++++++++++++++++++
 drivers/video/logo/logo_superh_mono.pbm    |  202 +++
 drivers/video/logo/logo_superh_vga16.ppm   | 1603 +++++++++++++++++++++++++++++
 include/asm-alpha/linux_logo.h             |   27 
 include/asm-arm/linux_logo.h               |   19 
 include/asm-i386/linux_logo.h              |   27 
 include/asm-ia64/linux_logo.h              |   28 
 include/asm-m68k/linux_logo.h              |  924 ----------------
 include/asm-m68knommu/linux_logo.h         |   13 
 include/asm-mips/linux_logo.h              |   43 
 include/asm-mips/linux_logo_dec.h          |  907 ----------------
 include/asm-mips/linux_logo_sgi.h          |  919 ----------------
 include/asm-mips64/linux_logo.h            |  919 ----------------
 include/asm-parisc/linux_logo.h            |   27 
 include/asm-ppc/linux_logo.h               |   24 
 include/asm-ppc64/linux_logo.h             |   26 
 include/asm-sh/linux_logo.h                | 1418 -------------------------
 include/asm-sparc/linux_logo.h             |  934 ----------------
 include/asm-sparc64/linux_logo.h           |  934 ----------------
 include/asm-um/linux_logo.h                |    6 
 include/asm-x86_64/linux_logo.h            |   29 
 include/linux/fb.h                         |    2 
 include/linux/linux_logo.h                 | 1435 -------------------------
 scripts/Makefile                           |    2 
 scripts/pnmtologo.c                        |  498 +++++++++
 45 files changed, 14090 insertions(+), 8748 deletions(-)

Detailed changes:

  - arch/mips64/Kconfig

    Add missing CONFIG_MIPS64

  - arch/ppc/syslib/prom.c

    Removed unused #include <asm/linux_logo.h>

  - arch/ppc/syslib/prom_init.c
    arch/ppc64/kernel/prom.c

    Modify PPC prom startup to use logo_linux_clut224 (if available)
    FIXME: verify RELOCs on ppc64

  - drivers/video/Kconfig

    Include drivers/video/logo/Kconfig

  - drivers/video/Makefile

    Enter drivers/video/logo if logo drawing is enabled

  - drivers/video/console/fbcon.c

    Remove obsolete LOGO_* definitions
    fb_show_logo() returns the logo height

  - drivers/video/console/newport_con.c

    Updates to call fb_find_logo()

  - drivers/video/fbmem.c

    Updates to call fb_find_logo()
    Support arbitrary logo sizes

  - drivers/video/hgafb.c

    Updates to call fb_find_logo()
    Support arbitrary logo sizes

  - drivers/video/logo/Kconfig

    Static logo selection code

  - drivers/video/logo/Makefile

    Logo makefile

  - drivers/video/logo/logo.c

    Dynamic logo selection code

  - drivers/video/logo/logo_dec_clut224.ppm
    drivers/video/logo/logo_linux_clut224.ppm
    drivers/video/logo/logo_linux_mono.pbm
    drivers/video/logo/logo_linux_vga16.ppm
    drivers/video/logo/logo_mac_clut224.ppm
    drivers/video/logo/logo_sgi_clut224.ppm
    drivers/video/logo/logo_sun_clut224.ppm
    drivers/video/logo/logo_superh_clut224.ppm
    drivers/video/logo/logo_superh_mono.pbm
    drivers/video/logo/logo_superh_vga16.ppm

    Logos in ASCII PNM format, converted from old logo includes

  - include/asm-alpha/linux_logo.h
    include/asm-arm/linux_logo.h
    include/asm-i386/linux_logo.h
    include/asm-ia64/linux_logo.h
    include/asm-m68k/linux_logo.h
    include/asm-m68knommu/linux_logo.h
    include/asm-mips/linux_logo.h
    include/asm-mips/linux_logo_dec.h
    include/asm-mips/linux_logo_sgi.h
    include/asm-mips64/linux_logo.h
    include/asm-parisc/linux_logo.h
    include/asm-ppc/linux_logo.h
    include/asm-ppc64/linux_logo.h
    include/asm-sh/linux_logo.h
    include/asm-sparc/linux_logo.h
    include/asm-sparc64/linux_logo.h
    include/asm-um/linux_logo.h
    include/asm-x86_64/linux_logo.h

    Remove old logo includes

  - include/linux/fb.h

    Make fb_image.data const

  - include/linux/linux_logo.h

    New logo definitions

  - scripts/Makefile

    Add pnmtologo

  - scripts/pnmtologo.c

    Logo conversion program (ASCII PNM to hex C source data)


The patch is quite large (+1 MiB uncompressed), so I put it up for download:

    http://home.tvd.be/cr26864/Linux/fbdev/linux-logo-2.5.56.diff.bz2

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

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

accel_putcs() calls fb_sync() after fb_imageblit(), except if fontwidth is not
a multiple of 8 and it falls back to individual drawing of the characters. This
patch adds the missing call to fb_sync().

It also replaces `vc->vc_font.height * width' by its precalculated value in
`cellsize'.

--- linux-2.5.56/drivers/video/console/fbcon.c	Thu Jan  2 12:54:55 2003
+++ linux-geert-2.5.56/drivers/video/console/fbcon.c	Sun Jan 12 13:20:53 2003
@@ -418,17 +415,17 @@
 			dst0 += width;
 		}
 		info->fbops->fb_imageblit(info, &image);
-		if (info->fbops->fb_sync)
-			info->fbops->fb_sync(info);
 	} else {
 		image.width = vc->vc_font.width;
 		while (count--) {
-			image.data = p->fontdata + 
-				(scr_readw(s++) & charmask) * vc->vc_font.height * width;
+			image.data = p->fontdata +
+				(scr_readw(s++) & charmask) * cellsize;
 			info->fbops->fb_imageblit(info, &image);
 			image.dx += vc->vc_font.width;
-		}	
+		}
 	}
+	if (info->fbops->fb_sync)
+		info->fbops->fb_sync(info);
 	/*
 	if (pixmap);
 		kfree(pixmap);

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: [BK fbdev updates]

[Jens A. <ax...@su...>]

On Sat, Jan 11 2003, James Simmons wrote:
> 
> Linus, please do a

James,

2.5 still doesn't work on my vaio (I think I told you about this 3-4
months ago) with the neofb. It just crashes with a black screen. If you
don't have any clues what the problem is, I can hook the machine up to a
serial console and see if anything interesting pops up. Using vesafb
does make it boot, however the screen stays pitch black until X loads...

-- 
Jens Axboe

Re: [Linux-fbdev-devel] fonts

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

On 12 Jan 2003, Antonino Daplas wrote:
> On Sun, 2003-01-12 at 03:15, Geert Uytterhoeven wrote:
> > I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
> >   - PEARL8x8: OK
> >   - SUN12x22: garbage (random characters)
> >   - ProFont6x11: garbage (each different line is filled with a different
> >     character)
> >   - MINI4x6: garbage (each different line is filled with a different
> >     character)
> > 
> > At first I thought it may be caused by xres and yres not divisible by the
> > fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
> > same, except that only a 640x600 window in the right part of the screen was
> > used.
> > 
> > Is my planar code in amifb to blane, or have other people seen the same?
> > 
> 
> The cfb_imageblit() function exhibited the same behavior.  I think we
> both made the wrong assumption that all monochrome bitmaps are packed. I
> think the rule is:
> 
>     The first pixel on the next scanline is always at the next byte from
>     the last pixel of the current scanline.  
> 
> So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> last 4 are used as padding.  It's worse with a 4x6 fonts where the
> 4-bits are just duplicated in the other nibble.

Yes.

But that was not my problem. Currently accel_putcs() falls back to individual
character drawing if the fontwidth is not a multiple of 8, and reuses the same
struct fb_image for each call of fb_imageblit(). And since my fb_imageblit()
had a loop like `while (image->height--) { ... }' it failed. Not modifying the
passed struct fb_image fixed the problem. Yes, we need the const 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

Re: [Linux-fbdev-devel] fonts

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

On Sun, 2003-01-12 at 03:15, Geert Uytterhoeven wrote:
> 
> I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
>   - PEARL8x8: OK
>   - SUN12x22: garbage (random characters)
>   - ProFont6x11: garbage (each different line is filled with a different
>     character)
>   - MINI4x6: garbage (each different line is filled with a different
>     character)
> 
> At first I thought it may be caused by xres and yres not divisible by the
> fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
> same, except that only a 640x600 window in the right part of the screen was
> used.
> 
> Is my planar code in amifb to blane, or have other people seen the same?
> 

The cfb_imageblit() function exhibited the same behavior.  I think we
both made the wrong assumption that all monochrome bitmaps are packed. I
think the rule is:

    The first pixel on the next scanline is always at the next byte from
    the last pixel of the current scanline.  

So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
last 4 are used as padding.  It's worse with a 4x6 fonts where the
4-bits are just duplicated in the other nibble.

It's a simple fix for imageblit. So here's a patch.

a. Fix for slow_imageblit() so fonts with widths not a multiple of 8
will work.

b. Fixed fast_imageblit() so it always access tables as 32-bit for it to
to work with a 64-bit machine.

James, can you apply?
 
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-12 09:48:47.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-12 10:06:59.000000000 +0000
@@ -88,11 +88,13 @@
 
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp)        (32 - bpp)
 #define NEXT_POS(pos, bpp)     ((pos) -= (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) >> (bits))
 #define SHIFT_LOW(val, bits)   ((val) << (bits))
 #else
 #define LEFT_POS(bpp)          (0)
+#define LEFT_POS32(bpp)        (0)
 #define NEXT_POS(pos, bpp)     ((pos) += (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
@@ -161,7 +163,7 @@
 				  unsigned long fgcolor, unsigned long bgcolor, 
 				  unsigned long start_index, unsigned long pitch_index)
 {
-	unsigned long i, j, l = 8;
+	unsigned long i, j, l;
 	unsigned long shift, color, bpp = p->var.bits_per_pixel;
 	unsigned long *dst, *dst2, val, pitch = p->fix.line_length;
 	unsigned long null_bits = BITS_PER_LONG - bpp;
@@ -170,10 +172,11 @@
 	dst2 = (unsigned long *) dst1;
 
 	for (i = image->height; i--; ) {
-		shift = 0;
-		val = 0;
+		shift = val = 0;
+		l = 8;
 		j = image->width;
 		dst = (unsigned long *) dst1;
+		s = src;
 
 		/* write leading bits */
 		if (start_index) {
@@ -182,35 +185,33 @@
 			val = FB_READL(dst) & start_mask;
 			shift = start_index;
 		}
+
 		while (j--) {
 			l--;
-			if (*src & (1 << l)) 
-				color = fgcolor;
-			else 
-				color = bgcolor;
+			color = (*s & (1 << l)) ? fgcolor : bgcolor;
 			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			
 			/* Did the bitshift spill bits to the next long? */
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
-				if (shift == null_bits)
-					val = 0;
-				else
-					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+				val = (shift == null_bits) ? 
+					0 : SHIFT_LOW(color, BITS_PER_LONG - shift);
 			}
 			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
-			if (!l) { l = 8; src++; };
+			if (!l) { l = 8; s++; };
 		}
+
 		/* write trailing bits */
  		if (shift) {
 			unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
 
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
-		dst1 += pitch;	
 
+		dst1 += pitch;	
+		src += (image->width + 7)/8;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (char *) dst2;
@@ -224,25 +225,25 @@
 }
 
 static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1, 
-				  unsigned long fgcolor, unsigned long bgcolor) 
+				  u32 fgcolor, u32 bgcolor) 
 {
 	int i, j, k, l = 8, n;
-	unsigned long bit_mask, end_mask, eorx; 
-	unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
-	unsigned long tmp = (1 << bpp) - 1;
-	unsigned long ppw = BITS_PER_LONG/bpp, ppos;
-	unsigned long *dst;
+	u32 bit_mask, end_mask, eorx; 
+	u32 fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+	u32 tmp = (1 << bpp) - 1;
+	u32 ppw = 32/bpp, ppos;
+	u32 *dst;
 	u32 *tab = NULL;
 	char *src = image->data;
 		
-	switch (ppw) {
-	case 4:
+	switch (bpp) {
+	case 8:
 		tab = cfb_tab8;
 		break;
-	case 2:
+	case 16:
 		tab = cfb_tab16;
 		break;
-	case 1:
+	case 32:
 		tab = cfb_tab32;
 		break;
 	}
@@ -264,17 +265,17 @@
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
-		dst = (unsigned long *) dst1;
-		
+		dst = (u32 *) dst1;
 		for (j = k; j--; ) {
 			l -= ppw;
 			end_mask = tab[(*src >> l) & bit_mask]; 
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
+			fb_writel((end_mask & eorx)^bgx, dst++);
 			if (!l) { l = 8; src++; }
 		}
+
 		if (n) {
 			end_mask = 0;	
-			ppos = LEFT_POS(bpp);
+			ppos = LEFT_POS32(bpp);
 			for (j = n; j > 0; j--) {
 				l--;
 				if (*src & (1 << l))
@@ -282,9 +283,9 @@
 				NEXT_POS(ppos, bpp);
 				if (!l) { l = 8; src++; }
 			}
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
+			fb_writel((end_mask & eorx)^bgx, dst++);
 		}
-		l -= pad;		
+		l -= pad;
 		dst1 += p->fix.line_length;	
 	}
 }	

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

 drivers/video/tridentfb.h        |  169 ----
 include/video/font.h             |   24
 arch/m68k/kernel/m68k_defs.c     |    2
 drivers/video/Kconfig            |    2
 drivers/video/Makefile           |    7
 drivers/video/aty/atyfb.h        |    1
 drivers/video/aty/atyfb_base.c   |   93 --
 drivers/video/aty/mach64_accel.c |   12
 drivers/video/console/Kconfig    |   14
 drivers/video/console/fbcon.c    |   90 +-
 drivers/video/console/sticon.c   |  101 +-
 drivers/video/console/sticore.c  |  159 ++--
 drivers/video/fbmem.c            |   13
 drivers/video/fbmon.c            |  411 ++++++++++
 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            |  711 +++++++++---------
 drivers/video/sstfb.h            |   31
 drivers/video/sticore.h          |   58 -
 drivers/video/stifb.c            |  103 ++
 drivers/video/tridentfb.c        | 1213 +++++++++++++++-----------------
 include/linux/fb.h               |   13
 include/linux/font.h             |   30
 include/video/trident.h          |  175 ++++
 32 files changed, 3195 insertions(+), 2429 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/01/11 1.891)
   [TRIDENT FBDEV] Driver ported to the new api.

<jsi...@ma...> (03/01/10 1.887.1.4)
   Final updtes to the GTF code. Now the code can gnerate GTF timings regardless of the validity of info->monospecs.

   [ATYFB] Updates to the aty driver.

<jsi...@ma...> (03/01/08 1.887.1.1)
   Remove fb_set_var. Some how it was missed in a merge conflict.

<jsimmons@kozmo.(none)> (03/01/08 1.889)
   [ATY] Somehow a merge mistake happened. We removed fb_set_var.

<jsi...@ma...> (03/01/08 1.887)
   [MONITOR support] GTF support for VESA complaint monitors. Here we calculate the general timings needed so we don't over step the bounds for a monitor.

   [fbmem.c cleanup] Name change to make teh code easier to read.

<jsi...@ma...> (03/01/07 1.879.2.95)
   Updates from Helge Deller for the console/fbdev drivers for the PARISC platform. Small fix for clearing the screen and a string typo for the Voodoo 1/2 driver.

<jsi...@ma...> (03/01/06 1.879.2.93)
   [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.879.2.92)
   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.879.2.91)
   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.

Standard diff is at

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

[Linux-fbdev-devel] vesafb and too much RAM?

[Matt N. <ma...@if...>]

I was running debian with a 2.4.20(-3 I believe) with vesafb with no
problems with 512MB ram. I upgraded to 1GB and immediately I could not
boot. I get as far as the LILO prompt, but as soon as I hit enter the
screen goes black, the caps lock and scroll lock keyboard LEDs flash, and
nothing save hitting the reset switch has any affect.

I can append 'mem=768M' to the kernel command line and everything boots
like normal except of course that then it think I have only 768MB RAM. If
I tell the kernel not to use vesafb by removing the 'vga=' line in my
lilo.conf then everything boot fine and my RAM is recognized.

I also have a second install of debian with kernel 2.4.19 on the same
machine. With this kernel it actually boots, however the screen stays
black. I can log in blindly and issue commands and dmesg reported the
following:

"vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xd8000000"

This kernel also behaves normally if I specify 'mem=768M' on the kernel
command line or if I specify vga=normal (overriding my normal vga=792 from
lilo.conf). With 'mem=768M' set dmesg shows:

 vesafb: framebuffer at 0xd8000000, mapped to 0xf080e000, size 131072k
 vesafb: mode is 1024x768x32, linelength=4096, pages=1
 vesafb: protected mode interface info at c000:e350
 vesafb: scrolling: redraw
 vesafb: directcolor: size=8:8:8:8, shift=24:16:8:0
 Console: switching to colour frame buffer device 128x48
 fb0: VESA VGA frame buffer device

with 2.4.20 and 'mem=768M'

 vesafb: framebuffer at 0xd8000000, mapped to 0xf0800000, size 131072k
 vesafb: mode is 1024x768x32, linelength=4096, pages=1
 vesafb: protected mode interface info at c000:e350
 vesafb: scrolling: redraw
 vesafb: directcolor: size=8:8:8:8, shift=24:16:8:0
 Console: switching to colour frame buffer device 128x48
 fb0: VESA VGA frame buffer device

In testing I have found that I can go as high as 'mem=880M' with no
problem but 'mem=881M' ends in the same results as described above.

I don't know if this is a bug or something I may have overlooked or failed
to do. Hope someone can understand whats happening.

Thanks and regards,
Matt N.

Re: [Linux-fbdev-devel] fonts

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

On Sat, 11 Jan 2003, Geert Uytterhoeven wrote:
> I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
>   - PEARL8x8: OK
>   - SUN12x22: garbage (random characters)
>   - ProFont6x11: garbage (each different line is filled with a different
>     character)
>   - MINI4x6: garbage (each different line is filled with a different
>     character)
> 
> At first I thought it may be caused by xres and yres not divisible by the
> fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
> same, except that only a 640x600 window in the right part of the screen was
> used.
> 
> Is my planar code in amifb to blane, or have other people seen the same?

BTW, VGA8x16 also works.

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

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

I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
  - PEARL8x8: OK
  - SUN12x22: garbage (random characters)
  - ProFont6x11: garbage (each different line is filled with a different
    character)
  - MINI4x6: garbage (each different line is filled with a different
    character)

At first I thought it may be caused by xres and yres not divisible by the
fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
same, except that only a 640x600 window in the right part of the screen was
used.

Is my planar code in amifb to blane, or have other people seen the same?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

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

On Sat, 2003-01-11 at 21:24, Geert Uytterhoeven wrote:
> > 
> > Do you think this will work?  The only problem I can think of is a color
> > expansion request where both bg and fg is 0.
> 
> And that can happen, try <ESC>[31m<ESC>[41m to set both to red.
> 
> > Or to totally eliminate the above possibility, add an extra field in
> > struct fb_image to denote color expansion vs logo drawing.  Again, only
> > mono cards will need to do this test.
> 
> Ugh, why invent a new field if we can use an existing field? depth == 0 is
> invalid for image blitting anyway.
> 

No argument here.

Tony

Re: [Linux-fbdev-devel] LCD scaling type

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

On Sat, 2003-01-11 at 21:29, Geert Uytterhoeven wrote:
> On 11 Jan 2003, Antonino Daplas wrote:
> > I also have a couple of things that come to mind (like switching from
> > truecolor to directcolor and vice versa without rebooting).  I currently
> > use var->nonstd which is probably not the the right thing to do.
> 
> Since directcolor is a superset of truecolor, shouldn't a driver always use
> directcolor, if the hardware supports it?
> 
Some apps don't know how to treat directcolor.  DirectFB-0.9.15 is
messed up when visual is in directcolor, so I need truecolor here. I
submitted a patch to them so it should get fixed with their next
release.

However, when I go to X, I want it to be in directcolor, for gamma
utilities to work 

Tony

Re: [Linux-fbdev-devel] LCD scaling type

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

On 11 Jan 2003, Antonino Daplas wrote:
> I also have a couple of things that come to mind (like switching from
> truecolor to directcolor and vice versa without rebooting).  I currently
> use var->nonstd which is probably not the the right thing to do.

Since directcolor is a superset of truecolor, shouldn't a driver always use
directcolor, if the hardware supports it?

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] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Jak <rf...@ei...>]

With so much good development being done on framebuffer drivers at the mo=
ment, perhaps
the following is only a temporary problem, but I hope the following repor=
t is of some use.

I seem to be triggering a reproducible bug when loading rivafb, whether i=
t is built-in or modular
with both 2.5.54 & 2.5.55 ( and, I suspect, 2.5.53 also ).
I have tried rivafb on 2 different nVidia cards, both yield the similar r=
esults when using recent
( Jan 8 ) fbdev.diff.gz patch.

After rivafb is loaded, the display goes bright green. After entering a c=
ommand, I get
text back, but colours are wrong - there is no visible blue on screen i.e=
 with colorized
ls listing, normally blue text is bright green, normally red is ( brighte=
r ) red, normally white
is grey.

This is from 2.5.55 with fbdev.diff.gz applied, rivafb and fbcon both mod=
ular:
I have manually insmodded cfbimgblt & vgastate, then insmod rivafb

Jan 11 12:30:41 TBird kernel: rivafb: nVidia device/chipset 10DE002C
Jan 11 12:30:41 TBird kernel: rivafb: RIVA MTRR set to ON
Jan 11 12:30:41 TBird kernel: rivafb: PCI nVidia NV4 framebuffer ver 0.9.=
5b (nVidiaRIVA-VTNT2, 16
MB @ 0xD0000000)
Jan 11 12:30:41 TBird kernel: Badness in kobject_register at lib/kobject.=
c:129
Jan 11 12:30:41 TBird kernel: Call Trace:
Jan 11 12:30:41 TBird kernel:  [<d08d43b4>] rivafb_driver+0x54/0xfffddd00=
 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<c01c6aa6>] kobject_add+0x56/0x60
Jan 11 12:30:41 TBird kernel:  [<d08d43a4>] rivafb_driver+0x44/0xfffddd00=
 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<c01f67f9>] bus_remove_device+0x59/0xc0
Jan 11 12:30:41 TBird kernel:  [<d08d43a4>] rivafb_driver+0x44/0xfffddd00=
 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<d08d3078>] +0x0/0xfffdefe8 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<c01f6c51>] put_driver+0x31/0x40
Jan 11 12:30:41 TBird kernel:  [<d08d4388>] rivafb_driver+0x28/0xfffddd00=
 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<c01cb369>] pci_device_resume+0x49/0x60
Jan 11 12:30:41 TBird kernel:  [<d08d4388>] rivafb_driver+0x28/0xfffddd00=
 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<d08b2032>] 0xd08b2032
Jan 11 12:30:41 TBird kernel:  [<d08d4360>] rivafb_driver+0x0/0xfffddd00 =
[rivafb]
Jan 11 12:30:41 TBird kernel:  [<d08d5d00>] +0x0/0xfffdc360 [rivafb]
Jan 11 12:30:41 TBird kernel:  [<c012ca97>] load_module+0x117/0x1c0
Jan 11 12:30:41 TBird kernel:  [<c0109327>] system_call+0x7/0xb
Jan 11 12:30:41 TBird kernel:
Module                  Size  Used by
rivafb                 45444  0
cfbimgblt               2880  1 rivafb
vgastate                9472  1 rivafb
mousedev                7256  1

Now I rmmod rivafb and insmod it again :

Module                  Size  Used by
cfbimgblt               2880  0
vgastate                9472  0
mousedev                7256  1
Jan 11 12:35:29 TBird kernel: Badness in kobject_register at lib/kobject.=
c:129
Jan 11 12:35:29 TBird kernel: Call Trace:
Jan 11 12:35:29 TBird kernel:  [<d08d43b4>] rivafb_driver+0x54/0xfffddd00=
 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<c01c6aa6>] kobject_add+0x56/0x60
Jan 11 12:35:29 TBird kernel:  [<d08d43a4>] rivafb_driver+0x44/0xfffddd00=
 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<c01f67f9>] bus_remove_device+0x59/0xc0
Jan 11 12:35:29 TBird kernel:  [<d08d43a4>] rivafb_driver+0x44/0xfffddd00=
 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<d08d3078>] +0x0/0xfffdefe8 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<c01f6c51>] put_driver+0x31/0x40
Jan 11 12:35:29 TBird kernel:  [<d08d4388>] rivafb_driver+0x28/0xfffddd00=
 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<c01cb369>] pci_device_resume+0x49/0x60
Jan 11 12:35:29 TBird kernel:  [<d08d4388>] rivafb_driver+0x28/0xfffddd00=
 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<d08b2032>] 0xd08b2032
Jan 11 12:35:29 TBird kernel:  [<d08d4360>] rivafb_driver+0x0/0xfffddd00 =
[rivafb]
Jan 11 12:35:29 TBird kernel:  [<d08d5d00>] +0x0/0xfffdc360 [rivafb]
Jan 11 12:35:29 TBird kernel:  [<c012ca97>] load_module+0x117/0x1c0
Jan 11 12:35:29 TBird kernel:  [<c0109327>] system_call+0x7/0xb
Jan 11 12:35:29 TBird kernel:
Module                  Size  Used by
rivafb                 45444  0
cfbimgblt               2880  1 rivafb
vgastate                9472  1 rivafb
mousedev                7256  1

BTW1: With stock 2.5.5 and modular rivafb, module will not load, this is =
what  I get :
Jan 10 12:49:53 TBird kernel: rivafb: falsely claims to have parameter fo=
nt

BTW2: the FBCON_ADVANCED  "Advanced low level driver options" still shows=
 up in=20
make *config, but does not seem to do much - should it still be there ?

BTW3: the second nVidia card I referred to is on my new laptop, using Gef=
orce4 420 Go
card, which is not yet supported in 2.4.x, but seems to be detected prope=
rly in 2.5.x.

Loading fbcon causes bigger problems : serial OOPSes shortly followed by =
complete lockup
accel_putcs always seems to be implicated.

Jan 11 12:36:51 TBird kernel: Call Trace:
Jan 11 12:36:51 TBird kernel:  [<d08cd437>] accel_putcs+0x157/0xfffe4f95 =
[fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d2d30>] +0x30/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d2d00>] +0x0/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<c017a731>] ext3_get_block_handle+0x51/0x=
90
Jan 11 12:36:51 TBird kernel:  [<c0211b2c>] blk_recount_segments+0xdc/0x1=
50
Jan 11 12:36:51 TBird kernel:  [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb=
con]
Jan 11 12:36:51 TBird kernel:  [<d08ce976>] fbcon_putcs+0x86/0xfffe3985 [=
fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb=
con]
Jan 11 12:36:51 TBird kernel:  [<c020b14b>] set_console+0x24b/0x300
Jan 11 12:36:51 TBird kernel:  [<c011c350>] sys_syslog+0x60/0x70
Jan 11 12:36:51 TBird kernel:  [<c011c42c>] _call_console_drivers+0x5c/0x=
120
Jan 11 12:36:51 TBird kernel:  [<c011c73f>] acquire_console_sem+0x3f/0xa0
Jan 11 12:36:51 TBird kernel:  [<c011c669>] emit_log_char+0x109/0x140
Jan 11 12:36:51 TBird kernel:  [<c0129eb5>] __constant_c_and_count_memset=
+0x35/0x40
Jan 11 12:36:51 TBird kernel:  [<c0117b3f>] bust_spinlocks+0x21f/0x4b8
Jan 11 12:36:51 TBird kernel:  [<c021fbd6>] execute_drive_cmd+0xf6/0x1a0
Jan 11 12:36:51 TBird kernel:  [<c021fda7>] ide_stall_queue+0xd7/0x1d0
Jan 11 12:36:51 TBird kernel:  [<c021febf>] ide_do_request+0x1f/0x30
Jan 11 12:36:51 TBird kernel:  [<c0212152>] blk_remove_plug+0x42/0x50
Jan 11 12:36:51 TBird kernel:  [<c0118f9a>] scheduling_functions_start_he=
re+0x16a/0x2a0
Jan 11 12:36:51 TBird kernel:  [<d08d324f>] +0x54f/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<c0117920>] bust_spinlocks+0x0/0x4b8
Jan 11 12:36:51 TBird kernel:  [<c0109d31>] divide_error+0x2d/0x38
Jan 11 12:36:51 TBird kernel:  [<d08d324f>] +0x54f/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08c1ef0>] fontdata_8x16+0x210/0x2f73e32=
0 [font]
Jan 11 12:36:51 TBird kernel:  [<d08d4300>] +0x1600/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08cd437>] accel_putcs+0x157/0xfffe4f95 =
[fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d2d50>] +0x50/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d2d00>] +0x0/0xfffdf575 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb=
con]
Jan 11 12:36:51 TBird kernel:  [<d08ce976>] fbcon_putcs+0x86/0xfffe3985 [=
fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb=
con]
Jan 11 12:36:51 TBird kernel:  [<c0207224>] scrdown+0x124/0x190
Jan 11 12:36:51 TBird kernel:  [<c0207e20>] set_origin+0x150/0x180
Jan 11 12:36:51 TBird kernel:  [<c02083f3>] vc_allocate+0x303/0x420
Jan 11 12:36:51 TBird kernel:  [<d08ce27d>] fbcon_set_display+0x31d/0xfff=
e4315 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<c0135cb8>] cache_free_debugcheck+0xb8/0x=
d0
Jan 11 12:36:51 TBird kernel:  [<c0134e36>] kmem_cache_alloc+0x96/0xd0
Jan 11 12:36:51 TBird kernel:  [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb=
con]
Jan 11 12:36:51 TBird kernel:  [<d08cdac9>] fbcon_init+0x59/0xfffe4805 [f=
bcon]
Jan 11 12:36:51 TBird kernel:  [<d08d1820>] fb_con+0x0/0xfffe0a55 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<c0207f1c>] vc_cons_allocated+0xac/0x110
Jan 11 12:36:51 TBird kernel:  [<c020b8ba>] clear_buffer_attributes+0xaa/=
0x1c0
Jan 11 12:36:51 TBird kernel:  [<d08d2bc0>] +0x0/0xfffdf6b5 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d1939>] +0x1d/0xfffe0959 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08d2bc0>] +0x0/0xfffdf6b5 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<d08b226d>] 0xd08b226d
Jan 11 12:36:51 TBird kernel:  [<d08d1820>] fb_con+0x0/0xfffe0a55 [fbcon]
Jan 11 12:36:51 TBird kernel:  [<c012ca97>] load_module+0x117/0x1c0
Jan 11 12:36:51 TBird kernel:  [<c0109327>] system_call+0x7/0xb

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

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

On 11 Jan 2003, Antonino Daplas wrote:
> On Sat, 2003-01-11 at 03:43, Geert Uytterhoeven wrote:
> > On Fri, 10 Jan 2003, James Simmons wrote:
> > >    I'm just not to crazy about the depth equal zero thing. I just pitcure 
> > > developers having a hard time with it.
> > 
> > Monochrome color expansion just works differently: it expands the zeroes and
> > ones in a bitmap based on fg_color and bg_color, while image drawing draws an
> > image containing colormap indices to the frame buffer.
> > 
> > Do you have a better suggestion?
> > 
> 
> If James is a bit skeptical about this, how about doing it this way:
> 
> If image.fg_color and image.bg_color == 0, then each byte of image.data
> is an index to the pseudo_palette, or the actual pixel, whatever the
> case may be.  Otherwise, image.data is a monochrome bitmap that should
> be expanded using fg_color and bg_color.
> 
> No other changes will be needed except that mono cards have to test for
> fg_color and bg_color, and we need to memset the fb_image structure to 0
> in fb_set_logo(). Non-mono cards will continue testing for image.depth.
> 
> Do you think this will work?  The only problem I can think of is a color
> expansion request where both bg and fg is 0.

And that can happen, try <ESC>[31m<ESC>[41m to set both to red.

> Or to totally eliminate the above possibility, add an extra field in
> struct fb_image to denote color expansion vs logo drawing.  Again, only
> mono cards will need to do this test.

Ugh, why invent a new field if we can use an existing field? depth == 0 is
invalid for image blitting anyway.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] LCD scaling type

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

On Sat, 2003-01-11 at 20:08, Benjamin Herrenschmidt wrote:
> 
> For my immediate need, however, I still think turning one of the
> reserved fields of var_screeninfo into a "mode_flags" would be useful,
> we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the
> driver to not bother keeping aspect ratio (the idea here is that keeping
> aspect ratio is the default, so 0, even if that's nor really working yet
> in radeonfb or aty128fb).
>  

I wasn't contradicting you.  A new feature that can be supported by
different hardware and is quite useful deserves a unique flag, and I
definitely agree with that.  I don't to see my desktop flattened top to
bottom if I can prevent it.

But aside from the above, I also need a field which is interpreted
differently from driver to driver, and is so nebulous that it doesn't
deserve its own flag.  Just something that can be used to poke the
hardware from user space without writing a utility each time. 
Currently, I'm doing this by setting bits in var->nonstd.

Tony

Re: [Linux-fbdev-devel] LCD scaling type

[Benjamin H. <be...@ke...>]

On Sat, 2003-01-11 at 12:35, Antonino Daplas wrote:
> If you only need to do is turn something on or off, assigning it an
> ioctl may be too much.  The "feature" can be anything, not just a mode
> setting. Also, you will have fbdev drivers writing their own ioctls just
> for these "little" features, and each will need to have its own utility
> written specifically for the driver.  If you have an
> fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be
> used for all drivers.  One can even collect all possible 'hardware'
> tweaks and create a general fb tweaks utility just by using fbset.
> 
> Of course, if the feature requires something more than just turning a
> switch on and off, then an ioctl is more practical.

Hrm... I think this is going too far for var_screeninfo. However,
we do have need for such "tunable" settings, that can be
brightness/contrast/backlight kind of stuff, geometry on some i2c-driven
monitors (iMacs typically) etc...

It may be interesting to think about an API where the fbdev (or the
monitor layer, which is something we currently lack that should probably
sit on top of fbdev) to expose the available "settings" and have std
ioctls to get/set their values. A bit like sound mixer settings work
today maybe.

For my immediate need, however, I still think turning one of the
reserved fields of var_screeninfo into a "mode_flags" would be useful,
we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the
driver to not bother keeping aspect ratio (the idea here is that keeping
aspect ratio is the default, so 0, even if that's nor really working yet
in radeonfb or aty128fb).
 

-- 
Benjamin Herrenschmidt <be...@ke...>

Re: [Linux-fbdev-devel] waitretrace available?

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

On Sat, 2003-01-11 at 19:21, Xanthakis Stelios wrote:
> 
> Is there WAITRETRACE available in fb?
> 
> It seems that there used to be because svgalib sais:
> 
> 	static void fbdev_waitretrace(void)
> 	{
> 		/* This is from SDL */
> 	#ifdef FBIOWAITRETRACE
> 		ioctl(console_fd, FBIOWAITRETRACE, 0);
> 	#endif
> 	}
> 

There is an FBIO_GETVBLANK that gives information on the current status
of the display (such as if it's currently in hsync/vsync, the current
vsync count since boot etc).  However, only matroxfb implements this
ioctl.

There is an unofficial patch (also for matroxfb), FBIO_VSYNCIRQ, which
waits for the retrace by sleeping on a vsync interrupt.  

> But I can't find such a value in the headers.
> Seems like WAITRETRACE call is implemented in svga by:
> 
> 	while (!(inb(0x3da) & 8));
> 	while (inb(0x3da) & 8);
> 
> 
> *I know very little on how video hardware works*
>

It's a standard polling code for waiting for the retrace interval on VGA
hardware.  Most graphics hardware will still work.  However, it eats CPU
cycles.  The sleeping on an interrupt way is better.
 
> The goal is to attempt some smooth scrolling. 
> Back in the MS-DOS days there used to be a program
> called smooth editor which was amazing (so amazing that
> I used to do Page up/Down all the time w/o doing
> any work). I was thinking if I could have some similar
> smooth scrolling in my linux fb console.
> 

You can accomplish the same effect using the above code, provide the
hardware mode supports it, and provided you are not doing too many tasks
at one time, else you'll experience frame skips, sound stutters etc. 

> I recall that smooth editor explained that smooth scrolling
> was achieved by "synchronizing with the video refresh"
> (horizontal?, vertical? I don't remember). That's retrace yes?

Yes, it's vertical.

> 
> So, can we by some way do waitretrace at each \n?
> Should this be userland or kernelland?
> 

Depends.  The polling code can be done in userland.  However, newer
hardware has better ways of waiting for the retrace.  In these cases, it
has to be done within the driver.  See how the matroxfb patch does that.
It's in the DirectFB package (www.directfb.org).  Also, you may want to
check the DRI mailing list archives (dri.sourceforge.net).  They have
discussions on that.

Tony

Re: [Linux-fbdev-devel] LCD scaling type

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

On Sat, 2003-01-11 at 19:08, Benjamin Herrenschmidt wrote:
> On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: 
> > 
> > Well, yes of course, if a particular hardware feature is quite useful
> > and common, then you need something definitive.  But what I also want is
> > another field which will serve as a private communication channel
> > between userspace and driver. Adventurous users/testers can use them to
> > turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
> > utilities common in MS Windows.
> 
> I already do that in some drivers using private ioctl's, though if
> what you want is really an additional "feature" affecting a mode
> setting, then it makes sense to fit it into fb_var_screeninfo
> 

If you only need to do is turn something on or off, assigning it an
ioctl may be too much.  The "feature" can be anything, not just a mode
setting. Also, you will have fbdev drivers writing their own ioctls just
for these "little" features, and each will need to have its own utility
written specifically for the driver.  If you have an
fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be
used for all drivers.  One can even collect all possible 'hardware'
tweaks and create a general fb tweaks utility just by using fbset.

Of course, if the feature requires something more than just turning a
switch on and off, then an ioctl is more practical.

Tony

[Linux-fbdev-devel] waitretrace available?

[Xanthakis S. <sx...@ce...>]

Is there WAITRETRACE available in fb?

It seems that there used to be because svgalib sais:

	static void fbdev_waitretrace(void)
	{
		/* This is from SDL */
	#ifdef FBIOWAITRETRACE
		ioctl(console_fd, FBIOWAITRETRACE, 0);
	#endif
	}

But I can't find such a value in the headers.
Seems like WAITRETRACE call is implemented in svga by:

	while (!(inb(0x3da) & 8));
	while (inb(0x3da) & 8);


*I know very little on how video hardware works*

The goal is to attempt some smooth scrolling. 
Back in the MS-DOS days there used to be a program
called smooth editor which was amazing (so amazing that
I used to do Page up/Down all the time w/o doing
any work). I was thinking if I could have some similar
smooth scrolling in my linux fb console.

I recall that smooth editor explained that smooth scrolling
was achieved by "synchronizing with the video refresh"
(horizontal?, vertical? I don't remember). That's retrace yes?

So, can we by some way do waitretrace at each \n?
Should this be userland or kernelland?


stelios

Re: [Linux-fbdev-devel] LCD scaling type

[Benjamin H. <be...@ke...>]

On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: 
> 
> Well, yes of course, if a particular hardware feature is quite useful
> and common, then you need something definitive.  But what I also want is
> another field which will serve as a private communication channel
> between userspace and driver. Adventurous users/testers can use them to
> turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
> utilities common in MS Windows.

I already do that in some drivers using private ioctl's, though if
what you want is really an additional "feature" affecting a mode
setting, then it makes sense to fit it into fb_var_screeninfo

-- 
Benjamin Herrenschmidt <be...@ke...>

Re: [Linux-fbdev-devel] LCD scaling type

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

On Sat, 2003-01-11 at 17:47, Benjamin Herrenschmidt wrote:
> On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote:
> > On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:
> 
> > I second to this.  It's useful to have an extra field in
> > fb_var_screeninfo for drivers to play around.  It's like an extension
> > field and its main use is to expose a hardware capability which is
> > uncommon enough to warrant generic support.  It's meaning will vary from
> > driver to driver.  
> 
> I don't fully agree here. While I agree a driver specific field might
> be useful, I beleive the "flags" field should have defined meaning.
> 
> > I also have a couple of things that come to mind (like switching from
> > truecolor to directcolor and vice versa without rebooting).  I currently
> > use var->nonstd which is probably not the the right thing to do.
> 
> For this too, defined flags would make sense as other driver might want
> to implement the same capability, in which case we really want all of
> them to do it the same way.
> 

Well, yes of course, if a particular hardware feature is quite useful
and common, then you need something definitive.  But what I also want is
another field which will serve as a private communication channel
between userspace and driver. Adventurous users/testers can use them to
turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
utilities common in MS Windows.

Tony

Re: [Linux-fbdev-devel] LCD scaling type

[Benjamin H. <be...@ke...>]

On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote:
> On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:

> I second to this.  It's useful to have an extra field in
> fb_var_screeninfo for drivers to play around.  It's like an extension
> field and its main use is to expose a hardware capability which is
> uncommon enough to warrant generic support.  It's meaning will vary from
> driver to driver.  

I don't fully agree here. While I agree a driver specific field might
be useful, I beleive the "flags" field should have defined meaning.

> I also have a couple of things that come to mind (like switching from
> truecolor to directcolor and vice versa without rebooting).  I currently
> use var->nonstd which is probably not the the right thing to do.

For this too, defined flags would make sense as other driver might want
to implement the same capability, in which case we really want all of
them to do it the same way.

-- 
Benjamin Herrenschmidt <be...@ke...>

Re: [Linux-fbdev-devel] LCD scaling type

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

On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:
> Hi !
> 
> When setting a mode on an LCD display that is not exactly the
> native mode of that display, we can, on some chips, setup a
> scaler. However, most of the time, we have 2 difference choices
> for setting up this scaler: It can preserve or not preserve
> the aspect ratio. A typical example is the titnium powerbook's 1152x768
> mode. If I set it to 1024x768, I can get either horizontal scaling (not
> preserving aspect ratio) or no scaling with black bars on left & right
> (preserving aspect ratio).
> 
> While in most case you actually want to preserve the aspect ratio, it
> would still I beleive make sense to let the user choose it. 
> 
> Could we define one of the reserved fields in fb_var_screeninfo as
> beeing a "flags" field for such things ? There are a couple of other
> things that we may want to stuff into such a bitfield later, I'd suggest
> reserving one 32 bits field for such flags.
> 

I second to this.  It's useful to have an extra field in
fb_var_screeninfo for drivers to play around.  It's like an extension
field and its main use is to expose a hardware capability which is
uncommon enough to warrant generic support.  It's meaning will vary from
driver to driver.  

I also have a couple of things that come to mind (like switching from
truecolor to directcolor and vice versa without rebooting).  I currently
use var->nonstd which is probably not the the right thing to do.

Tony

Re: [Linux-fbdev-devel] rotation.

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

On Sat, 2003-01-11 at 03:42, James Simmons wrote:
> 
> > > Yes. Hardware rotation shouldn't also not effect the way accel 
> > > operatations are done.
> >  
> > The main difference is if the hardware supports rotation, fbcon will
> > present it with "normal" data.  With the generic implementation, fbcon
> > will present the driver with rotated data.
> > 
> > So we need a driver capabilities field either in fb_info or
> > fb_fix_screeninfo.
> 
> We can just test if the rotation hook exist for the fbdev driver. No hook 
Okay.  What will the hook do, BTW?  Just turn hardware rotation to
the appropriate orientation?  Something like...

int fb_rotate(struct fb_info *info, int rotate);

Then we can do something like:

if (info->fbops->fb_rotate) {
	info->fbops->fb_rotate(info, FB_ROTATE_CCW);
	"pass 'normally' oriented data"
else
	"pass data rotated CCW"
}

Also, you may want to place the rotate field in fb_fix_screeninfo
instead.  You mentioned that rotation is to be activated at the console
layer, so the rotate field is for informational purposes only.

> then use generic code in fbcon. Also we have a angle field in var so we 
> can see if the user wants the data rotated.
> 
> > Not really.  We can dynamically rotate the fontdata using the default
> > display->fontdata into another buffer.  I believe I have functions that
> > do that in the patch I submitted.  (Sorry, I lost it when one of my
> > drives crashed :-(.
> 
> I have that patch. It just has to be updated to the latest changes.
> 
> 
Yeap.  Geert forwarded them to me.  Thanks Geert :-)

Tony

Re: [Linux-fbdev-devel] clipping

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

On Sat, 2003-01-11 at 04:31, James Simmons wrote:
> 
> > > > Except for the geek value, why would it be cleaner to draw half of a character
> > > > near the border?
> > > 
> > > This is one of the reasons why I moved from fbset to setting the console 
> > > resolution via the console layer. You can't end up with half characters. 
> > > Via fbset you could but fbcon had extra code to prevent such foolishness. 
> > > But it still looked silly to have half line on the bottom of the screen 
> > > that nothing ever drawed in.
> > 
> > What else can you do? My notebook has a fixed LCD of 1024x768. With the 12x22
> > font, I have a text console of 85x34, using only 1020x748 pixels. Shrinking the
> > resolution to 1020x748 is not an option.
> 
> Ug. I guess we handle it the best way we can. Also we can try BenH 
> suggesting of incorpating scaling. 
> 

Or we can modify fbcon_resize() so it just checks if the resulting
resolution is enough to accomodate the console window size...

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, x, y;

	var.xres = x = width * vc->vc_font.width;
	var.yres = y = height * vc->vc_font.height;
	var.activate = FB_ACTIVATE_TEST;
	err = fb_set_var(&var, info);
	if (err || var.xres < x || var.yres < y)
		return -EINVAL;

	var.activate = FB_ACTIVATE_NOW;
	err = fb_set_var(&var, info);
	p->vrows = info->var.yres_virtual/vc->vc_font.height;
	return err; 
}

...which implies that we also have to modify accel_clear_margins() so it
clears more than just a fraction of a character's width and height...

void accel_clear_margins(struct vc_data *vc, struct display *p,
				int bottom_only)
{
	struct fb_info *info = p->fb_info;
	unsigned int cw = vc->vc_font.width;
	unsigned int ch = vc->vc_font.height;
	unsigned int rw = info->var.xres - vc->vc_cols * cw;
	unsigned int bh = info->var.yres - vc->vc_rows * ch;
	unsigned int rs = info->var.xres - rw;
	unsigned int bs = info->var.yres - bh;
	struct fb_fillrect region;

	region.color = attr_bgcol_ec(p, vc);
	region.rop = ROP_COPY;

	if (rw & !bottom_only) {
		region.dx = info->var.xoffset + rs;
		region.dy = 0;
		region.width = rw;
		region.height = info->var.yres_virtual;
		info->fbops->fb_fillrect(info, &region);
	}

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

... which exposed a bug in vc_resize() in vt.c.  In vc_resize(), the
global variables:

	video_num_lines;
	video_num_columns;
	video_size_row;
	screenbuf_size;

are modified before calling consw->con_resize() which, if it returns
with an error, are left with invalid numbers. So attached is a patch.

It behaves correctly now.  When the resulting resolution is bigger than
the console window size, it's left with a small window at the upper left
corner.  So stty must be called so rows and cols are enough but no
bigger than the supported resolution.

This works pretty well if panning is disabled.  With panning, I get a
cursor "dissynchronous" with the display and where the virtual screen is
randomly placed anywhere within the display window.

We might need to fix for scrolling + panning here.

Tony

diff -Naur linux-2.5.54/drivers/char/vt.c linux/drivers/char/vt.c
--- linux-2.5.54/drivers/char/vt.c	2003-01-11 04:47:02.000000000 +0000
+++ linux/drivers/char/vt.c	2003-01-11 04:47:49.000000000 +0000
@@ -732,24 +732,24 @@
 	if (new_cols == video_num_columns && new_rows == video_num_lines)
 		return 0;
 
-	newscreen = (unsigned short *) kmalloc(new_screen_size, GFP_USER);
-	if (!newscreen)
-		return -ENOMEM;
-
 	old_rows = video_num_lines;
 	old_cols = video_num_columns;
 	old_row_size = video_size_row;
 	old_screen_size = screenbuf_size;
 
+	err = resize_screen(currcons, new_cols, new_rows);
+	if (err) 
+		return err;
+
+	newscreen = (unsigned short *) kmalloc(new_screen_size, GFP_USER);
+	if (!newscreen)
+		return -ENOMEM;
+
 	video_num_lines = new_rows;
 	video_num_columns = new_cols;
 	video_size_row = new_row_size;
 	screenbuf_size = new_screen_size;
 
-	err = resize_screen(currcons, new_cols, new_rows);
-	if (err)
-		return err;
-
 	rlth = min(old_row_size, new_row_size);
 	rrem = new_row_size - rlth;
 	old_origin = origin;