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

RE: [Linux-fbdev-devel] (no subject)

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

On Wed, 2002-12-11 at 02:05, vivens wrote:
> Well, I mend it like this:
> I'm trying to build a framebuffer for an embedded ARM platform (which
> doesn't use any kind of a Lunix distr).
> I want to use a framebuffer, because some apps need it. For example the
> ZEN browser I want to implement on this platform.

You can check the linux-2.5.51 for insights.  But if you just want to 
implement the API without necessarily conforming to linux's framebuffer
support (don't want to use linux), then:

First you need hardware with linear video memory.

If you want compatibility with standard fb_apps , then you need the
following;
1. accessing the driver as a file (/dev/fbx) - the name is pretty much
hardwired.
2. support standard file operations (open, close, read, write).  The
read/write operation accesses the video memory.

3. This is the biggie:  support for most fb_specific ioctls (check
drivers/video/fbmem.c).  

Required ioctl support:
a. Setting the struct fb_var_screeninfo.  This is basically the
structure used to communicate between user apps and the driver, and
contains information that can modify the video/framebuffer state
depending on the capabilities of the hardware.  As for the video
/framebuffer state, it encompasses the dimensions of the display, the
pixelformat, the color information, etc, as described in the file
linux/include/linux/fb.h.  

You don't have to follow everything in the request.  In fact, you don't
even have to do anything at all, but you must return an
fb_var_screeninfo structure that is valid for the driver. It's like the
app saying "this is what I want" and the driver returning with "this is
what you get, take it or leave it".

b. Getting the struct fb_var_screeninfo.  This is simple enough, it
returns the structure containing information describing the current
state.

c. Getting struct fb_fix_screeninfo.  This structure contains
information that cannot be altered by outside requests, that's why get
is only supported.  It does partly depend on fb_var_screeninfo, but is
more or less hardware specific information. This is a one way ioctl,
driver to user.

As for the rest of the ioctls, you can just return success or fail.

4. have video memory mappable to user space (check fb_mmap in fbmem.c).
Although optional, practically all apps use/need this.

5. You may wish to skip console support because that entails a lot of
work. (and you probably don't need this)

> So my question is:
> What basic functions does a framebuffer normally have, what is need to
> initialize for these functions?

At a bare minimum, the driver must set the hardware into a state as
imposed by itself during initialization, or by requests through
fb_var_screeninfo..  

For most apps, mmap support must be included.

The simplest driver then would support #1, #2, #4, and set the video
mode at initialization.  As for #3, just return success/fail, making
sure the driver channels back the correct information to the userland
app, without actually doing anything at all. 

> Can I see the framebuffer as the API between the video hardware and any
> application what uses the video hardware?
> 

Yes, that's the goal of the framebuffer, to abstract the underlying
hardware into a well-defined interface.  But to keep it as simple and as
cross-platform as possible, the API is at the barest minimum (set the
hardware, set the mode, and offer access to the graphics memory either
through file reads/writes or mmap). The rest are icing on the cake.

If I missed anything, feel free.

Tony

[Linux-fbdev-devel] Re: [FBDEV]: Framebuffer driver for Intel 810/815 chipsets

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

Applied !!!!

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On 11 Dec 2002, Antonino Daplas wrote:

> James,
>
> It seems the fbdev framework is stable enough, and already in the
> development tree.  So, I'm submitting a driver for the Intel 810/815 for
> review and perhaps inclusion to your tree (to get more testing), and
> hopefully merge with Linus's tree.
>
> The patch is against linux-2.5.51, but will not work yet because of 2
> reasons:
>
> 1. agpgart is not working for the i810
> 2. support for early agp initialization needs to be added.
>
> Once #1 is fixed, the driver should work as a module.  And once #2 gets
> included, the driver can be compiled statically.  Dave Jones (thanks for
> the help, by the way) has already #2 in his tree (tested and works), and
> is currently working on #1 (I have a hacked version at home).
>
> The driver should be compliant with fbdev-2.5, and should support most
> if not all features that are to be expected (modularity, state saving
> and restoring, full hardware support, etc).  One thing also that's very
> important for many people is that the driver will work with XFree86 with
> its native i810 drivers without further modification, and quite stably
> too.
>
> The patch is at
> http://i810fb.sourceforge.net/linux-2.5.51-i810fb.diff.gz
>
> Thanks,
>
> Tony
>
>
>
>
>

[Linux-fbdev-devel] anyone working on radeonfb?

[Aleksandr K. <cz...@ik...>]

hello

is anyone actively maintaining the radeon fb driver in the 2.4 series?

I've started reviving and older hacked version (based on mplayer radeonfb)
of the driver. The version I have has proper panning and accel console
(almost, 32bit mode is causing some minor head-aches still).

I'd like to eventually sync my version with the kernel one (and yes, I
know that the mplayer version is way off Linus coding style, and yes, it's
based somewhat on xfree86, but I'm willing to work that out eventually).

currently I have only some radeon boards left, but no DVI anymore, so I'll
need someone with DVI displays as well. Also I have no access to PPCs, so
would need someone to test the newer driver there as well if possible.

thanks :-)

ak.

Re: [Linux-fbdev-devel] 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

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

On Wed, 2002-12-11 at 05:39, Miles Lane wrote: 
> Hi,
> 
> I have tried getting rivafb to work in 2.5.51.  It is much better
> than before (thanks!).  It compiles and sorta works.
> 
Can you test the attached patch (rivafb1.diff)?  It fixes some things: 

1. double ioremap/request_mem_region of the framebuffer memory.  Might
cause some initialization weirdness :-) 

2. riva_hw.c is outdated (no support for NV_ARCH_20) which will crash
the GeForce3's (I think I read one report of that in the  kernel mailing
list). 

3.  Matched the initialization ordering of rivafb in linux-2.4, except
that RivaGetConfig is executed at rivafb_open(). 

3. Not sure if the color problem will be fixed.  Miles, are you by
offchance using bpp > 8?  Because setting the DAC at 8 bpp should be a
very simple matter compared with directcolor which requires some
juggling acts 

Also, you mentioned that everything is okay except the characters are
mirrored in the vertical axis, is this correct?  Meaning colors are fine
etc.  If this is the case, try this patch also: 

diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c	2002-12-12 13:59:07.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2002-12-12 13:59:30.000000000 +0000
@@ -917,9 +917,11 @@
 	size = width * h;
 	dat = cdat;
 
-	for (i = 0; i < size; i++) {
-		*dat = byte_rev[*dat];
-		dat++;
+	if (par->riva.Architecture == NV_ARCH_03) {
+		for (i = 0; i < size; i++) {
+			*dat = byte_rev[*dat];
+			dat++;
+		}
 	}
 
 	switch (info->var.bits_per_pixel) {

Tony

[Linux-fbdev-devel] [PATCH] fix text console redrawing

[Paul M. <pa...@sa...>]

I found out why the text console wasn't getting redrawn when switching
from X back to tty1.  It was because the vc->vc_font.width and .height
for tty1 had been reset to 0 by fbcon_set_display().  The font-setting
logic in there looks wrong to me, and this patch should fix it.
Without this patch, we find the first console on this fb which appears
to have valid font data and then copy the width and height *to* that
console rather than *from* that console.  This patch changes it to
copy from that console to the new console that we are initializing.

Paul.

diff -urN linux-2.5/drivers/video/console/fbcon.c pmac-2.5/drivers/video/console/fbcon.c
--- linux-2.5/drivers/video/console/fbcon.c	2002-12-10 15:20:32.000000000 +1100
+++ pmac-2.5/drivers/video/console/fbcon.c	2002-12-12 13:46:21.000000000 +1100
@@ -926,11 +926,11 @@
 		struct display *q = &fb_display[i];
 		struct vc_data *tmp = vc_cons[i].d;
 		
-		if (fontwidthvalid(p, vc->vc_font.width)) {
+		if (!fontwidthvalid(p, vc->vc_font.width)) {
 			/* If we are not the first console on this
 			   fb, copy the font from that console */
-			tmp->vc_font.width = vc->vc_font.width;
-			tmp->vc_font.height = vc->vc_font.height;
+			vc->vc_font.width = tmp->vc_font.width;
+			vc->vc_font.height = tmp->vc_font.height;
 			p->fontdata = q->fontdata;
 			p->userfont = q->userfont;
 			if (p->userfont) {

[Linux-fbdev-devel] [PATCH] fix offb

[Paul M. <pa...@sa...>]

This patch fixes the offb driver, and fixes the Makefile so it doesn't
go looking for a nonexistent file (cfbimgblit.o) when CONFIG_FB_OF is
turned on.  In the offb driver, we were overrunning the end of the
info->fix.id field on some cards, plus it had an undefined variable.
I guess we could also get rid of the "info->node = NODEV;" line too.

Paul.

diff -urN linux-2.5/drivers/video/Makefile pmac-2.5/drivers/video/Makefile
--- linux-2.5/drivers/video/Makefile	2002-12-10 15:20:32.000000000 +1100
+++ pmac-2.5/drivers/video/Makefile	2002-12-10 21:25:36.000000000 +1100
@@ -42,7 +42,7 @@
 obj-$(CONFIG_FB_3DFX)             += tdfxfb.o
 obj-$(CONFIG_FB_MAC)              += macfb.o macmodes.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o 
 obj-$(CONFIG_FB_HP300)            += hpfb.o cfbfillrect.o cfbimgblt.o
-obj-$(CONFIG_FB_OF)               += offb.o cfbfillrect.o cfbimgblit.o cfbcopyarea.o
+obj-$(CONFIG_FB_OF)               += offb.o cfbfillrect.o cfbimgblt.o cfbcopyarea.o
 obj-$(CONFIG_FB_IMSTT)            += imsttfb.o
 obj-$(CONFIG_FB_RETINAZ3)         += retz3fb.o
 obj-$(CONFIG_FB_CLGEN)            += clgenfb.o
diff -urN linux-2.5/drivers/video/offb.c pmac-2.5/drivers/video/offb.c
--- linux-2.5/drivers/video/offb.c	2002-12-10 15:20:32.000000000 +1100
+++ pmac-2.5/drivers/video/offb.c	2002-12-10 19:58:24.000000000 +1100
@@ -393,6 +393,7 @@
 	struct fb_fix_screeninfo *fix;
 	struct fb_var_screeninfo *var;
 	struct fb_info *info;
+	int size;
 
 	if (!request_mem_region(res_start, res_size, "offb"))
 		return;
@@ -421,7 +422,7 @@
 	var = &info->var;
 
 	strcpy(fix->id, "OFfb ");
-	strncat(fix->id, name, sizeof(fix->id));
+	strncat(fix->id, name, sizeof(fix->id) - sizeof("OFfb "));
 	fix->id[sizeof(fix->id) - 1] = '\0';
 
 	var->xres = var->xres_virtual = width;
@@ -522,8 +523,6 @@
 	var->sync = 0;
 	var->vmode = FB_VMODE_NONINTERLACED;
 
-	strcpy(fix->id, "OFfb ");
-	strncat(fix->id, full_name, sizeof(fix->id));
 	info->node = NODEV;
 	info->fbops = &offb_ops;
 	info->screen_base = ioremap(address, fix->smem_len);

[Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit

[Paul M. <pa...@sa...>]

This patch fixes the endian problems in color_imageblit().  With this
patch, I get the penguin drawn properly on boot.

The main change is that on big-endian systems, when we load a pixel
from the source, we now shift it to the left-hand (most significant)
end of the word.  With this change the rest of the logic is correct on
big-endian systems.  This may not be the most efficient way to do
things but it is a simple change that works and avoids disturbing the
rest of the code.

Paul.

diff -urN linux-2.5/drivers/video/cfbimgblt.c pmac-2.5/drivers/video/cfbimgblt.c
--- linux-2.5/drivers/video/cfbimgblt.c	2002-12-10 15:20:32.000000000 +1100
+++ pmac-2.5/drivers/video/cfbimgblt.c	2002-12-12 09:14:47.000000000 +1100
@@ -103,10 +103,10 @@
 {
 	/* Draw the penguin */
 	int i, n;
-	unsigned long bitmask = SHIFT_LOW(~0UL, BITS_PER_LONG - p->var.bits_per_pixel);
+	int bpp = p->var.bits_per_pixel;
 	unsigned long *palette = (unsigned long *) p->pseudo_palette;
 	unsigned long *dst, *dst2, color = 0, val, shift;
-	unsigned long null_bits = BITS_PER_LONG - p->var.bits_per_pixel; 
+	unsigned long null_bits = BITS_PER_LONG - bpp;
 	u8 *src = image->data;
 
 	dst2 = (unsigned long *) dst1;
@@ -125,9 +125,10 @@
 		while (n--) {
 			if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 			    p->fix.visual == FB_VISUAL_DIRECTCOLOR )
-				color = palette[*src] & bitmask;
+				color = palette[*src];
 			else
-				color = *src & bitmask;	
+				color = *src;
+			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
@@ -136,7 +137,7 @@
 				else
 					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
 			}
-			shift += p->var.bits_per_pixel;
+			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
 			src++;
 		}

[Linux-fbdev-devel] Re: atyfb in 2.5.51

[Paul M. <pa...@sa...>]

James Simmons writes:

> :-( True. We should always assume X or any userland app could be broken.

I don't think we can blame X in this particular situation.  When I
press ctrl-alt-F1 in X, it resets the screen to the colormap and depth
that the text console was using, but the kernel doesn't redraw the
text console screen image.  (I presume it also resets the resolution,
but since I have only tried on an LCD screen I can't say for sure.)

Paul.

[Linux-fbdev-devel] Re: atyfb in 2.5.51

[Alan C. <al...@lx...>]

On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> fbdev is nice, in the specific cases where the device fits the fbdev
> model, because once you have the kernel bits you have X support :)

fbdev also can't be used in some situations on x86. Deeply fascinating
things happen on some x86 processors if you execute a loop of code with
an instruction that crosses two different memory types.

[Linux-fbdev-devel] Re: atyfb in 2.5.51

[David S. M. <da...@re...>]

   From: James Simmons <jsi...@in...>
   Date: Wed, 11 Dec 2002 07:16:04 -0800 (PST)
   
   I agree that the design of the /dev/fbX interface is not the best.
   Unfortunely we are stuck with it. Changing it would break userland apps.
   
I totally understand.  I do not suggest to break fbdev in it's current
form, too much stuff uses it.

My main point was, don't be surprised the X servers, like the ATI
driver, don't use fbdev and instead just mmap the device and simply
program it directly.

fbdev is nice, in the specific cases where the device fits the fbdev
model, because once you have the kernel bits you have X support :)

Franks a lot,
David S. Miller
da...@re...

[Linux-fbdev-devel] Radeon frame buffer compile error?

[imranj <im...@em...>]

this is the error that i get when i compile my modules

system :- redhat 8.0 no upgrades to the core components ex gcc compilers 
every thing with default settings.


DKBUILD_MODNAME=cfbimgblt -DEXPORT_SYMTAB  -c -o 
drivers/video/cfbimgblt.o drivers/video/cfbimgblt.c
  ld -m elf_i386  -r -o drivers/video/cfbimgblt.ko drivers/video/cfbimgblt.o
  gcc -Wp,-MD,drivers/video/.radeonfb.o.d -D__KERNEL__ -Iinclude -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=pentium4 
-Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix 
include -DMODULE   -DKBUILD_BASENAME=radeonfb 
-DKBUILD_MODNAME=radeonfb   -c -o drivers/video/radeonfb.o 
drivers/video/radeonfb.c
drivers/video/radeonfb.c:187: `PCI_DEVICE_ID_ATI_RADEON_QD' undeclared 
here (not in a function)
drivers/video/radeonfb.c:187: initializer element is not constant
drivers/video/radeonfb.c:187: (near initialization for 
`radeonfb_pci_table[0].device')
drivers/video/radeonfb.c:187: initializer element is not constant
drivers/video/radeonfb.c:187: (near initialization for 
`radeonfb_pci_table[0]')
drivers/video/radeonfb.c:188: `PCI_DEVICE_ID_ATI_RADEON_QE' undeclared 
here (not in a function)
drivers/video/radeonfb.c:188: initializer element is not constant
drivers/video/radeonfb.c:188: (near initialization for 
`radeonfb_pci_table[1].device')
drivers/video/radeonfb.c:188: initializer element is not constant
drivers/video/radeonfb.c:188: (near initialization for 
`radeonfb_pci_table[1]')
drivers/video/radeonfb.c:189: `PCI_DEVICE_ID_ATI_RADEON_QF' undeclared 
here (not in a function)
drivers/video/radeonfb.c:189: initializer element is not constant
drivers/video/radeonfb.c:189: (near initialization for 
`radeonfb_pci_table[2].device')
drivers/video/radeonfb.c:189: initializer element is not constant
drivers/video/radeonfb.c:189: (near initialization for 
`radeonfb_pci_table[2]')
drivers/video/radeonfb.c:190: `PCI_DEVICE_ID_ATI_RADEON_QG' undeclared 
here (not in a function)
drivers/video/radeonfb.c:190: initializer element is not constant
drivers/video/radeonfb.c:190: (near initialization for 
`radeonfb_pci_table[3].device')
drivers/video/radeonfb.c:190: initializer element is not constant
drivers/video/radeonfb.c:190: (near initialization for 
`radeonfb_pci_table[3]')
drivers/video/radeonfb.c:191: `PCI_DEVICE_ID_ATI_RADEON_QY' undeclared 
here (not in a function)
drivers/video/radeonfb.c:191: initializer element is not constant
drivers/video/radeonfb.c:191: (near initialization for 
`radeonfb_pci_table[4].device')
drivers/video/radeonfb.c:191: initializer element is not constant
drivers/video/radeonfb.c:191: (near initialization for 
`radeonfb_pci_table[4]')
drivers/video/radeonfb.c:192: `PCI_DEVICE_ID_ATI_RADEON_QZ' undeclared 
here (not in a function)
drivers/video/radeonfb.c:192: initializer element is not constant
drivers/video/radeonfb.c:192: (near initialization for 
`radeonfb_pci_table[5].device')
drivers/video/radeonfb.c:192: initializer element is not constant
drivers/video/radeonfb.c:192: (near initialization for 
`radeonfb_pci_table[5]')
drivers/video/radeonfb.c:193: `PCI_DEVICE_ID_ATI_RADEON_LW' undeclared 
here (not in a function)
drivers/video/radeonfb.c:193: initializer element is not constant
drivers/video/radeonfb.c:193: (near initialization for 
`radeonfb_pci_table[6].device')
drivers/video/radeonfb.c:193: initializer element is not constant
drivers/video/radeonfb.c:193: (near initialization for 
`radeonfb_pci_table[6]')
drivers/video/radeonfb.c:194: `PCI_DEVICE_ID_ATI_RADEON_LX' undeclared 
here (not in a function)
drivers/video/radeonfb.c:194: initializer element is not constant
drivers/video/radeonfb.c:194: (near initialization for 
`radeonfb_pci_table[7].device')
drivers/video/radeonfb.c:194: initializer element is not constant
drivers/video/radeonfb.c:194: (near initialization for 
`radeonfb_pci_table[7]')
drivers/video/radeonfb.c:195: `PCI_DEVICE_ID_ATI_RADEON_LY' undeclared 
here (not in a function)
drivers/video/radeonfb.c:195: initializer element is not constant
drivers/video/radeonfb.c:195: (near initialization for 
`radeonfb_pci_table[8].device')
drivers/video/radeonfb.c:195: initializer element is not constant
drivers/video/radeonfb.c:195: (near initialization for 
`radeonfb_pci_table[8]')
drivers/video/radeonfb.c:196: `PCI_DEVICE_ID_ATI_RADEON_LZ' undeclared 
here (not in a function)
drivers/video/radeonfb.c:196: initializer element is not constant
drivers/video/radeonfb.c:196: (near initialization for 
`radeonfb_pci_table[9].device')
drivers/video/radeonfb.c:196: initializer element is not constant
drivers/video/radeonfb.c:196: (near initialization for 
`radeonfb_pci_table[9]')
drivers/video/radeonfb.c:197: `PCI_DEVICE_ID_ATI_RADEON_QL' undeclared 
here (not in a function)
drivers/video/radeonfb.c:197: initializer element is not constant
drivers/video/radeonfb.c:197: (near initialization for 
`radeonfb_pci_table[10].device')
drivers/video/radeonfb.c:197: initializer element is not constant
drivers/video/radeonfb.c:197: (near initialization for 
`radeonfb_pci_table[10]')
drivers/video/radeonfb.c:198: `PCI_DEVICE_ID_ATI_RADEON_QN' undeclared 
here (not in a function)
drivers/video/radeonfb.c:198: initializer element is not constant
drivers/video/radeonfb.c:198: (near initialization for 
`radeonfb_pci_table[11].device')
drivers/video/radeonfb.c:198: initializer element is not constant
drivers/video/radeonfb.c:198: (near initialization for 
`radeonfb_pci_table[11]')
drivers/video/radeonfb.c:199: `PCI_DEVICE_ID_ATI_RADEON_QO' undeclared 
here (not in a function)
drivers/video/radeonfb.c:199: initializer element is not constant
drivers/video/radeonfb.c:199: (near initialization for 
`radeonfb_pci_table[12].device')
drivers/video/radeonfb.c:199: initializer element is not constant
drivers/video/radeonfb.c:199: (near initialization for 
`radeonfb_pci_table[12]')
drivers/video/radeonfb.c:200: `PCI_DEVICE_ID_ATI_RADEON_Ql' undeclared 
here (not in a function)
drivers/video/radeonfb.c:200: initializer element is not constant
drivers/video/radeonfb.c:200: (near initialization for 
`radeonfb_pci_table[13].device')
drivers/video/radeonfb.c:200: initializer element is not constant
drivers/video/radeonfb.c:200: (near initialization for 
`radeonfb_pci_table[13]')
drivers/video/radeonfb.c:201: `PCI_DEVICE_ID_ATI_RADEON_BB' undeclared 
here (not in a function)
drivers/video/radeonfb.c:201: initializer element is not constant
drivers/video/radeonfb.c:201: (near initialization for 
`radeonfb_pci_table[14].device')
drivers/video/radeonfb.c:201: initializer element is not constant
drivers/video/radeonfb.c:201: (near initialization for 
`radeonfb_pci_table[14]')
drivers/video/radeonfb.c:202: `PCI_DEVICE_ID_ATI_RADEON_QW' undeclared 
here (not in a function)
drivers/video/radeonfb.c:202: initializer element is not constant
drivers/video/radeonfb.c:202: (near initialization for 
`radeonfb_pci_table[15].device')
drivers/video/radeonfb.c:202: initializer element is not constant
drivers/video/radeonfb.c:202: (near initialization for 
`radeonfb_pci_table[15]')
drivers/video/radeonfb.c:203: `PCI_DEVICE_ID_ATI_RADEON_QX' undeclared 
here (not in a function)
drivers/video/radeonfb.c:203: initializer element is not constant
drivers/video/radeonfb.c:203: (near initialization for 
`radeonfb_pci_table[16].device')
drivers/video/radeonfb.c:203: initializer element is not constant
drivers/video/radeonfb.c:203: (near initialization for 
`radeonfb_pci_table[16]')
drivers/video/radeonfb.c:204: `PCI_DEVICE_ID_ATI_RADEON_Id' undeclared 
here (not in a function)
drivers/video/radeonfb.c:204: initializer element is not constant
drivers/video/radeonfb.c:204: (near initialization for 
`radeonfb_pci_table[17].device')
drivers/video/radeonfb.c:204: initializer element is not constant
drivers/video/radeonfb.c:204: (near initialization for 
`radeonfb_pci_table[17]')
drivers/video/radeonfb.c:205: `PCI_DEVICE_ID_ATI_RADEON_Ie' undeclared 
here (not in a function)
drivers/video/radeonfb.c:205: initializer element is not constant
drivers/video/radeonfb.c:205: (near initialization for 
`radeonfb_pci_table[18].device')
drivers/video/radeonfb.c:205: initializer element is not constant
drivers/video/radeonfb.c:205: (near initialization for 
`radeonfb_pci_table[18]')
drivers/video/radeonfb.c:206: `PCI_DEVICE_ID_ATI_RADEON_If' undeclared 
here (not in a function)
drivers/video/radeonfb.c:206: initializer element is not constant
drivers/video/radeonfb.c:206: (near initialization for 
`radeonfb_pci_table[19].device')
drivers/video/radeonfb.c:206: initializer element is not constant
drivers/video/radeonfb.c:206: (near initialization for 
`radeonfb_pci_table[19]')
drivers/video/radeonfb.c:207: `PCI_DEVICE_ID_ATI_RADEON_Ig' undeclared 
here (not in a function)
drivers/video/radeonfb.c:207: initializer element is not constant
drivers/video/radeonfb.c:207: (near initialization for 
`radeonfb_pci_table[20].device')
drivers/video/radeonfb.c:207: initializer element is not constant
drivers/video/radeonfb.c:207: (near initialization for 
`radeonfb_pci_table[20]')
drivers/video/radeonfb.c:208: `PCI_DEVICE_ID_ATI_RADEON_Ld' undeclared 
here (not in a function)
drivers/video/radeonfb.c:208: initializer element is not constant
drivers/video/radeonfb.c:208: (near initialization for 
`radeonfb_pci_table[21].device')
drivers/video/radeonfb.c:208: initializer element is not constant
drivers/video/radeonfb.c:208: (near initialization for 
`radeonfb_pci_table[21]')
drivers/video/radeonfb.c:209: `PCI_DEVICE_ID_ATI_RADEON_Le' undeclared 
here (not in a function)
drivers/video/radeonfb.c:209: initializer element is not constant
drivers/video/radeonfb.c:209: (near initialization for 
`radeonfb_pci_table[22].device')
drivers/video/radeonfb.c:209: initializer element is not constant
drivers/video/radeonfb.c:209: (near initialization for 
`radeonfb_pci_table[22]')
drivers/video/radeonfb.c:210: `PCI_DEVICE_ID_ATI_RADEON_Lf' undeclared 
here (not in a function)
drivers/video/radeonfb.c:210: initializer element is not constant
drivers/video/radeonfb.c:210: (near initialization for 
`radeonfb_pci_table[23].device')
drivers/video/radeonfb.c:210: initializer element is not constant
drivers/video/radeonfb.c:210: (near initialization for 
`radeonfb_pci_table[23]')
drivers/video/radeonfb.c:211: `PCI_DEVICE_ID_ATI_RADEON_Lg' undeclared 
here (not in a function)
drivers/video/radeonfb.c:211: initializer element is not constant
drivers/video/radeonfb.c:211: (near initialization for 
`radeonfb_pci_table[24].device')
drivers/video/radeonfb.c:211: initializer element is not constant
drivers/video/radeonfb.c:211: (near initialization for 
`radeonfb_pci_table[24]')
drivers/video/radeonfb.c:212: `PCI_DEVICE_ID_ATI_RADEON_ND' undeclared 
here (not in a function)
drivers/video/radeonfb.c:212: initializer element is not constant
drivers/video/radeonfb.c:212: (near initialization for 
`radeonfb_pci_table[25].device')
drivers/video/radeonfb.c:212: initializer element is not constant
drivers/video/radeonfb.c:212: (near initialization for 
`radeonfb_pci_table[25]')
drivers/video/radeonfb.c:213: `PCI_DEVICE_ID_ATI_RADEON_NE' undeclared 
here (not in a function)
drivers/video/radeonfb.c:213: initializer element is not constant
drivers/video/radeonfb.c:213: (near initialization for 
`radeonfb_pci_table[26].device')
drivers/video/radeonfb.c:213: initializer element is not constant
drivers/video/radeonfb.c:213: (near initialization for 
`radeonfb_pci_table[26]')
drivers/video/radeonfb.c:214: `PCI_DEVICE_ID_ATI_RADEON_NF' undeclared 
here (not in a function)
drivers/video/radeonfb.c:214: initializer element is not constant
drivers/video/radeonfb.c:214: (near initialization for 
`radeonfb_pci_table[27].device')
drivers/video/radeonfb.c:214: initializer element is not constant
drivers/video/radeonfb.c:214: (near initialization for 
`radeonfb_pci_table[27]')
drivers/video/radeonfb.c:215: `PCI_DEVICE_ID_ATI_RADEON_NG' undeclared 
here (not in a function)
drivers/video/radeonfb.c:215: initializer element is not constant
drivers/video/radeonfb.c:215: (near initialization for 
`radeonfb_pci_table[28].device')
drivers/video/radeonfb.c:215: initializer element is not constant
drivers/video/radeonfb.c:215: (near initialization for 
`radeonfb_pci_table[28]')
drivers/video/radeonfb.c:216: initializer element is not constant
drivers/video/radeonfb.c:216: (near initialization for 
`radeonfb_pci_table[29]')
drivers/video/radeonfb.c:364: field `disp' has incomplete type
drivers/video/radeonfb.c: In function `radeon_get_pllinfo':
drivers/video/radeonfb.c:857: `PCI_DEVICE_ID_ATI_RADEON_QW' undeclared 
(first use in this function)
drivers/video/radeonfb.c:857: (Each undeclared identifier is reported 
only once
drivers/video/radeonfb.c:857: for each function it appears in.)
drivers/video/radeonfb.c:858: `PCI_DEVICE_ID_ATI_RADEON_QX' undeclared 
(first use in this function)
drivers/video/radeonfb.c:865: `PCI_DEVICE_ID_ATI_RADEON_QL' undeclared 
(first use in this function)
drivers/video/radeonfb.c:866: `PCI_DEVICE_ID_ATI_RADEON_QN' undeclared 
(first use in this function)
drivers/video/radeonfb.c:867: `PCI_DEVICE_ID_ATI_RADEON_QO' undeclared 
(first use in this function)
drivers/video/radeonfb.c:868: `PCI_DEVICE_ID_ATI_RADEON_Ql' undeclared 
(first use in this function)
drivers/video/radeonfb.c:869: `PCI_DEVICE_ID_ATI_RADEON_BB' undeclared 
(first use in this function)
drivers/video/radeonfb.c:876: `PCI_DEVICE_ID_ATI_RADEON_Id' undeclared 
(first use in this function)
drivers/video/radeonfb.c:877: `PCI_DEVICE_ID_ATI_RADEON_Ie' undeclared 
(first use in this function)
drivers/video/radeonfb.c:878: `PCI_DEVICE_ID_ATI_RADEON_If' undeclared 
(first use in this function)
drivers/video/radeonfb.c:879: `PCI_DEVICE_ID_ATI_RADEON_Ig' undeclared 
(first use in this function)
drivers/video/radeonfb.c:886: `PCI_DEVICE_ID_ATI_RADEON_QD' undeclared 
(first use in this function)
drivers/video/radeonfb.c:887: `PCI_DEVICE_ID_ATI_RADEON_QE' undeclared 
(first use in this function)
drivers/video/radeonfb.c:888: `PCI_DEVICE_ID_ATI_RADEON_QF' undeclared 
(first use in this function)
drivers/video/radeonfb.c:889: `PCI_DEVICE_ID_ATI_RADEON_QG' undeclared 
(first use in this function)
drivers/video/radeonfb.c: In function `radeon_engine_init':
drivers/video/radeonfb.c:1231: `RB2D_DSTCACHE_MODE' undeclared (first 
use in this function)
drivers/video/radeonfb.c: In function `radeon_init_disp':
drivers/video/radeonfb.c:1292: warning: implicit declaration of function 
`gen_set_var'
drivers/video/radeonfb.c: In function `radeonfb_setcolreg':
drivers/video/radeonfb.c:1672: `PIXCLK_DAC_ALWAYS_ONb' undeclared (first 
use in this function)
drivers/video/radeonfb.c: In function `radeon_save_state':
drivers/video/radeonfb.c:1751: `TMDS_TRANSMITTER_CNTL' undeclared (first 
use in this function)
drivers/video/radeonfb.c: In function `radeonfb_set_par':
drivers/video/radeonfb.c:1982: `PIXCLK_DAC_ALWAYS_ONb' undeclared (first 
use in this function)
drivers/video/radeonfb.c:2041: `TMDS_RAN_PAT_RST' undeclared (first use 
in this function)
drivers/video/radeonfb.c:2042: `ICHCSEL' undeclared (first use in this 
function)
drivers/video/radeonfb.c:2042: `TMDS_PLL_EN' undeclared (first use in 
this function)
drivers/video/radeonfb.c:2043: `TMDS_PLLRST' undeclared (first use in 
this function)
drivers/video/radeonfb.c: In function `radeon_write_mode':
drivers/video/radeonfb.c:2150: `TMDS_TRANSMITTER_CNTL' undeclared (first 
use in this function)
drivers/video/radeonfb.c:2155: `LVDS_STATE_MASK' undeclared (first use 
in this function)
drivers/video/radeonfb.c: At top level:
drivers/video/radeonfb.c:2189: warning: initialization from incompatible 
pointer type
drivers/video/radeonfb.c: In function `radeon_set_fbinfo':
drivers/video/radeonfb.c:2210: structure has no member named `modename'
drivers/video/radeonfb.c:2210: structure has no member named `modename'
drivers/video/radeonfb.c:2214: structure has no member named `disp'
drivers/video/radeonfb.c: In function `radeonfb_pci_register':
drivers/video/radeonfb.c:2910: `PCI_DEVICE_ID_ATI_RADEON_LY' undeclared 
(first use in this function)
drivers/video/radeonfb.c:2911: `PCI_DEVICE_ID_ATI_RADEON_LZ' undeclared 
(first use in this function)
make[2]: *** [drivers/video/radeonfb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
[root@localhost linux]#

Re: [Linux-fbdev-devel] 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles L. <mil...@at...>]

On Wed, 2002-12-11 at 04:49, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> > Hi,
> > 
> > I have tried getting rivafb to work in 2.5.51.  It is much better
> > than before (thanks!).  It compiles and sorta works.
> > 
> > Here are the problems:
> > 
> > When I run "fbset -a 640x480", I get display that fills
> > the screen and looks okay, but most of the characters are
> > flipped along the vertical axis, so they are backwards, so that:
> > 
> > +----		    ----+
> > |			|
> > +---    becomes	     ---+
> > |			|
> > |			|
> > 
> What's the hardware, is it on a big endian machine? I think there's a
> typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN).  This should
> produce the "mirroring" effect.

CPU: AMD Athlon(tm) Processor stepping 01

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller (rev 25)

01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256
DDR] (rev 10) (prog-if 00 [VGA])
        Subsystem: VISIONTEK: Unknown device 000b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fd000000 (32-bit, non-prefetchable)
[size=16M]
        Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at feaf0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

> Secondly, a lot of the changes there are for riva128, which may not
> apply for all cards. Try doing fbset -accel false/true and see if
> there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
> and comment out the line with the FB_ACCELF_TEXT.  This should force the
> hardware to do everything in software.  

Thanks, I'll check this today.

	Miles

Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51

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

> Before, most drivers just unconditionally refresh the hardware at every
> switch  during set_var(). I've been pointing this out for a long time
> now, do we unconditionally do a check_var()/set_par() after every
> console switch, or do we rely on fbdev and X cooperating with each
> other? Or better, maybe fbcon has a way of knowing if the switch came
> from  Xfree86.

My next project is to fix this issue. I will be working on that today.

[Linux-fbdev-devel] Re: atyfb in 2.5.51

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

> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.

I agree that the design of the /dev/fbX interface is not the best.
Unfortunely we are stuck with it. Changing it would break userland apps.

> > I will have to go threw the X code to fix that :-(
>
> There is nothing to fix.  You simply must restore the video state when
> the last mmap() client goes away.  The __sparc__ code does exactly that.

I should of worded that better. Meaning I have to see what X is doing so
the fbdev driver sets the state itself better. Hm. I'm thinking about the
mmap approach versus the fb_open approach being used now.

> I think relying on an application that mmap's a card to perfectly
> restore the state would work in a perfect world, one we do not live
> in.  Furthermore, fixing up the state like I am suggesting makes life
> much simpler for people actually working on things like X servers and
> other programs directly programming the ATI chip.

:-( True. We should always assume X or any userland app could be broken.

[Linux-fbdev-devel] Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

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

> James, I appreciate all your hard work.  I hope my bug report
> isn't too upsetting for you.  I think you are making great progress.
> It is also a shame that so much of the driver porting has fallen
> on your shoulders.  If I were a programmer.  I'd help, but my skills
> are in software testing, for the most part.

Thank you :-) Its getting there.

[Linux-fbdev-devel] Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev

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

> > int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> > {
> >         int xoffset = var->xoffset;
> >         int yoffset = var->yoffset;
> >         int err;
> >
> >         if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
>
> I'm probably missing something important, but do not you want
>                                            !info->fbops->fb_pan_display
> instead?

Oops. Typo to the screen. That wasn't commited :-)

[Linux-fbdev-devel] matroxfb broken in 2.5.51 ?

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

Hello, ...

matroxfb seems broken in 2.5.51 :

  gcc -Wp,-MD,drivers/video/matrox/.matroxfb_base.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix include -DKBUILD_BASENAME=matroxfb_base -DKBUILD_MODNAME=matroxfb_base -DEXPORT_SYMTAB  -c -o drivers/video/matrox/matroxfb_base.o
  drivers/video/matrox/matroxfb_base.c
  In file included from drivers/video/matrox/matroxfb_base.c:105:
  drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or directory
  drivers/video/matrox/matroxfb_base.h:53: video/fbcon-cfb4.h: No such file or directory
  drivers/video/matrox/matroxfb_base.h:54: video/fbcon-cfb8.h: No such file or directory
  drivers/video/matrox/matroxfb_base.h:55: video/fbcon-cfb16.h: No such file or directory
  drivers/video/matrox/matroxfb_base.h:56: video/fbcon-cfb24.h: No such file or directory
  drivers/video/matrox/matroxfb_base.h:57: video/fbcon-cfb32.h: No such file or directory
  In file included from drivers/video/matrox/matroxfb_base.c:105:
  drivers/video/matrox/matroxfb_base.h:341: warning: `struct display' declared inside parameter list
  drivers/video/matrox/matroxfb_base.h:341: warning: its scope is only this definition or declaration, which is probably not what you want.

Mmm, maybe it is only because the fbcon.h and co did not get moved to
the right place or something such, will check.

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev

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

On 10 Dec 02 at 21:59, James Simmons wrote:

> Fixed. Actually I used the following code.
> 
> int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> {
>         int xoffset = var->xoffset;
>         int yoffset = var->yoffset;
>         int err;
> 
>         if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||

I'm probably missing something important, but do not you want
                                           !info->fbops->fb_pan_display
instead?
                                                            Petr
                                                                                                       
>             xoffset + info->var.xres > info->var.xres_virtual ||
>             yoffset + info->var.yres > info->var.yres_virtual)
>                 return -EINVAL;
>         if ((err = info->fbops->fb_pan_display(var, info)))
>                 return err;
>         info->var.xoffset = var->xoffset;
>         info->var.yoffset = var->yoffset;
>         if (var->vmode & FB_VMODE_YWRAP)

Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51

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

On Wed, 2002-12-11 at 04:11, Benjamin Herrenschmidt wrote:
> 
> I don't know if happened with earlier fbdev versions for you, but one
> possibility is that X reconfigures the display base, and possibly more
> bits of the card's internal memory map. Either fbdev should restore
> that, or adapt to what X set. On R128's and radeon's, this is things
> like DISPLAY_BASE_ADDR.
>  
Although this is in the faqs for a long time, (behavior is undefined if
fbdev is used with software that touches the video card) this is an
issue that needs to be taken into consideration.  Without the set_var()
hook, fbcon will depend on the contents of info->var if there is a need
to touch the hardware or not.  And switching from X to the console will
not change the var, but since X actually did touch the hardware, you
just messed up your screen or worse, crashed the hardware.

Before, most drivers just unconditionally refresh the hardware at every
switch  during set_var(). I've been pointing this out for a long time
now, do we unconditionally do a check_var()/set_par() after every
console switch, or do we rely on fbdev and X cooperating with each
other? Or better, maybe fbcon has a way of knowing if the switch came
from  Xfree86.

Tony

Re: [Linux-fbdev-devel] 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

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

On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> Hi,
> 
> I have tried getting rivafb to work in 2.5.51.  It is much better
> than before (thanks!).  It compiles and sorta works.
> 
> Here are the problems:
> 
> When I run "fbset -a 640x480", I get display that fills
> the screen and looks okay, but most of the characters are
> flipped along the vertical axis, so they are backwards, so that:
> 
> +----		    ----+
> |			|
> +---    becomes	     ---+
> |			|
> |			|
> 
What's the hardware, is it on a big endian machine? I think there's a
typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN).  This should
produce the "mirroring" effect.

Secondly, a lot of the changes there are for riva128, which may not
apply for all cards. Try doing fbset -accel false/true and see if
there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
and comment out the line with the FB_ACCELF_TEXT.  This should force the
hardware to do everything in software.  

> Also, when I boot, the penguin logo looks like it is being rendered
> in about five colors.  In addition, the text is black, except for
That's definitely a color map problem.

> the white underscore cursor, so all I can see is the cursor.
> When the gpm gets loaded, the mouse pointer, instead of showing
> a white rectangle that, when it passes over a character, shows that
> character in reverse-video, shows a colored cursor that always
> contains some character.  The character shown in the mouse cursor 
> changes when it passes over text in the window, but it never shows
> the character it is passing over.
> 
I get this with every framebuffer driver, so this is generic.

> Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
> a usable console window, but it is embedded in the larger high
> resolution display, like this:
> 
> 	+---------+----------------+
> 	|	  |		   |
> 	|	  |		   |
> 	|	  |		   |
> 	+---------+		   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	+--------------------------+
> 
> The area outside of the 640x480 boundary is filled with colored
> junk (no characters).
Because changes done via fbset are not passed to fbcon anymore.  So
you'll see the display change, but fbcon still thinks it's still on
640x480.  I guess James will add some support for that via the console.

I'll test it myself too with a riva128 PCI.

Tony

[Linux-fbdev-devel] Re: xxx_check_var

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

On Wed, 2002-12-11 at 07:32, James Simmons wrote:
> 
>  For the pmu_sleep_notifier can you pass in a specific struct fb_info or
> do you need to make a list of all of them?

So far, I need to make that list. But sooner or later, those notifiers
will go away and I'll use the PCI and/or new driver model PM features.

Ben.

[Linux-fbdev-devel] Re: atyfb in 2.5.51

[David S. M. <da...@re...>]

On Tue, 2002-12-10 at 22:18, James Simmons wrote:
> > AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> > Marc Aurele La France (maintainer of this driver) is basically allergic
> > to kernel fbdev support.
> 
> :-(

I've always stated that the whole fbdev model was flawed, it makes
basic assumptions about how a video card's memory and registers are
accessed (ie. the programming model) and many popular cards absolutely
do not fit into that model.

> I will have to go threw the X code to fix that :-(

There is nothing to fix.  You simply must restore the video state when
the last mmap() client goes away.  The __sparc__ code does exactly that.

I think relying on an application that mmap's a card to perfectly
restore the state would work in a perfect world, one we do not live
in.  Furthermore, fixing up the state like I am suggesting makes life
much simpler for people actually working on things like X servers and
other programs directly programming the ATI chip.

[Linux-fbdev-devel] [FBDEV]: Framebuffer driver for Intel 810/815 chipsets

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

James,

It seems the fbdev framework is stable enough, and already in the
development tree.  So, I'm submitting a driver for the Intel 810/815 for
review and perhaps inclusion to your tree (to get more testing), and
hopefully merge with Linus's tree.

The patch is against linux-2.5.51, but will not work yet because of 2
reasons:

1. agpgart is not working for the i810
2. support for early agp initialization needs to be added.

Once #1 is fixed, the driver should work as a module.  And once #2 gets
included, the driver can be compiled statically.  Dave Jones (thanks for
the help, by the way) has already #2 in his tree (tested and works), and
is currently working on #1 (I have a hacked version at home).

The driver should be compliant with fbdev-2.5, and should support most
if not all features that are to be expected (modularity, state saving
and restoring, full hardware support, etc).  One thing also that's very
important for many people is that the driver will work with XFree86 with
its native i810 drivers without further modification, and quite stably
too.

The patch is at
http://i810fb.sourceforge.net/linux-2.5.51-i810fb.diff.gz

Thanks,

Tony

[Linux-fbdev-devel] Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev

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

On Wed, 2002-12-11 at 10:59, James Simmons wrote:
> 
> > Here's a diff to correct several small things that escaped through the
> > cracks.
> 
> Ug. Now that a wider test base is being done and more drivers actually
> compile we are going to see more cracks.
> 
> > 1.  The YNOMOVE scrollmode for non-accelerated drivers is just very slow
> > because of a lot of block moves (leads to slow and jerky scrolling in
> > vesafb with ypanning enabled).  Depending on var->accel_flags, set the
> > scrollmode to either YREDRAW or YNOMOVE. For drivers with hardware
> > acceleration, set var->accel_flags to nonzero for max speed.
> 
I think the scrollmode is better determined on a case-to-case basis, but
the above should be a good enough differentiation.

> Thanks. I have had several emails complementing the speed improvements.
> Another speed boost will be a plus.
> 
Yes, probably not much at low pixel depths, but at high pixel depths and
resolutions, 2.5 should be much better than 2.4 (even 2-3x faster in
some cases).  And for drivers with hardware acceleration, whatever the
color depth, it will be much better because they were written
specifically for them. 

Personally, the performance gain is just a minor side-effect. The
greatest benefit in all this is the separation of the fbdev-fbcon
structure into components, where each component has a defined use and
function, and very much independent of each other.  This really makes it
easier to understand the code, port or write drivers too it, write
smaller and more efficient code, and even debug.  And you basically did
all this, so great job :-)  

 > > 2.  fb_pan_display() always returns an error.  User apps will
complain.
> 
> Fixed. Actually I used the following code.
> 
> int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> {
>         int xoffset = var->xoffset;
>         int yoffset = var->yoffset;
>         int err;
> 
>         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)
>                 return -EINVAL;
>         if ((err = info->fbops->fb_pan_display(var, info)))
>                 return err;
>         info->var.xoffset = var->xoffset;
>         info->var.yoffset = var->yoffset;
>         if (var->vmode & FB_VMODE_YWRAP)
> 
> instead. The reason is I didn't like the idea of xoffset and yoffset being
> changed even if the hardware panning function failed. Comments?
> 
Yes, I think thats better.

Tony

[Linux-fbdev-devel] Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles L. <mil...@at...>]

James, I appreciate all your hard work.  I hope my bug report
isn't too upsetting for you.  I think you are making great progress.
It is also a shame that so much of the driver porting has fallen
on your shoulders.  If I were a programmer.  I'd help, but my skills
are in software testing, for the most part.

All the best,
	Miles

James Simmons wrote:
>>I have tried getting rivafb to work in 2.5.51.  It is much better
>>than before (thanks!).  It compiles and sorta works.
> 
> 
> Ug. Now that several drivers compile now I get bug reports :-( I'm getting
> alot of positive feedback as well as one negative source.
> 
> 
>>Here are the problems:
>>
>>When I run "fbset -a 640x480", I get display that fills
>>the screen and looks okay, but most of the characters are
>>flipped along the vertical axis, so they are backwards, so that:
>>
>>+----		    ----+
>>|			|
>>+---    becomes	     ---+
>>|			|
>>|			|
> 
> 
> Okay. That is weird. I have this card so I will give it a try.
> 
> 
>>Also, when I boot, the penguin logo looks like it is being rendered
>>in about five colors.
> 
> 
> Yipes. Imageblit sounds broken.
> 
> 
>>In addition, the text is black, except for
>>the white underscore cursor, so all I can see is the cursor.
> 
> 
> I noticed this. The color palette is for some reason messed up.
> 
> 
>>When the gpm gets loaded, the mouse pointer, instead of showing
>>a white rectangle that, when it passes over a character, shows that
>>character in reverse-video, shows a colored cursor that always
>>contains some character.  The character shown in the mouse cursor
>>changes when it passes over text in the window, but it never shows
>>the character it is passing over.
> 
> 
> Same things. Color palette is messed up.
> 
> 
>>Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
>>a usable console window, but it is embedded in the larger high
>>resolution display, like this:
>>
>>	+---------+----------------+
>>	|	  |		   |
>>	|	  |		   |
>>	|	  |		   |
>>	+---------+		   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	+--------------------------+
>>
>>The area outside of the 640x480 boundary is filled with colored
>>junk (no characters).
>>
>>Any ideas?
> 
> 
> Yeap. I migrated changing the console from /dev/fb to actually using the
> tty layer. I haven't merged those changes yet but you will be able to do a
> 
> stty -f /dev/ttyX 80 col 50 row
> 
> and change the video mode.
> 
> So I didn't plan to push so soon but I kept getting emails about various
> drivers being broken. So I did this push to make more drivers work.
> Unfortuenly I sent a watered down fbcon system.
> 
> 
> 
> 
> 
>