rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Jak]

With so much good development being done on framebuffer drivers at the moment, perhaps
the following is only a temporary problem, but I hope the following report is of some use.

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

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

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

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

Now I rmmod rivafb and insmod it again :

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

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

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

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

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

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




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[James Simmons]

Can you try the latest pacth at

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




-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en

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

[Jak]

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 )
 after clearing green screen using fbset, text colours are wrong
 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 )
 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_init()
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

				Thanks,
						Jak.

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



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en

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

[Fredrik Noring]

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




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Antonino Daplas]

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




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Antonino Daplas]

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  




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Fredrik Noring]

sön 2003-01-19 klockan 16.41 skrev Antonino Daplas:
> The other patch (in reply to Jak) should hopefully fix the initial 
> 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




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Jak]

Tony,
	thanks for your patches, they have fixed most of the problems I had.
>
> Try running stty to fix your display.
>
I can't convince stty to do anything useful for me :
	do I need a specific/patched version ?
	do I need to specify anything except rows cols values ?
	how would I change the colour depth ?
	I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp,
how can I tell stty that I want to use the equivalent of the timing values of
any particular one of these 7 modes ( assuming timings are still relevant ) ?
	what was wrong with fbset which I have to keep for the forseeable
future anyway until 2.6 approaches 2.4 reliability ?
>
> 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.
>
Using your 3 recent patches together clears up the green screen problem
and text corruption as well as kobject "badness".

>  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);
>  }
>
This will normally return 1, not 0 as before. Is this intended ?




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Antonino Daplas]

On Tue, 2003-01-21 at 03:09, Jak wrote:
> Tony,
> 	thanks for your patches, they have fixed most of the problems I had.
> >
> > Try running stty to fix your display.
> >
> I can't convince stty to do anything useful for me :
> 	do I need a specific/patched version ?

No.
> 	do I need to specify anything except rows cols values ?

No.
> 	how would I change the colour depth ?

You can still use fbset :-), except that as it currently stands, it
might corrupt the display if panning is enabled.  rivafb does not
support panning at bootup so fbset is safe to use.

> 	I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp,
> how can I tell stty that I want to use the equivalent of the timing values of
> any particular one of these 7 modes ( assuming timings are still relevant ) ?

Bullseye :-) This is one of the reasons I submitted the GTF
implementation patch (It's already in fbmon.c).  The patch will compute
the modelines for you given xres, yres and your monitor's operational
limits.  It has the advantage of computing the maximum refresh rate your
monitor is capable of, and it can theoretically calculate any mode
without the use of additional entries in /etc/fb.modes.  This is ideal
for VESA GTF compliant monitors but I have tested this with old monitors
as well.

Once you have changed to an appropriate window size, you can then use
fbset to fine-tune your display timings.

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.

Once the above is done, adding support for GTF to a driver is just a
10-liner code.  I already did this for some of the drivers including
rivafb.

Of course, proprietary displays will need their own modeline formula
which, if this is the case, the driver has to add its own algorithm or
use fbset tricks.  You can do something like this:

fbset 1600x1200-85 && stty cols 200 rows 75
 
> 	what was wrong with fbset which I have to keep for the forseeable
> future anyway until 2.6 approaches 2.4 reliability ?

Nothing's wrong with fbset, because if fbset becomes unusable, then so
will most fbdev-based applications.  We don't want that to happen.

The main difference is instead of fbdev telling the console to change
the window size, it's now the console telling fbdev to change the window
size.  As the console is blind to color depth, pixelformat, accel, etc,
you can still use fbset to change most of the above.

> >
> > 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.
> >
> Using your 3 recent patches together clears up the green screen problem
> and text corruption as well as kobject "badness".
> 
> >  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);
> >  }
> >
> This will normally return 1, not 0 as before. Is this intended ?

The above should return 0 if successful.


Tony




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Antonino Daplas]

