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

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

> Are there any plans on merging DirectFB features? Stuff like vertical
> retrace interrupts etc.?

Thats already supported. Just add a poll function to fb_ops. To date no 
one has used this feature.

Re: [Linux-fbdev-devel] [PATCH] Funny sync calculation correction

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

> > Works fine. I applied it to the 2.5.X tree.
> 
> Has anyone got Riva 128 or TNT cards working with 2.5.59 or
> later? My cards freeze up completely with the new driver when
> loading fbcon.

The card I have is a Diamond Multimedia Systems Viper V730.

[Linux-fbdev-devel] Framebuffer overflow halts network (fwd)

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

---------- Forwarded message ----------
Date: Mon, 27 Jan 2003 21:44:13 +0100
From: Leif Neland <le...@ne...>
To: ge...@li...
Subject: Framebuffer overflow halts network

Sorry to bother you "privately", but I can't find much info of the use of
framebuffer after it is installed.

I have set up my primary work machine (i.e. it is mostly used as a terminal
to connect to other servers) with framebuffer and have 64 lines*160 chars in
a pretty font.

I ssh to other servers from this machine.

If I do something which create a lot of output, eg. ls -lR /, the remote
machine sends more data than the framebuffer-terminal can handle. This
blocks the network on the terminal machine, which also is nameserver,
internal webserver and upsd server.

Is it possible to set up some sort of flow control, so the remote machine
stops when the terminal is overloaded?

Both servers are 100Mb, on different switches, which are connected at 100Mb
The terminal is on a Cisco, the other on a cheaper 24ports switch.

If you can't help me, can you direct me in the proper direction?

Leif

[Linux-fbdev-devel] [PATCH] Fix for wasted memory in rivafb?

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

This patch fixes a problem with wasted memory in the rivafb driver.
For some reason, only half the memory is currently allowed when 
maximizing the virtual screen. The 2.5.x tree has the same problem.

Is this a reserve for something? I have not found any use for it 
inside the driver.

My app needs all the precious video memory it can get. :)

	Fredrik

--- linux-2.4.21-pre2/drivers/video/riva/fbdev.c.orig	2003-01-27 00:06:19.000000000 +0100
+++ linux-2.4.21-pre2/drivers/video/riva/fbdev.c	2003-01-26 21:28:04.000000000 +0100
@@ -1063,7 +1063,7 @@
 		       "using maximum available virtual resolution\n");
 		for (i = 0; modes[i].xres != -1; i++) {
 			if (modes[i].xres * nom / den * modes[i].yres <
-			    rinfo->ram_amount / 2)
+			    rinfo->ram_amount)
 				break;
 		}
 		if (modes[i].xres == -1) {
@@ -1080,13 +1080,13 @@
 		       v->xres_virtual, v->yres_virtual);
 	} else if (v->xres_virtual == -1) {
 		v->xres_virtual = (rinfo->ram_amount * den /
-			(nom * v->yres_virtual * 2)) & ~15;
+			(nom * v->yres_virtual)) & ~15;
 		printk(KERN_WARNING PFX
 		       "setting virtual X resolution to %d\n", v->xres_virtual);
 	} else if (v->yres_virtual == -1) {
 		v->xres_virtual = (v->xres_virtual + 15) & ~15;
 		v->yres_virtual = rinfo->ram_amount * den /
-			(nom * v->xres_virtual * 2);
+			(nom * v->xres_virtual);
 		printk(KERN_WARNING PFX
 		       "setting virtual Y resolution to %d\n", v->yres_virtual);
 	} else {

Re: [Linux-fbdev-devel] Re: ati radeon specs

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

--- Luismi <lui...@er...> wrote:
> > the ati specs. Somebody has them or where can I
> find them?
> > 
You need to register with ATI:

http://apps.ati.com/developers/devform1.asp

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

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

[Linux-fbdev-devel] Re: ati radeon specs

[Luismi <lui...@er...>]

 Sorry for all these mails, i've had some problems with my mail
 server...

 "PS: fucking eresmas ...

> 	Hi, I've tried several radeonfb versions on a laptop with an 'ati
> radeon mobility M6 LY', and all of them have the same problem,
> sometimes appear several horizontal lines when changing the
> resolution.
> 
> 	I've been reading the 'linux framebuffer driver writing howto'
> and I want to learn about driver programming.
> 
> 	I'm thinking about doing it myself for this videocard, and
> help to radeonfb developing if it is possible, but I need
> the ati specs. Somebody has them or where can I find them?
> 
> 	Thanks.
> 				

[Linux-fbdev-devel] aty radeon specs

[Luismi <lui...@er...>]

	Hi, I've tried several radeonfb versions on a laptop with an 'ati
radeon mobility M6 LY', and all of them have the same problem,
sometimes appear several horizontal lines when changing the
resolution.

	I've been reading the 'linux framebuffer driver writing howto'
and I want to learn about driver programming.

	I'm thinking about doing it myself for this videocard, and
help to radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

	Thanks.
				

[Linux-fbdev-devel] ati radeon specs

[Luismi <lui...@er...>]

    Hi, I've tried several radeonfb versions on a laptop with an 'ati 
radeon mobility M6 LY', and all of them have the same problem, sometimes 
appear several horizontal lines when changing the resolution.

    I've been reading the 'linux framebuffer driver writing howto' and I 
want to learn about driver programming.

    I'm thinking about doing it myself for this videocard, and help to 
radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

Thanks.

[Linux-fbdev-devel] aty radeon specs

[Luismi <lui...@er...>]

    Hi, I've tried several radeonfb versions on a laptop with an 'ati 
radeon mobility M6 LY', and all of them have the same problem, sometimes 
appear several horizontal lines when changing the resolution.

    I've been reading the 'linux framebuffer driver writing howto' and I 
want to learn about driver programming.

    I'm thinking about doing it myself for this videocard, and help to 
radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

Thanks.

[Linux-fbdev-devel] aty radeon specs

[Luismi <lui...@er...>]

    Hi, I've tried several radeonfb versions on a laptop with an 'ati 
radeon mobility M6 LY', and all of them have the same problem, sometimes 
appear several horizontal lines when changing the resolution.

    I've been reading the 'linux framebuffer driver writing howto' and I 
want to learn about driver programming.

    I'm thinking about doing it myself for this videocard, and help to 
radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

Thanks.

[Linux-fbdev-devel] aty radeon specs

[Luismi <lui...@er...>]

    Hi, I've tried several radeonfb versions on a laptop with an 'ati 
radeon mobility M6 LY', and all of them have the same problem, sometimes 
appear several horizontal lines when changing the resolution.

    I've been reading the 'linux framebuffer driver writing howto' and I 
want to learn about driver programming.

    I'm thinking about doing it myself for this videocard, and help to 
radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

Thanks.

[Linux-fbdev-devel] aty radeon specs

[Luismi <lui...@er...>]

	Hi, I've tried several radeonfb versions on a laptop with an 'ati 
radeon mobility M6 LY', and all of them have the same problem, sometimes 
appear several horizontal lines when changing the resolution.

	I've been reading the 'linux framebuffer driver writing howto' and I 
want to learn about driver programming.

	I'm thinking about doing it myself for this videocard, and help to 
radeonfb developing if it is possible, but I need
the ati specs. Somebody has them or where can I find them?

Thanks.

[Linux-fbdev-devel] Vertical retrace interrupts?

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

Hi,

Are there any plans on merging DirectFB features? Stuff like vertical
retrace interrupts etc.?

	Fredrik

Re: [Linux-fbdev-devel] [PATCH] Funny sync calculation correction

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

> Works fine. I applied it to the 2.5.X tree.

Has anyone got Riva 128 or TNT cards working with 2.5.59 or
later? My cards freeze up completely with the new driver when
loading fbcon.

	Fredrik

[Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

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

Attached patch implements interlace for the rivafb driver and
the hardware that supports it (Riva 128, TNT, TNT2, some GeForce 
cards and possibly others).

It's a patch against 2.4.21-pre2 (with polarity and sync patches)
but it should fit with 2.5.x too skipping riva_hw.c and riva_hw.h 
which already are adopted from XFree86.

	Fredrik


--- linux-2.4.21-pre2/drivers/video/riva/riva_hw.c.orig	2003-01-25 00:36:10.000000000 +0100
+++ linux-2.4.21-pre2/drivers/video/riva/riva_hw.c	2003-01-25 00:38:14.000000000 +0100
@@ -1547,6 +1547,8 @@
     VGA_WR08(chip->PCIO, 0x03D5, state->cursor0);
     VGA_WR08(chip->PCIO, 0x03D4, 0x31);
     VGA_WR08(chip->PCIO, 0x03D5, state->cursor1);
+    VGA_WR08(chip->PCIO, 0x03D4, 0x39);
+    VGA_WR08(chip->PCIO, 0x03D5, state->interlace);
     chip->PRAMDAC[0x00000300/4]  = state->cursor2;
     chip->PRAMDAC[0x00000508/4]  = state->vpll;
     chip->PRAMDAC[0x0000050C/4]  = state->pllsel;
--- linux-2.4.21-pre2/drivers/video/riva/riva_hw.h.orig	2003-01-25 00:36:15.000000000 +0100
+++ linux-2.4.21-pre2/drivers/video/riva/riva_hw.h	2003-01-25 00:38:49.000000000 +0100
@@ -421,6 +421,7 @@
     U032 bpp;
     U032 width;
     U032 height;
+    U032 interlace;
     U032 repaint0;
     U032 repaint1;
     U032 screen;
--- linux-2.4.21-pre2/drivers/video/riva/fbdev.c.orig	2003-01-25 23:41:18.000000000 +0100
+++ linux-2.4.21-pre2/drivers/video/riva/fbdev.c	2003-01-25 23:45:07.000000000 +0100
@@ -14,6 +14,9 @@
  *
  *	Jindrich Makovicka:  Accel code help, hw cursor, mtrr
  *
+ *	Fredrik Noring <no...@no...>:  Sync polarity and
+ *	interlace code with XFree86 4.2 as reference.
+ *
  * Initial template from skeletonfb.c, created 28 Dec 1997 by Geert Uytterhoeven
  * Includes riva_hw.c from nVidia, see copyright below.
  * KGI code provided the basis for state storage, init, and mode switching.
@@ -26,6 +29,12 @@
  *	restoring text mode fails
  *	doublescan modes are broken
  *	option 'noaccel' has no effect
+ *
+ * Interlace is supported on Riva 128, TNT, TNT2 and some early
+ * GeForce cards. Many newer cards do not support interlace.
+ *
+ * Interlace and hardware accelerated video overlay are not compatible
+ * (likely a limitation in hardware).
  */
 
 #include <linux/config.h>
@@ -890,6 +899,9 @@
 
 	memcpy(&newmode, &reg_template, sizeof(struct riva_regs));
 
+	if((video_mode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED) 
+		vTotal |= 1;
+
 	newmode.crtc[0x0] = Set8Bits (hTotal - 4);
 	newmode.crtc[0x1] = Set8Bits (hDisplay);
 	newmode.crtc[0x2] = Set8Bits (hDisplay);
@@ -929,6 +941,15 @@
 	else
 		newmode.misc_output |= 0x80;
 	
+	if((video_mode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED)
+	{
+	        int tmp = (hTotal >> 1) & ~1;
+		newmode.ext.interlace = Set8Bits(tmp);
+		newmode.ext.horiz |= SetBitField(tmp, 8:8,4:4);
+	} else {
+		newmode.ext.interlace = 0xff;  /* interlace off */
+	}
+
 	rinfo->riva.CalcStateExt(&rinfo->riva, &newmode.ext, bpp, width,
 				  hDisplaySize, hDisplay, hStart, hEnd,
 				  hTotal, height, vDisplay, vStart, vEnd,

Re: [Linux-fbdev-devel] [PATCH] Funny sync calculation correction

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

> I've been digging around in the rivafb module to find out why some
> modes converted from XFree86 4.2 don't work on some display devices.
> Here's a funny part of the riva_load_video_mode function (Linux
> 2.4.21-pre2):
> 
> 	hStart = (hDisplaySize + video_mode->right_margin) / 8 + 2;
> 	hEnd   = (hDisplaySize + video_mode->right_margin +
> 		 video_mode->hsync_len) / 8 - 1;
> 
> Please notice how "hsync_len" does not actually represent the length
> of the sync. Rather, it's compensated with 24 pixels. The corresponding
> code in the XFree86 4.2 (nv_dac.c) contains no such compensation:
> 
>     int horizStart      = (mode->CrtcHSyncStart/8) - 1;
>     int horizEnd        = (mode->CrtcHSyncEnd/8)   - 1;
> 
> The difference seems to be almost insignificant for modern multisync
> screens, but devices such as TV:s get confused by the current version.
> Is there a reason for the difference in calculations?
> 
> The attached patch corrects the calculations in accordance with XFree86
> and works better with the modelines I've tested. 
> 
> Please give it a try. Thanks,

Works fine. I applied it to the 2.5.X tree.

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

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

On Fri, Jan 24, 2003 at 10:59:05PM +0000, James Simmons wrote:
> 
> >   3) Are the 2.5.x kernel working on powerpc, and if yes, is the
> >   radeonfb driver ported ?
> 
> Yes and yes to the last time I checked. 

:)))

Now, i only need that the POP patches are ported to 2.5.x.

Friendly,

Sven Luther

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

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

On Fri, 24 Jan 2003, James Simmons wrote:
> > > The only problem right now is how do you pass the monitor info to the
> > > driver?  The best way is to parse the EDID block and use I2C/DDC. 
> > > Personally, I think passing the monitor info as a boot/module option is
> > > the simplest and safest method.
> > 
> > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?
> > 
> > Since ioctls are considered evil these days, changing the resolution etc. could
> > work in a similar way as well.
> 
> Can you do this with sysfs? This is what I have been waiting for!!! The 
> proc thing is don't care for tho.

Yes, you can create a fbdev filesystem, which shows frame buffers and
information about them. By changing the contents of those virtual files (e.g. a
file that corresponds to struct fb_var_screeninfo), you can change the video
mode.  This can also solve the burden of maintaining backwards compatibility in
struct fb_var_screeninfo. You want a new field? Just add a new virtual file to
the filesystem.

One thing I'm still wondering about is how to keep things synchronized. You
don't want to put all fields of struct fb_var_screeninfo in one file, you want
separate files for resolution, timings, .... But in the end you usually want to
change a video mode by changing all parameters at once, so you want the changes
to the different virtual files to be synchronized. Perhaps some lock file?

Gr{oetje,eeting}s,

						Geert

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

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

[Linux-fbdev-devel] [PATCH] Funny sync calculation correction

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

I've been digging around in the rivafb module to find out why some
modes converted from XFree86 4.2 don't work on some display devices.
Here's a funny part of the riva_load_video_mode function (Linux
2.4.21-pre2):

	hStart = (hDisplaySize + video_mode->right_margin) / 8 + 2;
	hEnd   = (hDisplaySize + video_mode->right_margin +
		 video_mode->hsync_len) / 8 - 1;

Please notice how "hsync_len" does not actually represent the length
of the sync. Rather, it's compensated with 24 pixels. The corresponding
code in the XFree86 4.2 (nv_dac.c) contains no such compensation:

    int horizStart      = (mode->CrtcHSyncStart/8) - 1;
    int horizEnd        = (mode->CrtcHSyncEnd/8)   - 1;

The difference seems to be almost insignificant for modern multisync
screens, but devices such as TV:s get confused by the current version.
Is there a reason for the difference in calculations?

The attached patch corrects the calculations in accordance with XFree86
and works better with the modelines I've tested. 

Please give it a try. Thanks,

	Fredrik

--- linux-2.4.21-pre2/drivers/video/riva/fbdev.c.orig	2003-01-24 23:59:56.000000000 +0100
+++ linux-2.4.21-pre2/drivers/video/riva/fbdev.c	2003-01-25 00:00:24.000000000 +0100
@@ -874,7 +874,7 @@
 	width = video_mode->xres_virtual;
 	hDisplaySize = video_mode->xres;
 	hDisplay = (hDisplaySize / 8) - 1;
-	hStart = (hDisplaySize + video_mode->right_margin) / 8 + 2;
+	hStart = (hDisplaySize + video_mode->right_margin) / 8 - 1;
 	hEnd = (hDisplaySize + video_mode->right_margin +
 		video_mode->hsync_len) / 8 - 1;
 	hTotal = (hDisplaySize + video_mode->right_margin +

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

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

>   3) Are the 2.5.x kernel working on powerpc, and if yes, is the
>   radeonfb driver ported ?

Yes and yes to the last time I checked. 

Re: [Linux-fbdev-devel] Some small problems...

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

> 1. When compiling, the following framebuffer devices does not compile :
> 	- Cirrus Logic
> 	- Matrox
> 	- Riva (had some warnings)
> 	- Ati (Had to do some small hack in aty_base.c to get this compiling)

Ati didn't compile? Do you have a patch I could apply.

Riva is starting to shape up. The Cirrus Logic and Matrox driver haven't 
been ported yet. The good news is I'm working on the matrox driver. I have 
alot to go tho for it.
 
> 2. When I'm doing make modules_install everything stops. This I got

Yeah the module stuff changed.

> 3. When the compiling sequence is finished, and it is time for reboot,
> there is no output on the screen after the grub startup manager.

DId you framebuffer console?

> 4. Are there a list of framebuffer drivers that are verified on the
> 2.5.59 kernel ?

No but most do work.

SHould work. been ported.
> - ATI Rage Pro 3D (AGP)
> - Nvidia Geforce 2 (PCI)
> - Nvidia TNT 2 (PCI)

WOrking on port.
> - Matrox Millenium II (PCI)

Driver way out of date and only works on m68k.
> - Herkules S3virge (PCI)

Needs to be ported.
> - Cirrus Logic GD5434-8 (PCI)

Driver is starting to work.
> - Nvidia Geforce 4 MX420 (AGP)
> - Nvidia Geforce 2 (PCI)
> - Nvidia TNT 2 (PCI)

Same as above.
> - Matrox Millenium II (PCI)
> - Herkules S3virge (PCI)
> - Cirrus Logic GD5434-8 (PCI)

Works.
> Machine #3:
> - Pentium 4, 2,4GHz, 256Mb
> - ATI Radeon Mobility M6

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

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

> > The only problem right now is how do you pass the monitor info to the
> > driver?  The best way is to parse the EDID block and use I2C/DDC. 
> > Personally, I think passing the monitor info as a boot/module option is
> > the simplest and safest method.
> 
> Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?
> 
> Since ioctls are considered evil these days, changing the resolution etc. could
> work in a similar way as well.

Can you do this with sysfs? This is what I have been waiting for!!! The 
proc thing is don't care for tho.

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

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

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

We should move the riva_load_state(par->initial_state) in riavfb_remove to 
rivafb_release. 
 
> >  rmmod fbcon locks up machine, no ALT-SYSRQ effective
> This is wishful thinking :-), as fbcon cannot be unloaded (yet). 

It works if you have more than one type of VT console system. I use MDA 
console with FB console. This way I can add and remove fbcon.o at will and 
test it in detail.

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

I applied part of the patch. I like to avoid changing nv_driver to much 
because it is based on the X windows driver. Easier to keep them sync. 
What we could do is move the following 

riva_common_setup(par);
..

par->dclk_max = par->riva.MaxVClock..

from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it 
works.

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

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

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

Applied. I'm about to test these new patches.

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

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

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

Applied.