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

Re: [Linux-fbdev-devel] fbcon scrolling + initialisation oddity

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

On Mon, 2003-01-20 at 04:03, Russell King wrote:
> 1. YWRAP scrolling.
> 
> There appears to be something weird going on with fbcon scrolling in 2.5.59
> when using YWRAP.  The best example is what happens when scrolling a large
> file (say, /etc/termcap) in less.
> 
> While scrolling down in the file, the screen scrolls correctly for the
> most part.  At some point, the screen stops scrolling and the last line
> which normally displays the less prompt character ":" is replaced by
> the next line of text.  Continuing to scroll down produces no visible
> changes.
> 
> Once enough scrolling has occurred, suddenly the screen jumps and we get
> the proper text displayed.
> 
> Also, if you scroll line by line until the ":" is replaced by text as
> above, scrolling back up one line replaces the ":" and scrolling upwards
> scrolls the screen up correctly.
> 
> As an additional behaviour point, if you scroll down until the ":" just
> disappears and then some extra lines, hit 'q' to exit less, followed by
> ^L, most of the screen is cleared, except for the very top few lines.
> I haven't checked, but I suspect the number of lines left at the top of
> the screen is equal to the number of lines we're off the bottom of the
> screen.
> 

fb_pan_display() does not test for YWRAP.  Can you try this?

Tony

diff -Naur linux-2.5.59/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.59/drivers/video/fbmem.c	2003-01-20 01:10:12.000000000 +0000
+++ linux/drivers/video/fbmem.c	2003-01-20 01:14:27.000000000 +0000
@@ -724,11 +724,15 @@
 {
         int xoffset = var->xoffset;
         int yoffset = var->yoffset;
+	int ybottom = var->yoffset;
         int err;
 
+	if (!(var->vmode & FB_VMODE_YWRAP))
+		ybottom += info->var.yres;
+
         if (xoffset < 0 || yoffset < 0 || !info->fbops->fb_pan_display ||
             xoffset + info->var.xres > info->var.xres_virtual ||
-            yoffset + info->var.yres > info->var.yres_virtual)
+            ybottom > info->var.yres_virtual)
                 return -EINVAL;
 	if ((err = info->fbops->fb_pan_display(var, info)))
 		return err;

[Linux-fbdev-devel] fbcon scrolling + initialisation oddity

[Russell K. <rm...@ar...>]

1. YWRAP scrolling.

There appears to be something weird going on with fbcon scrolling in 2.5.59
when using YWRAP.  The best example is what happens when scrolling a large
file (say, /etc/termcap) in less.

While scrolling down in the file, the screen scrolls correctly for the
most part.  At some point, the screen stops scrolling and the last line
which normally displays the less prompt character ":" is replaced by
the next line of text.  Continuing to scroll down produces no visible
changes.

Once enough scrolling has occurred, suddenly the screen jumps and we get
the proper text displayed.

Also, if you scroll line by line until the ":" is replaced by text as
above, scrolling back up one line replaces the ":" and scrolling upwards
scrolls the screen up correctly.

As an additional behaviour point, if you scroll down until the ":" just
disappears and then some extra lines, hit 'q' to exit less, followed by
^L, most of the screen is cleared, except for the very top few lines.
I haven't checked, but I suspect the number of lines left at the top of
the screen is equal to the number of lines we're off the bottom of the
screen.

2. Initialisation

Machine 1: (acornfb)

	parport0: PC-style at 0x278 (0x678) [PCSPP(,...)]
	i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
	Acornfb: 2048kB VRAM, VIDC20, using 1280x1024, 63.885kHz, 59Hz
	Acornfb: Monitor: 30.000-85.000kHz, 56-76Hz, DPMS
-->	Console: switching to colour frame buffer device 160x128
	pty: 256 Unix98 ptys configured
	i2c-dev.o: Registered 'IOC/IOMD' as minor 0
	mice: PS/2 mouse device common for all mice
	input: Acorn RiscPC mouse
	input: AT Set 2 keyboard on rpckbd/serio0
	...
	SCSI device sda: drive cache: write back
	 sda: sda1 sda2
	Attached scsi removable disk sda at scsi0, channel 0, id 2, lun 0
-->	Console: switching to colour frame buffer device 160x128
	NET4: Linux TCP/IP 1.0 for NET4.0
	IP: routing cache hash table of 512 buckets, 4Kbytes

Machine 2: (sa1100fb)

	i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
	i2c-proc.o version 2.6.4 (20020719)
	i2c-dev.o: Registered 'l3-bit-sa1100-gpio' as minor 0
	dma period = 1372168 ps, clock = 206400 kHz
-->	Console: switching to colour frame buffer device 40x30
	pty: 256 Unix98 ptys configured
	SA1100 Real Time Clock driver v1.00
	RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
-->	Console: switching to colour frame buffer device 40x30
	drivers/mtd/maps/pcmciamtd.c: PCMCIA Flash memory card driver $Revision: 1.36 $


We seem to be initialising the console twice?  Certainly the position of the
text vs the logo seems to jump around with the second initialisation.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Fwd: [PATCH 2.5.59] fix for fbcon.c

[Alexander K. <ale...@gm...>]

----------  Weitergeleitete Nachricht  ----------

Subject: [PATCH 2.5.59] fix for fbcon.c
Date: Sun, 19 Jan 2003 19:36:12 +0100
From: Alexander Kern <ale...@gm...>
To: fb-...@li...

Hello,

hier is a fix needed by 1400x1050 resolution. fbcon_resize() without fis =
set
resolution to 1400x1040 and confusing LCD vertical stretching.

Regards
Alex

PS: I have retest both kernel versions, here is a result.

COMPAQ ARMADA E500, ATI (Mach64) Rage 3D Mobility P/M
15" with native 1400x1050 pixel

                        2.4.21-pre3                              2.5.59
640x400        perfect(LOGO)                        perfect
640x480        perfect(LOGO)                        perfect
800x600        perfect                                      perfect
1024x768      h. overlapping(LOGO)          h. overlapping
1152x864      h. overlapping                        h. overlapping
1280x1024    h. overlapping                        h. overlapping
1400x1050    perfect                                   perfect (with this
 fix)

LOGO by 640x4?0 means strange blue pixels as mirror of pinguin
LOGO by 1024x768 means shift to top, pinguin head is unvisible
h. overlapping means mostly stretching issue.

-------------------------------------------------------

Re: [Linux-fbdev-devel] [PATCH] rivafb sync polarity problem?

[Fredrik N. <no...@no...>]

> How bad is the sync problem?  

Well, I must say it's pretty bad. It's a digital kind of TV - so
either you'll get a stable nice looking image, or you'll get the
blue "no-signal" screen. I get the blue screen.

But there is a strange mode in the TV where I can see the RGB signal
from the computer using the sync from the RF-input. Using this, at
least it seems the frequencies are reasonably correct.

> It's possible that your horizontal timings is not divisible by 8?  
> Ie., your hsync_len is 54, but when it's written to the register, 
> it's just 48.  You might want to recalculate the numbers so you 
> use 54 or 56.

I've tried the two variants below but neither work unfortunately.

    mode "768x288"
        geometry   768 288   768 288   32
    #   timings    62500   126 80   20 2   48 2
        timings    62500   118 80   20 2   56 2
        hsync low
        vsync low
    endmode

Thanks,

	Fredrik

Re: [Linux-fbdev-devel] [PATCH] rivafb sync polarity problem?

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

On Sun, 2003-01-19 at 20:55, Fredrik Noring wrote:
> Hi,
> 
> It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
> the RGB (TV) screen fail to sync properly. (The equivalent modeline in
> XFree86 4.2 works.)
> 
>     mode "768x288"
>         geometry   768 288   768 288   32
>         timings    62500   120 80   20 2   54 2
>         hsync low
>         vsync low
>     endmode
> 

Ooops :-)  Sorry, I did not notice you were using 288 for your yres, so
62500 is just right.

How bad is the sync problem?  It's possible that your horizontal timings
is not divisible by 8?  Ie., your hsync_len is 54, but when it's written
to the register, it's just 48.  You might want to recalculate the
numbers so you use 54 or 56.

Tony

Re: [Linux-fbdev-devel] [PATCH] rivafb sync polarity problem?

[Fredrik N. <no...@no...>]

s=F6n 2003-01-19 klockan 17.25 skrev Antonino Daplas:
> The dotclock should be in picoseconds.  The above will translate to
> roughly 16MHz only.

Yep. The corresponding modeline in XFree86 4.2 is:

  Modeline "768x288" 16.0 768 848 902 1022 288 290 292 312 -hsync -vsync

It's a mode designed for regular PAL TV output (through RGB-SCART) and
it works excellent with XFree86 4.2. The corresponding modeline for NTSC
looks like this:

  Modeline "768x240" 16.0 768 848 902 1022 240 243 244 261 -hsync -vsync

Hopefully, rivafb will support interlace some day and then these
modelines will also work:

  ModeLine "768x485" 16.0 768 848 902 1022 485 491 496 525 -hsync -vsync in=
terlace
  ModeLine "768x576" 16.0 768 848 902 1022 576 580 585 625 -hsync -vsync in=
terlace

(PAL and NTSC respectively.)

For some reason, rivafb will not render any of these modes properly a.t.m.

	Fredrik

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Fredrik N. <no...@no...>]

s=F6n 2003-01-19 klockan 16.41 skrev Antonino Daplas:
> The other patch (in reply to Jak) should hopefully fix the initial=20
> screen corruption on insmod and the kobject trace message.

It did - thanks!

> Can you try running an fbdev-based application, such as X, at 8bpp, just
> to find out if the hardware is incorrectly initialized from the very
> start or if this is more fbcon-related?

I've tried two things. This:

   modprobe rivafb     <-- loads OK, no visual side effects
   modprobe fbcon      <-- garbage graphics, complete hang

And this:

   modprobe rivafb     <-- loads OK, no visual side effects
   fbset 640x480-60    <-- screen turns black, complete hang

The mode looks like this:

   mode "640x480-60"
       # D: 25.175 MHz, H: 31.469 kHz, V: 59.94 Hz
       geometry 640 480 640 480 8
       timings 39722 48 16 33 10 96 2
    endmode

I haven't found any crash reports or similar in /var/log/messages. The
system simply freezes completely.

	Fredrik

Re: [Linux-fbdev-devel] [PATCH] rivafb sync polarity problem?

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

On Sun, 2003-01-19 at 20:55, Fredrik Noring wrote:
> Hi,
> 
> It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
> the RGB (TV) screen fail to sync properly. (The equivalent modeline in
> XFree86 4.2 works.)
> 
>     mode "768x288"
>         geometry   768 288   768 288   32
>         timings    62500   120 80   20 2   54 2
                     ^^^^^ 

The dotclock should be in picoseconds.  The above will translate to
roughly 16MHz only.

picoseconds = 1/Hz * 1E12

Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

On Sun, 2003-01-19 at 19:29, Fredrik Noring wrote:
> Hi,
> 
> > To summarise:
> >  insmod rivafb causes "Badness in kobject_register" every time 
> >    ( after pci_register_driver() in rivafb_init(),see below )
> >  after insmod rivafb, I have a green screen, which can be cleared by fbset
> >   ( fbset now changes resolution of all VTs, this is different from 2.4.x )
> >  after clearing green screen using fbset, text colours are wrong
> 
> I get similar results, but I have to run and stop XFree86 4.2 before 
> "insmod rivafb". Otherwise the screen will not be cleared by fbset.
> 
> >  now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart from
> >   the left-hand-most column of screen appears at right-hand side of screen )
> 
> With 2.5.59 with and without the patch Antonino Daplas sent to the
> kernel list (17 Jan), loading fbcon only displays garbage on the screen.
> The graphics card is TNT AGP.
> 

Unfortunately, the first patch I submitted will only fix wrong colors
with user applications.  If you already have garbage with the unmodified
driver, the patch will not fix it.  The other patch (in reply to Jak)
should hopefully fix the initial screen corruption on insmod and the
kobject trace message.

Can you try running an fbdev-based application, such as X, at 8bpp, just
to find out if the hardware is incorrectly initialized from the very
start or if this is more fbcon-related?

Tony  

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

On Sun, 2003-01-19 at 04:28, Jak wrote: 
> 
> James,
> 		I still see the same problem using 2.5.59. I think this
> is the same problem as that referred to by Udo A. Steinberg
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104278873827538&w=2
> ( I get similar results as him if I compile rivafb built-in )
> 
> Is this possibly related to driver-model issues discussed in this thread ?
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104283662023857&w=2
> 
> Good news is that 2.5.59 seems quite stable as regards framebuffer.
> It no longer locks up after loading fbcon. But rmmod fbcon still
> causes instant death accompanied by increased whirring noises from inside
> box.
> 
> To summarise:
>  insmod rivafb causes "Badness in kobject_register" every time 
>    ( after pci_register_driver() in rivafb_init(),see below )
>  after insmod rivafb, I have a green screen, which can be cleared by fbset
>   ( fbset now changes resolution of all VTs, this is different from 2.4.x )
The green screen is expected because the driver partly initializes the
hardware (in riva_common_setup()).  Running fbset() will complete the
initialization, but... 

>  after clearing green screen using fbset, text colours are wrong
...unfortunately, upon exit, the driver restores only the partly
initialized state, thus the vga console text colors are wrong. 

>  now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart from
When fbcon is loaded, it goes to graphics mode, so the screen should
look okay.  

>   the left-hand-most column of screen appears at right-hand side of screen )
Try running stty to fix your display. 

>  rmmod fbcon locks up machine, no ALT-SYSRQ effective
This is wishful thinking :-), as fbcon cannot be unloaded (yet). 

James, 

Calling riva_common_setup() calls RivaGetConfig() which modifies the
hardware.  Since we only need fix->smem_len and the bandwidth from
RivaGetConfig(), I isolated them into riva_get_memlen() and
riva_get_maxdclk().  RivaGetConfig will be called from rivafb_open()
anyway.

So can you and Jak try the attached patch?  It should prevent VGA
console corruption on insmod and it should eliminate the kobject trace
messages.

Diff is against 2.5.59.

Tony

diff -Naur linux-2.5.59/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.59/drivers/video/riva/fbdev.c	2003-01-19 15:24:14.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2003-01-19 15:23:18.000000000 +0000
@@ -150,7 +150,7 @@
 static struct riva_chip_info {
 	const char *name;
 	unsigned arch_rev;
-} riva_chip_info[] __devinitdata = {
+} riva_chip_info[] __initdata = {
 	{ "RIVA-128", NV_ARCH_03 },
 	{ "RIVA-TNT", NV_ARCH_04 },
 	{ "RIVA-TNT2", NV_ARCH_04 },
@@ -193,7 +193,7 @@
 	{ "Quadro4-700-XGL", NV_ARCH_20 }
 };
 
-static struct pci_device_id rivafb_pci_tbl[] __devinitdata = {
+static struct pci_device_id rivafb_pci_tbl[] __initdata = {
 	{ PCI_VENDOR_ID_NVIDIA_SGS, PCI_DEVICE_ID_NVIDIA_SGS_RIVA128,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_RIVA_128 },
 	{ PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TNT,
@@ -1543,7 +1543,7 @@
 	.fb_sync 	= rivafb_sync,
 };
 
-static int __devinit riva_set_fbinfo(struct fb_info *info)
+static int __init riva_set_fbinfo(struct fb_info *info)
 {
 	struct riva_par *par = (struct riva_par *) info->par;
 	unsigned int cmap_len;
@@ -1689,8 +1689,8 @@
  *
  * ------------------------------------------------------------------------- */
 
-static int __devinit rivafb_probe(struct pci_dev *pd,
-				     const struct pci_device_id *ent)
+static int __init rivafb_probe(struct pci_dev *pd,
+			       const struct pci_device_id *ent)
 {
 	struct riva_chip_info *rci = &riva_chip_info[ent->driver_data];
 	struct riva_par *default_par;
@@ -1788,8 +1788,8 @@
 		default_par->riva.PCRTC = default_par->riva.PCRTC0 = default_par->riva.PGRAPH;
 	}
 
-	rivafb_fix.smem_len = default_par->riva.RamAmountKBytes * 1024;
-	default_par->dclk_max = default_par->riva.MaxVClockFreqKHz * 1000;
+	rivafb_fix.smem_len = riva_get_memlen(default_par) * 1024;
+	default_par->dclk_max = riva_get_maxdclk(default_par) * 1000;
 
 	if (!request_mem_region(rivafb_fix.smem_start,
 				rivafb_fix.smem_len, "rivafb")) {
@@ -1819,12 +1819,6 @@
 	}
 #endif /* CONFIG_MTRR */
 
-	/* unlock io */
-	CRTCout(default_par, 0x11, 0xFF);/* vgaHWunlock() + riva unlock (0x7F) */
-	default_par->riva.LockUnlock(&default_par->riva, 0);
-
-	riva_save_state(default_par, &default_par->initial_state);
-
 	if (riva_set_fbinfo(info) < 0) {
 		printk(KERN_ERR PFX "error setting initial video mode\n");
 		goto err_out_load_state;
@@ -1869,7 +1863,7 @@
 	return -ENODEV;
 }
 
-static void __devexit rivafb_remove(struct pci_dev *pd)
+static void __exit rivafb_remove(struct pci_dev *pd)
 {
 	struct fb_info *info = pci_get_drvdata(pd);
 	struct riva_par *par = (struct riva_par *) info->par;
@@ -1877,8 +1871,6 @@
 	if (!info)
 		return;
 
-	riva_load_state(par, &par->initial_state);
-
 	unregister_framebuffer(info);
 
 #ifdef CONFIG_MTRR
@@ -1948,7 +1940,7 @@
 	name:		"rivafb",
 	id_table:	rivafb_pci_tbl,
 	probe:		rivafb_probe,
-	remove:		__devexit_p(rivafb_remove),
+	remove:		__exit_p(rivafb_remove),
 };
 

@@ -1961,12 +1953,7 @@
 
 int __init rivafb_init(void)
 {
-	int err;
-	err = pci_module_init(&rivafb_driver);
-	if (err)
-		return err;
-	pci_register_driver(&rivafb_driver);
-	return 0;
+	return pci_module_init(&rivafb_driver);
 }
 

diff -Naur linux-2.5.59/drivers/video/riva/nv_driver.c linux/drivers/video/riva/nv_driver.c
--- linux-2.5.59/drivers/video/riva/nv_driver.c	2003-01-19 15:24:14.000000000 +0000
+++ linux/drivers/video/riva/nv_driver.c	2003-01-19 15:23:18.000000000 +0000
@@ -35,6 +35,7 @@
 5 20:47:06 mvojkovi Exp $ */
 
 #include <linux/delay.h>
+#include <linux/pci.h>
 #include <linux/pci_ids.h>
 #include "nv_type.h"
 #include "rivafb.h"
@@ -133,6 +134,159 @@
 	riva_override_CRTC(par);
 }
 
+unsigned long riva_get_memlen(struct riva_par *par)
+{
+	RIVA_HW_INST *chip = &par->riva;
+	unsigned long memlen = 0;
+	unsigned int chipset = par->Chipset;
+	struct pci_dev* dev;
+	int amt;
+
+	switch (chip->Architecture) {
+	case NV_ARCH_03:
+		if (chip->PFB[0x00000000/4] & 0x00000020) {
+			if (((chip->PMC[0x00000000/4] & 0xF0) == 0x20)
+			    && ((chip->PMC[0x00000000/4] & 0x0F) >= 0x02)) {
+				/*
+				 * SDRAM 128 ZX.
+				 */
+				switch (chip->PFB[0x00000000/4] & 0x03) {
+				case 2:
+					memlen = 1024 * 4;
+					break;
+				case 1:
+					memlen = 1024 * 2;
+					break;
+				default:
+					memlen = 1024 * 8;
+					break;
+				}
+			} else {
+				memlen = 1024 * 8;
+			}            
+		} else 	{
+			/*
+			 * SGRAM 128.
+			 */
+			switch (chip->PFB[0x00000000/4] & 0x00000003) {
+			case 0:
+				memlen = 1024 * 8;
+				break;
+			case 2:
+				memlen = 1024 * 4;
+				break;
+			default:
+				memlen = 1024 * 2;
+				break;
+			}
+		}        
+		break;
+	case NV_ARCH_04:
+		if (chip->PFB[0x00000000/4] & 0x00000100) {
+			memlen = ((chip->PFB[0x00000000/4] >> 12) & 0x0F) * 
+				1024 * 2 + 1024 * 2;
+		} else {
+			switch (chip->PFB[0x00000000/4] & 0x00000003) {
+			case 0:
+				memlen = 1024 * 32;
+				break;
+			case 1:
+				memlen = 1024 * 4;
+				break;
+			case 2:
+				memlen = 1024 * 8;
+				break;
+			case 3:
+			default:
+				memlen = 1024 * 16;
+				break;
+			}
+		}
+		break;
+	case NV_ARCH_10:
+	case NV_ARCH_20:
+		if(chipset == NV_CHIP_IGEFORCE2) {
+
+			dev = pci_find_slot(0, 1);
+			pci_read_config_dword(dev, 0x7C, &amt);
+			memlen = (((amt >> 6) & 31) + 1) * 1024;
+		} else if (chipset == NV_CHIP_0x01F0) {
+			dev = pci_find_slot(0, 1);
+			pci_read_config_dword(dev, 0x84, &amt);
+			memlen = (((amt >> 4) & 127) + 1) * 1024;
+		} else {
+			switch ((chip->PFB[0x0000020C/4] >> 20) & 0x000000FF){
+			case 0x02:
+				memlen = 1024 * 2;
+				break;
+			case 0x04:
+				memlen = 1024 * 4;
+				break;
+			case 0x08:
+				memlen = 1024 * 8;
+				break;
+			case 0x10:
+				memlen = 1024 * 16;
+				break;
+			case 0x20:
+				memlen = 1024 * 32;
+				break;
+			case 0x40:
+				memlen = 1024 * 64;
+				break;
+			case 0x80:
+				memlen = 1024 * 128;
+				break;
+			default:
+				memlen = 1024 * 16;
+				break;
+			}
+		}
+		break;
+	}
+	return memlen;
+}
+
+unsigned long riva_get_maxdclk(struct riva_par *par)
+{
+	RIVA_HW_INST *chip = &par->riva;
+	unsigned long dclk = 0;
+
+	switch (chip->Architecture) {
+	case NV_ARCH_03:
+		if (chip->PFB[0x00000000/4] & 0x00000020) {
+			if (((chip->PMC[0x00000000/4] & 0xF0) == 0x20)
+			    && ((chip->PMC[0x00000000/4] & 0x0F) >= 0x02)) {   
+				/*
+				 * SDRAM 128 ZX.
+				 */
+				dclk = 800000;
+			} else {
+				dclk = 1000000;
+			}            
+		} else {
+			/*
+			 * SGRAM 128.
+			 */
+			dclk = 1000000;
+		} 
+		break;
+	case NV_ARCH_04:
+	case NV_ARCH_10:
+	case NV_ARCH_20:
+		switch ((chip->PFB[0x00000000/4] >> 3) & 0x00000003) {
+		case 3:
+			dclk = 800000;
+			break;
+		default:
+			dclk = 1000000;
+			break;
+		}
+		break;
+	}
+	return dclk;
+}
+
 void
 riva_common_setup(struct riva_par *par)
 {
diff -Naur linux-2.5.59/drivers/video/riva/rivafb.h linux/drivers/video/riva/rivafb.h
--- linux-2.5.59/drivers/video/riva/rivafb.h	2003-01-19 15:24:17.000000000 +0000
+++ linux/drivers/video/riva/rivafb.h	2003-01-19 15:23:20.000000000 +0000
@@ -55,5 +55,7 @@
 };
 
 void riva_common_setup(struct riva_par *);
+unsigned long riva_get_memlen(struct riva_par *);
+unsigned long riva_get_maxdclk(struct riva_par *);
 
 #endif /* __RIVAFB_H */

[Linux-fbdev-devel] [PATCH] rivafb sync polarity problem?

[Fredrik N. <no...@no...>]

Hi,

It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
the RGB (TV) screen fail to sync properly. (The equivalent modeline in
XFree86 4.2 works.)

    mode "768x288"
        geometry   768 288   768 288   32
        timings    62500   120 80   20 2   54 2
        hsync low
        vsync low
    endmode

I suspect it may have something to do with the sync polarity, as it
does not seem to be implemented fully in the rivafb driver? (Then again,
it seems the polarity always is forced low by the driver, I'm not sure.)

Looking at http://web.inter.nl.net/hcc/S.Weijgers/FreeVGA/vga/extreg.htm
and reading XFree86 source code indicate it should be fairly simple to
solve this, given that the correct bits are set/cleared of course. :)

The patch below tries to set the proper polarity. The mode still doesn't
work though, since misc_output already is 0xEB by default. I don't know
if the patch is wrong or which additional problems the rivafb driver
might have with the mode.

Any ideas?

Thanks

	Fredrik

--- linux-2.4.21-pre2.old/drivers/video/riva/fbdev.c	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre2.new/drivers/video/riva/fbdev.c	2003-01-19 13:21:46.000000000 +0100
@@ -920,6 +920,15 @@
 	newmode.ext.width = width;
 	newmode.ext.height = height;
 
+	if(video_mode->sync & FB_SYNC_HOR_HIGH_ACT)
+		newmode.misc_output &= ~0x40;
+	else
+		newmode.misc_output |= 0x40;
+	if(video_mode->sync & FB_SYNC_VERT_HIGH_ACT)
+		newmode.misc_output &= ~0x80;
+	else
+		newmode.misc_output |= 0x80;
+	
 	rinfo->riva.CalcStateExt(&rinfo->riva, &newmode.ext, bpp, width,
 				  hDisplaySize, hDisplay, hStart, hEnd,
 				  hTotal, height, vDisplay, vStart, vEnd,

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Fredrik N. <no...@no...>]

Hi,

> To summarise:
>  insmod rivafb causes "Badness in kobject_register" every time 
>    ( after pci_register_driver() in rivafb_init(),see below )
>  after insmod rivafb, I have a green screen, which can be cleared by fbset
>   ( fbset now changes resolution of all VTs, this is different from 2.4.x )
>  after clearing green screen using fbset, text colours are wrong

I get similar results, but I have to run and stop XFree86 4.2 before 
"insmod rivafb". Otherwise the screen will not be cleared by fbset.

>  now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart from
>   the left-hand-most column of screen appears at right-hand side of screen )

With 2.5.59 with and without the patch Antonino Daplas sent to the
kernel list (17 Jan), loading fbcon only displays garbage on the screen.
The graphics card is TNT AGP.

The rivafb module works pretty well in Linux 2.4.21-pre2, except that
certain modes involving sync polarity and interlace don't work (these
modes work fine with XFree86 4.2). I was hoping that these would work
with rivafb in 2.5.59. Any thoughts?

	Fredrik

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

James,
=09=09I still see the same problem using 2.5.59. I think this
is the same problem as that referred to by Udo A. Steinberg
http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D104278873827538&w=3D2
( I get similar results as him if I compile rivafb built-in )

Is this possibly related to driver-model issues discussed in this thread =
?
http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D104283662023857&w=3D2

Good news is that 2.5.59 seems quite stable as regards framebuffer.
It no longer locks up after loading fbcon. But rmmod fbcon still
causes instant death accompanied by increased whirring noises from inside
box.

To summarise:
 insmod rivafb causes "Badness in kobject_register" every time=20
   ( after pci_register_driver() in rivafb_init(),see below )
 after insmod rivafb, I have a green screen, which can be cleared by fbse=
t
  ( fbset now changes resolution of all VTs, this is different from 2.4.x=
 )
 after clearing green screen using fbset, text colours are wrong
 now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart fr=
om
  the left-hand-most column of screen appears at right-hand side of scree=
n )
 rmmod fbcon locks up machine, no ALT-SYSRQ effective

Jan 18 14:44:10 TBird kernel: About to pci_module_init() in rivafb_init()
Jan 18 14:44:10 TBird kernel: Entering rivafb_probe()
Jan 18 14:44:10 TBird kernel: rivafb: nVidia device/chipset 10DE002C
Jan 18 14:44:10 TBird kernel: rivafb: RIVA MTRR set to ON
Jan 18 14:44:10 TBird kernel: About to pci_set_drvdata() in rivafb_probe(=
)
Jan 18 14:44:10 TBird kernel: rivafb: PCI nVidia NV4 framebuffer ver 0.9.=
5b (nVidiaRIVA-VTNT2, 16MB @ 0xD0000000)
Jan 18 14:44:10 TBird kernel: Return OK from rivafb_probe()
Jan 18 14:44:10 TBird kernel: About to pci_register_driver() in rivafb_in=
it()
Jan 18 14:44:10 TBird kernel: Badness in kobject_register at lib/kobject.=
c:152
Jan 18 14:44:10 TBird kernel: Call Trace:
Jan 18 14:44:10 TBird kernel:  [<d08d17b4>] rivafb_driver+0x54/0xfffe0918=
 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<c01d1436>] kobject_register+0x56/0x60
Jan 18 14:44:10 TBird kernel:  [<d08d17a4>] rivafb_driver+0x44/0xfffe0918=
 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<c0202707>] bus_add_driver+0x57/0xf0
Jan 18 14:44:10 TBird kernel:  [<d08d17a4>] rivafb_driver+0x44/0xfffe0918=
 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<c0202b91>] driver_register+0x31/0x40
Jan 18 14:44:10 TBird kernel:  [<d08d1788>] rivafb_driver+0x28/0xfffe0918=
 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<c01d5ae9>] pci_register_driver+0x49/0x60
Jan 18 14:44:10 TBird kernel:  [<d08d1788>] rivafb_driver+0x28/0xfffe0918=
 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<d08b204a>] +0x4a/0x68 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<d08d1760>] rivafb_driver+0x0/0xfffe0918 =
[rivafb]
Jan 18 14:44:10 TBird kernel:  [<d08d3100>] +0x0/0xfffdef78 [rivafb]
Jan 18 14:44:10 TBird kernel:  [<c0133e07>] sys_init_module+0x117/0x1c0
Jan 18 14:44:10 TBird kernel:  [<c010a393>] syscall_call+0x7/0xb

=09=09=09=09Thanks,
=09=09=09=09=09=09Jak.

On Wednesday 15 January 2003 00:43, James Simmons wrote:
> Can you try the latest pacth at
>
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Re: [Linux-fbdev-devel] [PATCH] 2.5.59 for ATI Mach64(port from Daniel code for 2.5.59)

[Alexander K. <ale...@gm...>]

Am Freitag, 17. Januar 2003 22:27 schrieb Alexander Kern:
> Hi, tested with ATI RAGE 3D MOBILITY M1 (P/M). 1400x1050 works, i assum=
e
> all others must work too.

Arrrrh, full speed back.

Please don't beat me, it works only with 1400x1050 on exetern CRT, image=20
timing for LCD is incorrect

[Linux-fbdev-devel] [PATCH]: i810fb updates

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

Hi James,

Attached is a diff against linux-2.5.59 with the following i810fb
updates:

1.  Uses fb_get_mode() and fb_validate_mode() to calculate/check display
timings.  

2. Fixed bug in i810fb_imageblit() and i810fb_cursor() when bitmap is not divisible
by 8.

3.  Removed unnecessary calls to wait_for_engine_idle() since fbcon
already guarantees that fb_sync() will be called whenever the
framebuffer memory is to be accessed.


The updates will remove around 250 lines of code :-)

Tony

[Linux-fbdev-devel] [PATCH] 2.4.21-pre3 for ATI Mach64(99% Work from Daniel Mantione)

[Alexander K. <ale...@gm...>]

Hi, patch to 2.4.21-pre3, tested with ATI RAGE 3D MOBILITY M1 (P/M). Alls=
=20
resolutions work.

[Linux-fbdev-devel] [PATCH] 2.5.59 for ATI Mach64(port from Daniel code for 2.5.59)

[Alexander K. <ale...@gm...>]

Hi, tested with ATI RAGE 3D MOBILITY M1 (P/M). 1400x1050 works, i assume =
all=20
others must work too.=20

[Linux-fbdev-devel] [PATCH][FBDEV]: rivafb fixes

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

Hi James,

The rivafb in linux-2.5.59 is now working on my hardware :-).  

I've attached a diff for linux-2.5.59 that reimplements
rivafb_imageblit() and rivafb_cursor().  The main fix is in
reverse_order() which only reverses the first 2 bytes instead of 4.


I've also attached another diff which should be applied on
top of the first patch.  It's up to you if you want to accept this or
not.  The diff fixes riva_get_cmaplen and includes initialization of 
the color registers.  Since rivafb exports its visual as DIRECTCOLOR,
the color registers must also be set accordingly.  Otherwise, user
applications running on top of rivafb will have wrong colors.  Try it
with XFBDev, and if the colors are wrong, try the attached patch.

I believe this is also a problem with the 2.4 version of rivafb.

Tony

PATCH 1 (rivafb_imageblit and rivafb_cursor)

diff -Naur linux-2.5.59/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.59/drivers/video/riva/fbdev.c	2003-01-17 13:39:08.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2003-01-17 13:50:14.000000000 +0000
@@ -458,7 +458,7 @@
 		m = *((u32 *)mask)++;
 		for (j = 0; j < w/2; j++) {
 			tmp = 0;
-#if defined (__BIG_ENDIAN__)
+#if defined (__BIG_ENDIAN)
 			if (m & (1 << 31))
 				tmp = (b & (1 << 31)) ? fg << 16 : bg << 16;
 			b <<= 1;
@@ -1156,13 +1156,13 @@
 	case 16:
 		if (info->var.green.length == 5) {
 			/* 0rrrrrgg gggbbbbb */
-			((u16 *)(info->pseudo_palette))[regno] =
+			((u32 *)(info->pseudo_palette))[regno] =
 					((red & 0xf800) >> 1) |
 					((green & 0xf800) >> 6) |
 					((blue & 0xf800) >> 11);
 		} else {
 			/* rrrrrggg gggbbbbb */
-			((u16 *)(info->pseudo_palette))[regno] =
+			((u32 *)(info->pseudo_palette))[regno] =
 					((red & 0xf800) >> 0) |
 					((green & 0xf800) >> 5) |
 					((blue & 0xf800) >> 11);
@@ -1288,6 +1288,8 @@
 {
 	u8 *a = (u8 *)l;
 	*a = byte_rev[*a], a++;
+	*a = byte_rev[*a], a++;
+	*a = byte_rev[*a], a++;
 	*a = byte_rev[*a];
 }
 
@@ -1318,10 +1320,10 @@
 static void rivafb_imageblit(struct fb_info *info, struct fb_image *image)
 {
 	struct riva_par *par = (struct riva_par *) info->par;
-	u32 fgx = 0, bgx = 0, width, mod;
-	u8 *cdat = image->data, *dat;
+	u32 fgx = 0, bgx = 0, width, mod, tmp;
+	u8 *cdat = image->data;
 	volatile u32 *d;
-	int i, j, size;
+	int i, j, k, size;
 
 	if (image->depth != 1) {
 		wait_for_idle(par);
@@ -1330,84 +1332,80 @@
 	}
 
 	width = (image->width + 7)/8;
-
-	size = image->width * image->height;
-	dat = cdat;
-/*
-	for (i = 0; i < size; i++) {
-		*dat = byte_rev[*dat];
-		dat++;
-	}
-*/
 	switch (info->var.bits_per_pixel) {
 	case 8:
 		fgx = image->fg_color;
 		bgx = image->bg_color;
 		break;
 	case 16:
-		fgx |= ((u16 *) (info->pseudo_palette))[image->fg_color];
-		bgx |= ((u16 *) (info->pseudo_palette))[image->bg_color];
+		fgx = ((u32 *) (info->pseudo_palette))[image->fg_color];
+		bgx = ((u32 *) (info->pseudo_palette))[image->bg_color];
 		if (info->var.green.length == 6)
 			convert_bgcolor_16(&bgx);	
 		break;
 	case 32:
-		fgx |= ((u32 *) (info->pseudo_palette))[image->fg_color];
-		bgx |= ((u32 *) (info->pseudo_palette))[image->bg_color];
+		fgx = ((u32 *) (info->pseudo_palette))[image->fg_color];
+		bgx = ((u32 *) (info->pseudo_palette))[image->bg_color];
 		break;
 	}
 
 	RIVA_FIFO_FREE(par->riva, Bitmap, 7);
-	par->riva.Bitmap->ClipE.TopLeft     = (image->dy << 16) | (image->dx & 0xFFFF);
-	par->riva.Bitmap->ClipE.BottomRight = (((image->dy + image->height) << 16) |
-                                       		((image->dx + image->width) & 0xffff));
+	par->riva.Bitmap->ClipE.TopLeft     = 
+		(image->dy << 16) | (image->dx & 0xFFFF);
+	par->riva.Bitmap->ClipE.BottomRight = 
+		(((image->dy + image->height) << 16) |
+		 ((image->dx + image->width) & 0xffff));
 	par->riva.Bitmap->Color0E           = bgx;
 	par->riva.Bitmap->Color1E           = fgx;
-	par->riva.Bitmap->WidthHeightInE    = (image->height << 16) | ((image->width + 31) & ~31);
-	par->riva.Bitmap->WidthHeightOutE   = (image->height << 16) | ((image->width + 31) & ~31);
-	par->riva.Bitmap->PointE            = (image->dy << 16) | (image->dx & 0xFFFF);
+	par->riva.Bitmap->WidthHeightInE    = 
+		(image->height << 16) | ((image->width + 31) & ~31);
+	par->riva.Bitmap->WidthHeightOutE   = 
+		(image->height << 16) | ((image->width + 31) & ~31);
+	par->riva.Bitmap->PointE            = 
+		(image->dy << 16) | (image->dx & 0xFFFF);
 
 	d = &par->riva.Bitmap->MonochromeData01E;
 
 	mod = width % 4;
 
 	if (width >= 4) {
-		while (image->height--) {
+		k = image->height;
+		while (k--) {
 			size = width / 4;
 			while (size >= 16) {
 				RIVA_FIFO_FREE(par->riva, Bitmap, 16);
-				for (i = 0; i < 16; i++)
-					d[i] = *((u32 *)cdat)++;
+				for (i = 0; i < 16; i++) {
+					tmp = *((u32 *)cdat)++;
+					reverse_order(&tmp);
+					d[i] = tmp;
+				}
 				size -= 16;
 			}
 
 			if (size) {
 				RIVA_FIFO_FREE(par->riva, Bitmap, size);
-				for (i = 0; i < size; i++)
-					d[i] = *((u32 *) cdat)++;
+				for (i = 0; i < size; i++) {
+					tmp = *((u32 *) cdat)++;
+					reverse_order(&tmp);
+					d[i] = tmp;
+				}
 			}
 
 			if (mod) {
-				u32 tmp;
 				RIVA_FIFO_FREE(par->riva, Bitmap, 1);
 				for (i = 0; i < mod; i++)
 					((u8 *)&tmp)[i] = *cdat++;
+				reverse_order(&tmp);
 				d[i] = tmp;
 			}
 		}
 	} else {
-		u32 tmp;
-
 		for (i = image->height; i > 0; i-=16) {
-			if (i >= 16)
-				size = 16;
-			else
-				size = i;
+			size = (i >= 16) ? 16 : i;
 			RIVA_FIFO_FREE(par->riva, Bitmap, size);
 			for (j = 0; j < size; j++) {
-				if (image->width <= 8)
-					tmp = *cdat++;
-				else
-					tmp = *((u16 *)cdat)++;
+				for (k = 0; k < width; k++) 
+					((u8 *) &tmp)[k] = *cdat++;
 				reverse_order(&tmp);
 				d[j] = tmp;
 			}
@@ -1470,14 +1468,19 @@
 	if (flags & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP | FB_CUR_SETDEST)) {
 		int bg_idx = cursor->image.bg_color;
 		int fg_idx = cursor->image.fg_color;
+		int width = (cursor->image.width+7)/8;
+		u8 *dat = (u8 *) cursor->image.data;
+		u8 *dst = (u8 *) cursor->dest;
+		u8 *msk = (u8 *) cursor->mask;
 
 		switch (cursor->rop) {
 		case ROP_XOR:
 			for (i = 0; i < cursor->image.height; i++) {
-				for (j = 0; j < (cursor->image.width + 7)/8; j++) {
+				for (j = 0; j < width; j++) {
 					d_idx = i * MAX_CURS/8  + j;
-					data[d_idx] =  byte_rev[((u8 *)cursor->image.data)[s_idx] ^ ((u8 *)cursor->dest)[s_idx]]; 	
-					mask[d_idx] = byte_rev[((u8 *)cursor->mask)[s_idx]];
+					data[d_idx] =  byte_rev[dat[s_idx] ^ 
+								dst[s_idx]];
+					mask[d_idx] = byte_rev[msk[s_idx]];
 					s_idx++;
 				}
 			}
@@ -1485,24 +1488,24 @@
 		case ROP_COPY:
 		default:
 			for (i = 0; i < cursor->image.height; i++) {
-				for (j = 0; j < (cursor->image.width + 7)/8; j++) {
+				for (j = 0; j < width; j++) {
 					d_idx = i * MAX_CURS/8 + j;
-					data[d_idx] = byte_rev[((u8 *)cursor->image.data)[s_idx]];
-					mask[d_idx] = byte_rev[((u8 *)cursor->mask)[s_idx]];
+					data[d_idx] = byte_rev[dat[s_idx]];
+					mask[d_idx] = byte_rev[msk[s_idx]];
 					s_idx++;
 				}
 			}
 			break;
 		}
-/*
-		bg = ((par->cmap[bg_idx].red & 0xf8) << 7) |
-		     ((par->cmap[bg_idx].green & 0xf8) << 2) |
-		     ((par->cmap[bg_idx].blue & 0xf8) >> 3) | 1 << 15;
-
-		fg = ((par->cmap[fg_idx].red & 0xf8) << 7) |
-		     ((par->cmap[fg_idx].green & 0xf8) << 2) |
-		     ((par->cmap[fg_idx].blue & 0xf8) >> 3) | 1 << 15;
-*/
+
+		bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
+		     ((info->cmap.green[bg_idx] & 0xf8) << 2) |
+		     ((info->cmap.blue[bg_idx] & 0xf8) >> 3) | 1 << 15;
+
+		fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
+		     ((info->cmap.green[fg_idx] & 0xf8) << 2) |
+		     ((info->cmap.blue[fg_idx] & 0xf8) >> 3) | 1 << 15;
+
 		par->riva.LockUnlock(&par->riva, 0);
 		rivafb_load_cursor_image(data, mask, par, cursor->image.width,
 		cursor->image.height, bg, fg);
@@ -1538,8 +1541,8 @@
 	.fb_blank 	= rivafb_blank,
 	.fb_fillrect 	= rivafb_fillrect,
 	.fb_copyarea 	= rivafb_copyarea,
-	.fb_imageblit 	= cfb_imageblit,
-	.fb_cursor	= soft_cursor,	
+	.fb_imageblit 	= rivafb_imageblit,
+	.fb_cursor	= rivafb_cursor,	
 	.fb_sync 	= rivafb_sync,
 };
 

PATCH 2 (color register fix)

diff -Naur linux-2.5.59/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.59/drivers/video/riva/fbdev.c	2003-01-17 16:21:54.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2003-01-17 18:04:41.000000000 +0000
@@ -310,9 +310,9 @@
 	xres_virtual:	640,
 	yres_virtual:	480,
 	bits_per_pixel:	8,
-	red:		{0, 6, 0},
-	green:		{0, 6, 0},
-	blue:		{0, 6, 0},
+	red:		{0, 8, 0},
+	green:		{0, 8, 0},
+	blue:		{0, 8, 0},
 	transp:		{0, 0, 0},
 	activate:	FB_ACTIVATE_NOW,
 	height:		-1,
@@ -515,6 +515,31 @@
 }
 
 /**
+ * riva_rclut - read fromCLUT register
+ * @chip: pointer to RIVA_HW_INST object
+ * @regnum: register number
+ * @red: red component
+ * @green: green component
+ * @blue: blue component
+ *
+ * DESCRIPTION:
+ * Reads red, green, and blue from color register @regnum.
+ *
+ * CALLED FROM:
+ * rivafb_setcolreg()
+ */
+static void riva_rclut(RIVA_HW_INST *chip,
+		       unsigned char regnum, unsigned char *red,
+		       unsigned char *green, unsigned char *blue)
+{
+	
+	VGA_WR08(chip->PDIO, 0x3c8, regnum);
+	*red = VGA_RD08(chip->PDIO, 0x3c9);
+	*green = VGA_RD08(chip->PDIO, 0x3c9);
+	*blue = VGA_RD08(chip->PDIO, 0x3c9);
+}
+
+/**
  * riva_save_state - saves current chip state
  * @par: pointer to riva_par object containing info for current riva board
  * @regs: pointer to riva_regs object
@@ -870,21 +895,18 @@
  */
 static int riva_get_cmap_len(const struct fb_var_screeninfo *var)
 {
-	int rc = 16;		/* reasonable default */
+	int rc = 256;		/* reasonable default */
 
-	switch (var->bits_per_pixel) {
+	switch (var->green.length) {
 	case 8:
-		rc = 256;	/* pseudocolor... 256 entries HW palette */
+		rc = 256;	/* 256 entries (2^8), 8 bpp and RGB8888 */
 		break;
-	case 15:
-		rc = 15;	/* fix for 15 bpp depths on Riva 128 based cards */
+	case 5:
+		rc = 32;	/* 32 entries (2^5), 16 bpp, RGB555 */
 		break;
-	case 16:
-		rc = 16;	/* directcolor... 16 entries SW palette */
-		break;		/* Mystique: truecolor, 16 entries SW palette, HW palette hardwired into 1:1 mapping */
-	case 32:
-		rc = 16;	/* directcolor... 16 entries SW palette */
-		break;		/* Mystique: truecolor, 16 entries SW palette, HW palette hardwired into 1:1 mapping */
+	case 6:
+		rc = 64;	/* 64 entries (2^6), 16 bpp, RGB565 */
+		break;		
 	default:
 		/* should not occur */
 		break;
@@ -1138,6 +1160,7 @@
 {
 	struct riva_par *par = (struct riva_par *)info->par;
 	RIVA_HW_INST *chip = &par->riva;
+	int i;
 
 	if (regno >= riva_get_cmap_len(&info->var))
 		return -EINVAL;
@@ -1155,23 +1178,46 @@
 		break;
 	case 16:
 		if (info->var.green.length == 5) {
-			/* 0rrrrrgg gggbbbbb */
-			((u32 *)(info->pseudo_palette))[regno] =
+			if (regno < 16) {
+				/* 0rrrrrgg gggbbbbb */
+				((u32 *)info->pseudo_palette)[regno] =
 					((red & 0xf800) >> 1) |
 					((green & 0xf800) >> 6) |
 					((blue & 0xf800) >> 11);
+			}
+			for (i = 0; i < 8; i++) 
+				riva_wclut(chip, regno*8+i, red >> 8,
+					   green >> 8, blue >> 8);
 		} else {
-			/* rrrrrggg gggbbbbb */
-			((u32 *)(info->pseudo_palette))[regno] =
+			u8 r, g, b;
+
+			if (regno < 16) {
+				/* rrrrrggg gggbbbbb */
+				((u32 *)info->pseudo_palette)[regno] =
 					((red & 0xf800) >> 0) |
 					((green & 0xf800) >> 5) |
 					((blue & 0xf800) >> 11);
+			}
+			if (regno < 32) {
+				for (i = 0; i < 8; i++) {
+					riva_wclut(chip, regno*8+i, red >> 8, 
+						   green >> 8, blue >> 8);
+				}
+			}
+			for (i = 0; i < 4; i++) {
+				riva_rclut(chip, regno*2+i, &r, &g, &b);
+				riva_wclut(chip, regno*4+i, r, green >> 8, b);
+			}
 		}
 		break;
 	case 32:
-		((u32 *) (info->pseudo_palette))[regno] =
-		    		((red & 0xff00) << 8) |
-		    		((green & 0xff00)) | ((blue & 0xff00) >> 8);
+		if (regno < 16) {
+			((u32 *)info->pseudo_palette)[regno] =
+				((red & 0xff00) << 8) |
+				((green & 0xff00)) | ((blue & 0xff00) >> 8);
+			
+		}
+		riva_wclut(chip, regno, red >> 8, green >> 8, blue >> 8);
 		break;
 	default:
 		/* do nothing */
@@ -1200,7 +1246,7 @@
 	if (info->var.bits_per_pixel == 8)
 		color = rect->color;
 	else
-		color = ((u32 *)(info->pseudo_palette))[rect->color];
+		color = ((u32 *)info->pseudo_palette)[rect->color];
 
 	switch (rect->rop) {
 	case ROP_XOR:
@@ -1338,14 +1384,14 @@
 		bgx = image->bg_color;
 		break;
 	case 16:
-		fgx = ((u32 *) (info->pseudo_palette))[image->fg_color];
-		bgx = ((u32 *) (info->pseudo_palette))[image->bg_color];
+		fgx = ((u32 *)info->pseudo_palette)[image->fg_color];
+		bgx = ((u32 *)info->pseudo_palette)[image->bg_color];
 		if (info->var.green.length == 6)
 			convert_bgcolor_16(&bgx);	
 		break;
 	case 32:
-		fgx = ((u32 *) (info->pseudo_palette))[image->fg_color];
-		bgx = ((u32 *) (info->pseudo_palette))[image->bg_color];
+		fgx = ((u32 *)info->pseudo_palette)[image->fg_color];
+		bgx = ((u32 *)info->pseudo_palette)[image->bg_color];
 		break;
 	}
 
@@ -1557,7 +1603,7 @@
 	info->fix = rivafb_fix;
 	info->fbops = &riva_fb_ops;
 	info->pseudo_palette = pseudo_palette;
-	
+
 #ifndef MODULE
 	if (mode_option)
 		fb_find_mode(&info->var, info, mode_option,

Re: [Linux-fbdev-devel] [PATCH]: Various fbdev fixes:

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

Applied. Its in the fbdev BK tree.

[Linux-fbdev-devel] Re: New logo code

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

On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> 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?

I put a new version at

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

Changes:
  - Merge with 2.5.59
  - New logo (CLUT224 only) for PA-RISC
  - Let hgafb and newport_con include logo sources directly, since they need
    access to the logos in non-init code

All comments are welcomed! 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] [PATCH]: Various fbdev fixes:

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

On Thu, 2003-01-16 at 11:49, Antonino Daplas wrote:
> Hi James,
> 
> It seems that the 32/64-bit patch for fast_imageblit() and the
> "non-divisible by 8 width" fix for slow_imageblit() did not completely
> take.  So here's an updated patch against linux-2.5.58 + your latest
> fbdev.diff:
> 
> a.  Fix for fast_imageblit() being unclean on 64-bit and higher
> machines:  With the change, the 32-bit tables will be accessed 2 (or
> more) times  on >= 64-bit machines before doing a single FB_WRITEL. 
> Because the extra tests and bit packing impose a performance penalty for
> 32-bit machines, 32-bit machines undergo a different, faster, and
> simpler path.
> 
> c.  Fix for slow_imageblit() being unclean for bitmaps with widths not
> divisible by 8.
> 
> d.  Fix for fbcon_resize().  Update display.vrows after fb_set_var(). 
> This should fix console problems when fb_var_screeninfo.yres_virtual is
> changed and y-panning is enabled. Only activated when fbcon_switch() is
> called.
> 
> e.  Trivial:  info->fbops->fb_sync() may not be necessary in
> accel_putcs().
> 

James,

This is a resend of the same patch against linux-2.5.59.  

Tony

diff -Naur linux-2.5.59/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.59/drivers/video/cfbimgblt.c	2003-01-17 07:40:33.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-17 07:39:54.000000000 +0000
@@ -73,26 +73,36 @@
 	0x00000000, 0xffffffff
 };
 
-#if BITS_PER_LONG == 32
-#define FB_WRITEL fb_writel
-#define FB_READL  fb_readl
-#else
-#define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq
-#endif 
-
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - 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 NEXT_POS(pos, bpp)     ((pos) += (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
 #endif
 
+#if BITS_PER_LONG == 32
+#define FB_WRITEL        fb_writel
+#define FB_READL         fb_readl
+#define INIT_FASTPATH    {}
+#define FASTPATH         fb_writel((end_mask & eorx)^bgx, dst++)
+#else
+#define FB_WRITEL        fb_writeq
+#define FB_READL         fb_readq
+#define INIT_FASTPATH    unsigned val = 0, bpl = 0 
+#define FASTPATH {                                     \
+	val |= SHIFT_HIGH((end_mask & eorx)^bgx, bpl); \
+	bpl += 32;                                     \
+	bpl &= BITS_PER_LONG - 1;                      \
+	if (!bpl) {                                    \
+		FB_WRITEL(val, dst++);                 \
+		val = 0;                               \
+	}                                              \
+}                                                      
+#endif 
+
 static inline void color_imageblit(struct fb_image *image, struct fb_info *p, 
 				   u8 *dst1, unsigned long start_index,
 				   unsigned long pitch_index)
@@ -152,18 +162,16 @@
 	}
 }
 
-static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, 
-				  u8 *dst1, unsigned long fgcolor,
-				  unsigned long bgcolor, 
-				  unsigned long start_index,
-				  unsigned long pitch_index)
+static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
+				  unsigned long fgcolor, unsigned long bgcolor, 
+				  unsigned long start_index, unsigned long pitch_index)
 {
-	unsigned long shift, color = 0, bpp = p->var.bits_per_pixel;
+	unsigned long i, j, l = 8;
+	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;
 	unsigned long spitch = (image->width+7)/8;
-	u8 *src = image->data, *s;
-	unsigned long i, j, l;
+	u8 *s = image->data, *src;
 	
 	dst2 = (unsigned long *) dst1;
 
@@ -172,42 +180,42 @@
 		l = 8;
 		j = image->width;
 		dst = (unsigned long *) dst1;
-		s = src;
-
+		src = s;
 		/* write leading bits */
 		if (start_index) {
-			unsigned long start_mask = ~(SHIFT_HIGH(~0UL,
+			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, 
 								start_index));
+
 			val = FB_READL(dst) & start_mask;
 			shift = start_index;
 		}
-
 		while (j--) {
 			l--;
-			color = (*s & (1 << l)) ? fgcolor : bgcolor;
+			color = (*src & (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++);
-				val = (shift == null_bits) ? 0 :
-					 SHIFT_LOW(color,BITS_PER_LONG - shift);
+				if (shift == null_bits)
+					val = 0;
+				else
+					val = SHIFT_LOW(color, 
+							BITS_PER_LONG - shift);
 			}
 			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
-			if (!l) { l = 8; s++; };
+			if (!l) { l = 8; src++; };
 		}
-
 		/* write trailing bits */
  		if (shift) {
 			unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
 
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
-		
-		dst1 += pitch;
-		src += spitch;	
+		dst1 += pitch;	
+		s += spitch;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (char *) dst2;
@@ -229,17 +237,16 @@
  *           beginning and end of a scanline is dword aligned
  */
 static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, 
-				  u8 *dst1, unsigned long fgcolor, 
-				  unsigned long bgcolor) 
+				  u8 *dst1, u32 fgcolor, u32 bgcolor) 
 {
-	unsigned long fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
-	unsigned long ppw = BITS_PER_LONG/bpp, spitch = (image->width + 7)/8;
-	unsigned long bit_mask, end_mask, eorx, shift;
-	char *s = image->data, *src;
-	unsigned long *dst;
+	int i, j, k; 
+	u32 bit_mask, end_mask, eorx, shift; 
+	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
+	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
 	u32 *tab = NULL;
-	int i, j, k;
-		
+	unsigned long *dst;
+	char *s = image->data, *src;
+
 	switch (bpp) {
 	case 8:
 		tab = cfb_tab8;
@@ -264,19 +271,19 @@
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
-		dst = (unsigned long *) dst1, shift = 8; src = s;
-		
+		INIT_FASTPATH;
+		dst = (unsigned long *) dst1; shift = 8; src = s;
 		for (j = k; j--; ) {
 			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }		
+			end_mask = tab[(*src >> shift) & bit_mask]; 
+			FASTPATH;
+			if (!shift) { shift = 8; src++; }
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
 }	
-	
+
 void cfb_imageblit(struct fb_info *p, struct fb_image *image)
 {
 	unsigned long fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
@@ -324,12 +331,13 @@
 			bgcolor = image->bg_color;
 		}	
 		
-		if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index && 
+		if (BITS_PER_LONG % bpp==0 && !start_index && !pitch_index &&
 		    ((image->width & (BITS_PER_LONG/bpp-1)) == 0) &&
 		    bpp >= 8 && bpp <= 32) 			
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
 		else 
-			slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
+			slow_imageblit(image, p, dst1, fgcolor, bgcolor, 
+				       start_index, pitch_index);
 	}
 	else if (image->depth == bpp) 
 		color_imageblit(image, p, dst1, start_index, pitch_index);
diff -Naur linux-2.5.59/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.59/drivers/video/console/fbcon.c	2003-01-17 07:40:40.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-17 07:42:39.000000000 +0000
@@ -399,7 +399,7 @@
 
 	if (!(vc->vc_font.width & 7)) {
 		unsigned int pitch, cnt, i, j, k;
-		unsigned int maxcnt = FB_PIXMAPSIZE/(vc->vc_font.height * width);
+		unsigned int maxcnt = FB_PIXMAPSIZE/cellsize;
 		char *src, *dst, *dst0;
 
 		image.data = pixmap;
@@ -437,8 +437,6 @@
 			image.dx += vc->vc_font.width;
 		}	
 	}
-	if (info->fbops->fb_sync)
-		info->fbops->fb_sync(info);
 }
 
 void accel_clear_margins(struct vc_data *vc, struct display *p,
@@ -1883,10 +1881,11 @@
 	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;
-	  
+	if (err || var.xres != info->var.xres ||
+		 var.yres != info->var.yres)
+		return -EINVAL;
+	p->vrows = info->var.yres_virtual/vc->vc_font.height;
+	return 0;
 }
 
 static int fbcon_switch(struct vc_data *vc)

Re: [Linux-fbdev-devel] video dir reorg

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

On Don, 2003-01-16 at 04:52, Jon Smirl wrote: 
> 
> 1) We have two drivers for the same hardware. They
> should be sharing the same include files describing
> the hardware.

Might be a good idea.

> 2) Bug fixing, in some cases the same hardware bug
> would need to be fixed in two places.

Not sure about this, as I don't see much overlap, but it's plausible I
guess.

> 3) State saving.  When the virtual terminal is changed
> is the complete state of the DRM driver saved? What if
> one of the other virtual terminals plays with 3D mode?

A 3D driver (at least an OpenGL driver) needs to always keep track of
hardware state anyway, so after a VT switch it can just upload
everything it needs again.

> 4) DDC and secondary reset support. I was looking at
> adding this to some of the framebuffer drivers. The X
> driver can't share this code.

The framebuffer device could offer interfaces for these though?

> 5) General kernel config. The same peice of hardware
> appears in two different places.

For very different purposes. Anyway, couldn't the config hierarchy be
changed without moving code around, at least with Kconfig?


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

Re: [Linux-fbdev-devel] video dir reorg

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

On Wed, Jan 15, 2003 at 07:52:31PM -0800, Jon Smirl wrote:
> --- Michel D?nzer <mi...@da...> wrote:
> > While I hope there will be some form of cooperation
> > between framebuffer
> > devices and the DRM in the future, I do think they
> > basically serve very
> > different purposes so I don't think merging them
> > makes sense.
> 
> Some areas of cooperation.....
> 
> 1) We have two drivers for the same hardware. They
> should be sharing the same include files describing
> the hardware.
> 2) Bug fixing, in some cases the same hardware bug
> would need to be fixed in two places.
> 3) State saving.  When the virtual terminal is changed
> is the complete state of the DRM driver saved? What if
> one of the other virtual terminals plays with 3D mode?

Currently, mostly the state saving code is in the X server anyway, so it
would not help here.

> 4) DDC and secondary reset support. I was looking at
> adding this to some of the framebuffer drivers. The X
> driver can't share this code.
> 5) General kernel config. The same peice of hardware
> appears in two different places.

Also, i believe that some discution about the sharing of fb memory and
other such may be in common.

Also, there could be the possibility (remote possiblity though) that the
fbdev driver author and the DRI author is the same person.

> There is no immediate reason for merging. I am just
> thinking about where this will be in three to five
> years. 
> 
> A more general question, what should be the
> capabilities of an in kernel video driver?
> 
> Required:
> 1) Complete state save on VT switch

This is done in the X server right now, altough i believe the fbdev also
does save its state on VT exit.

> 2) Security and control of DMA hardware

done in the drm module.

> Maybe required:
> 1) Reset and initialize hardware
> 2) Video mode change
> 3) Power saving

Currently duplicated in the X server and the fbdev driver. Mmm, maybe X
does not know about power saving, since i think the dri/ati people leave the
X VT  for fbdev before going in power saving mode.

> Not clear if better in user or kernel space:
> 1) copy, fill, blit, etc in current fb interface

This is common between X and fbdev. The architecture and the needs are
different, though, so i don't believe there will be anything shareable
here.

Also i thought Linus would not accept anything beyond console
acceleration stuff in the kernel anyway.

> Where is the right place to draw the link between
> kernel and user space for video drivers?

All accel except basic console driving code we have right now go to
userspace.

DMA, security control and irq handling need to be in the kernel though.

Friendly,

Sven Luther
> 
> 
> 
> 
> 
> =====
> Jon Smirl
> jon...@ya...
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
> is essential in establishing user confidence by providing assurance of 
> authenticity and code integrity. Download our Free Code Signing guide:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] [PATCH]: Various fbdev fixes:

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

Hi James,

It seems that the 32/64-bit patch for fast_imageblit() and the
"non-divisible by 8 width" fix for slow_imageblit() did not completely
take.  So here's an updated patch against linux-2.5.58 + your latest
fbdev.diff:

a.  Fix for fast_imageblit() being unclean on 64-bit and higher
machines:  With the change, the 32-bit tables will be accessed 2 (or
more) times  on >= 64-bit machines before doing a single FB_WRITEL. 
Because the extra tests and bit packing impose a performance penalty for
32-bit machines, 32-bit machines undergo a different, faster, and
simpler path.

c.  Fix for slow_imageblit() being unclean for bitmaps with widths not
divisible by 8.

d.  Fix for fbcon_resize().  Update display.vrows after fb_set_var(). 
This should fix console problems when fb_var_screeninfo.yres_virtual is
changed and y-panning is enabled. Only activated when fbcon_switch() is
called.

e.  Trivial:  info->fbops->fb_sync() may not be necessary in
accel_putcs().

Tony

diff -Naur linux-2.5.58-fbdev/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.58-fbdev/drivers/video/cfbimgblt.c	2003-01-16 03:09:59.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-16 03:31:41.000000000 +0000
@@ -73,26 +73,36 @@
 	0x00000000, 0xffffffff
 };
 
-#if BITS_PER_LONG == 32
-#define FB_WRITEL fb_writel
-#define FB_READL  fb_readl
-#else
-#define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq
-#endif 
-
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - 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 NEXT_POS(pos, bpp)     ((pos) += (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
 #endif
 
+#if BITS_PER_LONG == 32
+#define FB_WRITEL        fb_writel
+#define FB_READL         fb_readl
+#define INIT_FASTPATH    {}
+#define FASTPATH         fb_writel((end_mask & eorx)^bgx, dst++)
+#else
+#define FB_WRITEL        fb_writeq
+#define FB_READL         fb_readq
+#define INIT_FASTPATH    unsigned val = 0, bpl = 0 
+#define FASTPATH {                                     \
+	val |= SHIFT_HIGH((end_mask & eorx)^bgx, bpl); \
+	bpl += 32;                                     \
+	bpl &= BITS_PER_LONG - 1;                      \
+	if (!bpl) {                                    \
+		FB_WRITEL(val, dst++);                 \
+		val = 0;                               \
+	}                                              \
+}                                                      
+#endif 
+
 static inline void color_imageblit(struct fb_image *image, struct fb_info *p, 
 				   u8 *dst1, unsigned long start_index,
 				   unsigned long pitch_index)
@@ -160,29 +170,28 @@
 	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;
-	u8 *src = image->data, *s;
+	unsigned long spitch = (image->width+7)/8;
+	u8 *s = image->data, *src;
 	
 	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;
-
+		src = s;
 		/* write leading bits */
 		if (start_index) {
-			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, start_index));
+			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, 
+								start_index));
 
 			val = FB_READL(dst) & start_mask;
 			shift = start_index;
 		}
 		while (j--) {
 			l--;
-			if (*src & (1 << l)) 
-				color = fgcolor;
-			else 
-				color = bgcolor;
+			color = (*src & (1 << l)) ? fgcolor : bgcolor;
 			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			
@@ -192,7 +201,8 @@
 				if (shift == null_bits)
 					val = 0;
 				else
-					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+					val = SHIFT_LOW(color, 
+							BITS_PER_LONG - shift);
 			}
 			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
@@ -205,7 +215,7 @@
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
 		dst1 += pitch;	
-
+		s += spitch;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (char *) dst2;
@@ -227,17 +237,16 @@
  *           beginning and end of a scanline is dword aligned
  */
 static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, 
-				  u8 *dst1, unsigned long fgcolor, 
-				  unsigned long bgcolor) 
+				  u8 *dst1, u32 fgcolor, u32 bgcolor) 
 {
-	unsigned long fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
-	unsigned long ppw = BITS_PER_LONG/bpp, spitch = (image->width + 7)/8;
-	unsigned long bit_mask, end_mask, eorx, shift;
-	char *s = image->data, *src;
-	unsigned long *dst;
+	int i, j, k; 
+	u32 bit_mask, end_mask, eorx, shift; 
+	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
+	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
 	u32 *tab = NULL;
-	int i, j, k;
-		
+	unsigned long *dst;
+	char *s = image->data, *src;
+
 	switch (bpp) {
 	case 8:
 		tab = cfb_tab8;
@@ -262,19 +271,19 @@
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
-		dst = (unsigned long *) dst1, shift = 8; src = s;
-		
+		INIT_FASTPATH;
+		dst = (unsigned long *) dst1; shift = 8; src = s;
 		for (j = k; j--; ) {
 			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }		
+			end_mask = tab[(*src >> shift) & bit_mask]; 
+			FASTPATH;
+			if (!shift) { shift = 8; src++; }
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
 }	
-	
+
 void cfb_imageblit(struct fb_info *p, struct fb_image *image)
 {
 	unsigned long fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
@@ -322,12 +331,13 @@
 			bgcolor = image->bg_color;
 		}	
 		
-		if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index && 
+		if (BITS_PER_LONG % bpp==0 && !start_index && !pitch_index &&
 		    ((image->width & (BITS_PER_LONG/bpp-1)) == 0) &&
 		    bpp >= 8 && bpp <= 32) 			
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
 		else 
-			slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
+			slow_imageblit(image, p, dst1, fgcolor, bgcolor, 
+				       start_index, pitch_index);
 	}
 	else if (image->depth == bpp) 
 		color_imageblit(image, p, dst1, start_index, pitch_index);
diff -Naur linux-2.5.58-fbdev/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.58-fbdev/drivers/video/console/fbcon.c	2003-01-16 03:10:12.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-16 03:10:35.000000000 +0000
@@ -399,7 +399,7 @@
 
 	if (!(vc->vc_font.width & 7)) {
 		unsigned int pitch, cnt, i, j, k;
-		unsigned int maxcnt = FB_PIXMAPSIZE/(vc->vc_font.height * width);
+		unsigned int maxcnt = FB_PIXMAPSIZE/cellsize;
 		char *src, *dst, *dst0;
 
 		image.data = pixmap;
@@ -437,8 +437,6 @@
 			image.dx += vc->vc_font.width;
 		}	
 	}
-	if (info->fbops->fb_sync)
-		info->fbops->fb_sync(info);
 }
 
 void accel_clear_margins(struct vc_data *vc, struct display *p,
@@ -1883,10 +1881,11 @@
 	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;
-	  
+	if (err || var.xres != info->var.xres ||
+	    var.yres != info->var.yres)
+		return -EINVAL;
+	p->vrows = info->var.yres_virtual/vc->vc_font.height;
+	return 0;
 }
 
 static int fbcon_switch(struct vc_data *vc)

Re: [Linux-fbdev-devel] video dir reorg

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

--- Michel Dänzer <mi...@da...> wrote:
> While I hope there will be some form of cooperation
> between framebuffer
> devices and the DRM in the future, I do think they
> basically serve very
> different purposes so I don't think merging them
> makes sense.

Some areas of cooperation.....

1) We have two drivers for the same hardware. They
should be sharing the same include files describing
the hardware.
2) Bug fixing, in some cases the same hardware bug
would need to be fixed in two places.
3) State saving.  When the virtual terminal is changed
is the complete state of the DRM driver saved? What if
one of the other virtual terminals plays with 3D mode?
4) DDC and secondary reset support. I was looking at
adding this to some of the framebuffer drivers. The X
driver can't share this code.
5) General kernel config. The same peice of hardware
appears in two different places.

There is no immediate reason for merging. I am just
thinking about where this will be in three to five
years. 

A more general question, what should be the
capabilities of an in kernel video driver?

Required:
1) Complete state save on VT switch
2) Security and control of DMA hardware
Maybe required:
1) Reset and initialize hardware
2) Video mode change
3) Power saving
Not clear if better in user or kernel space:
1) copy, fill, blit, etc in current fb interface

Where is the right place to draw the link between
kernel and user space for video drivers?





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

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