On Tue, 2003-01-21 at 03:09, Jak wrote:
> 
> >  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);
> >  }
> >

Hmm, come to think of it, pci_module_init() is old-style.  Using

return (pci_register_driver(&rivafb_driver) > 0) ? 0 : -ENODEV;

instead is better and will allow the rivafb driver to appear in sysfs.
Anyway, pci_module_init() should not be called since
pci_register_driver() already does that for you.  That's what causing
the "Badness" in kobject.

Tony





-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

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

[Geert Uytterhoeven]

On 21 Jan 2003, Antonino Daplas 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.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[Antonino Daplas]

On Tue, 2003-01-21 at 18:29, Geert Uytterhoeven wrote:
> On 21 Jan 2003, Antonino Daplas 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.
> 

True, but I prefer having the monitor limits at driver load time so I
can immediately go into a high resolution.

Tony




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[James Simmons]

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

rmmod is really broken for fbcon. It shuts down the VT console system. It 
needs work in this area.




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[James Simmons]

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[James Simmons]

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[Antonino Daplas]

On Sat, 2003-01-25 at 17:00, Geert Uytterhoeven wrote:
> 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?
> 

From what I understand about sysfs, you can only have one type per file,
so each field will have to be in separate files.  To synchronize, we can
perhaps use a file ('sync', 'lock', 'update' or whatever) which is
similar in function to fb_var_screeninfo.activate. Only when the user
writes to this file that the new settings are synchronized and we call
fb_set_var() or whatever.

How do you think sysfs support will be written?  Will this mean that the
framebuffer system has to register its own kobject as the top level
entry in sysfs, no?  This would also mean that we need something similar
for the console subsystem if it has to support additional features, ie
rotation?

Tony




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[Antonino Daplas]

On Sat, 2003-01-25 at 04:14, James Simmons wrote:
> 
> 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.
> 

I haven't tried this yet, but I think it will work.  The only (very
minor) problem with this is the rivafb's printk output will be incorrect
(no info on video memory size).  

Tony



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

[James Simmons]

> >From what I understand about sysfs, you can only have one type per file,
> so each field will have to be in separate files.  

Correct.

> To synchronize, we can
> perhaps use a file ('sync', 'lock', 'update' or whatever) which is
> similar in function to fb_var_screeninfo.activate. Only when the user
> writes to this file that the new settings are synchronized and we call
> fb_set_var() or whatever.

This doesn't bother me. I cna live with that. Actually it is a good idea 
to do it that way. THis way if we have graphics clients we can invalidate 
them when switch the entire graphics state. The accel engine will switch 
behavior on changing the video mode.

> How do you think sysfs support will be written?  Will this mean that the
> framebuffer system has to register its own kobject as the top level
> entry in sysfs, no?  

I think so. I haven't looked down this aveue yet. This is a latter time 
project.

> This would also mean that we need something similar
> for the console subsystem if it has to support additional features, ie
> rotation?

I'm not to thrilled about this idea.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

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

[James Simmons]

> > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it 
> > works.
> > 
> 
> I haven't tried this yet, but I think it will work.  The only (very
> minor) problem with this is the rivafb's printk output will be incorrect
> (no info on video memory size).  

True. All to keep in sync with X :-( Maybe we should break nv_driver.c 
syncing since it already has been altered. Hell with it. Could you update 
a patch with seperate functions for memsize clock finding.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

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

[Antonino Daplas]

On Thu, 2003-02-13 at 04:15, James Simmons wrote:
> 
> > > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it 
> > > works.
> > > 
> > 
> > I haven't tried this yet, but I think it will work.  The only (very
> > minor) problem with this is the rivafb's printk output will be incorrect
> > (no info on video memory size).  
> 
> True. All to keep in sync with X :-( Maybe we should break nv_driver.c 
> syncing since it already has been altered. Hell with it. Could you update 
> a patch with seperate functions for memsize clock finding.
> 

Will do once you provide an updated patch I can diff against.  

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf