From: David L. <lio...@co...> - 2004-11-05 10:21:31
|
On the 2.6.9 kernel on Debian sid, rivafb loads successfully: ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 rivafb: nVidia device/chipset 10DE0176 rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M] rivafb: flatpanel support enabled rivafb: Detected CRTC controller 1 being used rivafb: RIVA MTRR set to ON rivafb: could not retrieve EDID from DDC/I2C rivafb: setting virtual Y resolution to 52428 rivafb: Detected CRTC controller 1 being used rivafb: Detected CRTC controller 1 being used Console: switching to colour frame buffer device 80x30 rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000) Along with rivafb, these modules load: Module Size Used by rivafb 49924 1 i2c_algo_bit 8968 1 rivafb vgastate 9472 1 rivafb cfbimgblt 2944 1 rivafb i2c_core 19088 2 rivafb,i2c_algo_bit As long as the proprietary nvidia kernel module is not loaded, this works fine. However, I'm only getting 640x480. My /etc/fb.modes has lots of other resolutions, but they're not accepted. Is this a limitation of the rivafb driver, my hardware, or something else? vesafb won't load at all. I run thermoman's lilo, which shows an animated scene -- flying penguins and so on -- in full screen, so I'm disappointed that I get better framebuffer support in lilo than in the OS! Can anyone suggest how to get a full screen after boot? X11 uses 1280x854. Please cc me, I'm not subscribed. Cheers, Dave |
From: Antonino A. D. <ad...@ho...> - 2004-11-05 13:15:33
|
On Friday 05 November 2004 18:21, David Liontooth wrote: > On the 2.6.9 kernel on Debian sid, rivafb loads successfully: > > ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 > rivafb: nVidia device/chipset 10DE0176 > rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M] > rivafb: flatpanel support enabled > rivafb: Detected CRTC controller 1 being used > rivafb: RIVA MTRR set to ON > rivafb: could not retrieve EDID from DDC/I2C > rivafb: setting virtual Y resolution to 52428 > rivafb: Detected CRTC controller 1 being used > rivafb: Detected CRTC controller 1 being used > Console: switching to colour frame buffer device 80x30 > rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000) > > Along with rivafb, these modules load: > > Module Size Used by > rivafb 49924 1 > i2c_algo_bit 8968 1 rivafb > vgastate 9472 1 rivafb > cfbimgblt 2944 1 rivafb > i2c_core 19088 2 rivafb,i2c_algo_bit > > As long as the proprietary nvidia kernel module is not loaded, this works > fine. > > However, I'm only getting 640x480. My /etc/fb.modes has lots of other > resolutions, but they're not accepted. > > Is this a limitation of the rivafb driver, my hardware, or something else? Nope, it's a bug in the rivafb driver when the EDID block cannot be accessed. I can't submit a patch right now, but I'll give instructions on how to fix this: 1. open drivers/video/riva/fbdev.c 2. search for the function "static int __devinit rivafb_probe". 3. Somewhere near the end you should see these lines: fb_destroy_modedb(info->monspecs.modedb); info->monspecs.modedb_len = 0; info->monspecs.modedb = NULL; 4. Remove the line "info->monspecs.modedb_len = 0" 5. Next, search for the function "static int rivafb_check_var" 6. Look for these lines: if (!mode_valid && !list_empty(&info->modelist)) return -EINVAL; 7. Change it so it becomes like this: if (!mode_valid && !info->monspecs.modedb_len) return -EINVAL; 8. Recompile and reboot. The end effect is rivafb will accept all modelines coming from fbset as gospel truth. Tony |
From: Antonino A. D. <ad...@ho...> - 2004-11-05 13:25:04
|
On Friday 05 November 2004 21:15, Antonino A. Daplas wrote: > 7. Change it so it becomes like this: > > if (!mode_valid && !info->monspecs.modedb_len) > return -EINVAL; > Oops. This should be: if (!mode_valid && info->monspecs.modedb_len) return -EINVAL; (No exclamation mark(!)) Tony |
From: David L. <lio...@co...> - 2004-11-09 03:40:20
|
Antonino A. Daplas wrote: >On Friday 05 November 2004 18:21, David Liontooth wrote: > > >>On the 2.6.9 kernel on Debian sid, rivafb loads successfully: >> >>ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 >>rivafb: nVidia device/chipset 10DE0176 >>rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M] >>rivafb: flatpanel support enabled >>rivafb: Detected CRTC controller 1 being used >>rivafb: RIVA MTRR set to ON >>rivafb: could not retrieve EDID from DDC/I2C >>rivafb: setting virtual Y resolution to 52428 >>rivafb: Detected CRTC controller 1 being used >>rivafb: Detected CRTC controller 1 being used >>Console: switching to colour frame buffer device 80x30 >>rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000) >> >>Along with rivafb, these modules load: >> >>Module Size Used by >>rivafb 49924 1 >>i2c_algo_bit 8968 1 rivafb >>vgastate 9472 1 rivafb >>cfbimgblt 2944 1 rivafb >>i2c_core 19088 2 rivafb,i2c_algo_bit >> >>As long as the proprietary nvidia kernel module is not loaded, this works >>fine. >> >>However, I'm only getting 640x480. My /etc/fb.modes has lots of other >>resolutions, but they're not accepted. >> >>Is this a limitation of the rivafb driver, my hardware, or something else? >> >> > >Nope, it's a bug in the rivafb driver when the EDID block cannot be accessed. > >I can't submit a patch right now, but I'll give instructions on how to fix this: > >1. open drivers/video/riva/fbdev.c >2. search for the function "static int __devinit rivafb_probe". >3. Somewhere near the end you should see these lines: > > fb_destroy_modedb(info->monspecs.modedb); > info->monspecs.modedb_len = 0; > info->monspecs.modedb = NULL; > >4. Remove the line "info->monspecs.modedb_len = 0" >5. Next, search for the function "static int rivafb_check_var" >6. Look for these lines: > > if (!mode_valid && !list_empty(&info->modelist)) > return -EINVAL; > >7. Change it so it becomes like this: > > if (!mode_valid && info->monspecs.modedb_len) > return -EINVAL; > >8. Recompile and reboot. The end effect is rivafb will accept >all modelines coming from fbset as gospel truth. > >Tony > > > > Hi Tony, Thank you! That did the trick. I now have a framebuffer of any size, including my 1280x854 monitor. How do I generate new entries for /etc/fb.modes? I know the 1280x854 entry I use is slightly wrong, but evidently not wrong enough to cause problems, and a 720x480 entry I tried to create failed. I'm now able to run slideshows using fbi, and the results are excellent! I also tried to play videos, and fbxine will play stuff, the sound is fine, the speed is correct, but the colors are all swapped. Is there anything I can do? I also tried mplayer -vo fbdev, but that didn't work -- it looks like mplayer tries to scale the framebuffer to the size of the movie and fails if that size is not available. This is very cool and I really appreciate your patch. It would be great to have this in the kernel. Cheers, David |
From: Antonino A. D. <ad...@ho...> - 2004-11-09 05:12:48
|
On Tuesday 09 November 2004 11:26, David Liontooth wrote: > Antonino A. Daplas wrote: > >On Friday 05 November 2004 18:21, David Liontooth wrote: > > Hi Tony, > > Thank you! That did the trick. I now have a framebuffer of any size, > including my 1280x854 monitor. > How do I generate new entries for /etc/fb.modes? I know the 1280x854 > entry I use is slightly wrong, If you have sample XFree86 modelines, you can use the utility modeline2fb to convert them to entries compatible with /etc/fb.modes. Or you can use the VESA GTF (Generalized Timing Formula). There are several utilities as well as online calculators that will generate mode timings for you based on the GTF. You can easily do a google search for both of them. > but evidently not wrong enough to cause problems, and a 720x480 entry I > tried to create failed. > > I'm now able to run slideshows using fbi, and the results are excellent! > I also tried to play videos, > and fbxine will play stuff, the sound is fine, the speed is correct, but > the colors are all swapped. Is The rivafb driver uses DirectColor and several applications have difficulties with this mode since they assume that Truecolor and Directcolor are the same. (Most applications are used to Truecolor). If I have time, I'll see what's wrong with fbxine. > there anything I can do? I also tried mplayer -vo fbdev, but that didn't > work -- it looks like mplayer > tries to scale the framebuffer to the size of the movie and fails if > that size is not available. I get the same thing to, not just rivafb. Similarly, once I have time, I'll try to examine this. > > This is very cool and I really appreciate your patch. It would be great > to have this in the kernel. I already submitted the patch. Tony |
From: David L. <lio...@co...> - 2004-11-09 20:30:24
|
Antonino A. Daplas wrote: > If you have sample XFree86 modelines, you can use the utility > >modeline2fb to convert them to entries compatible with /etc/fb.modes. > > Got it -- in Debian, it's part of the fbset package. >If I have time, I'll see what's wrong with fbxine. > > That would be awesome -- the ability to play movies in the framebuffer was the first reason I wanted it, since it would drain the batteries less than running movies in KDE. For some reason, fbxine has stopped working altogether -- I've tried to reconstruct the environment in which it worked, but now it just displays the previous console page and exits. fbi works great -- slideshows, autoscaling, rotation, the works. I'll test mplayer again too -- it sounds like this may be an mplayer problem. The main remaining annoyance is that you can't remove the rivafb module, so you have to reboot to let the nv or nvidia module take over. Cheers, Dave |
From: Antonino A. D. <ad...@ho...> - 2004-11-11 02:43:21
|
On Wednesday 10 November 2004 04:29, David Liontooth wrote: > Antonino A. Daplas wrote: > > If you have sample XFree86 modelines, you can use the utility > > > >modeline2fb to convert them to entries compatible with /etc/fb.modes. > > Got it -- in Debian, it's part of the fbset package. > > >If I have time, I'll see what's wrong with fbxine. > > That would be awesome -- the ability to play movies in the framebuffer > was the first reason I wanted it, since it would drain the batteries less > than running movies in KDE. > > For some reason, fbxine has stopped working altogether -- I've tried to > reconstruct > the environment in which it worked, but now it just displays the > previous console > page and exits. fbi works great -- slideshows, autoscaling, rotation, > the works. > > I'll test mplayer again too -- it sounds like this may be an mplayer > problem. > > The main remaining annoyance is that you can't remove the rivafb module, You can actually, as long as you don't enable the framebuffer console. This sequence should work: modprobe rivafb mplayer -vo directfb rmmod rivafb Of course you will only have a vga console. > so you > have to reboot to let the nv or nvidia module take over. The rivafb driver and nv should nicely coexist. The nvidia driver is still not compatible with rivafb. Tony |
From: David L. <lio...@co...> - 2004-11-12 00:02:48
|
Hi Tony, The directfb works great -- I can now play movies in the framebuffer and the quality is as good as in x-windows (even though my fb.mode has a depth of 8). CPU usage is below 50% (and that is running the CPU at half speed using cpufreq), while in X it's around 75%. Very cool actually. A quirk in the framebuffer: if I touch the mouse while playing a movie with mplayer, everything freezes and I have to hardboot. I can't even ssh into the machine. I wanted the mousewheel as a way of fast forwarding in the movie. I'm also wondering if it's possible to tell the rivafb module to use the right mode when loading -- at the moment it loads into 640x480 and then I use fbset to change it to 1280x854. Here's the first entry in my /etc/fb.modes: # # Sample video modes # # Generated using modeline2fb, 1280x854, 85.266 MHz dotclock mode "fullscreen" geometry 1280 854 1280 26201 8 timings 11728 240 16 31 0 256 7 hsync low vsync low endmode The module doesn't seem to accept mode parameters, however. >>The main remaining annoyance is that you can't remove the rivafb module, >> >> >You can actually, as long as you don't enable the framebuffer console. This >sequence should work: > >modprobe rivafb >mplayer -vo directfb >rmmod rivafb > >Of course you will only have a vga console. > > Not sure I understand -- you don't mean I can insert rivafb while the nvidia module is still inserted? In that case I get this: ---------------------- DirectFB v0.9.20 --------------------- (c) 2000-2002 convergence integrated media GmbH (c) 2002-2003 convergence GmbH ----------------------------------------------------------- (*) Single Application Core. (with MMX support) (2004-01-20 10:18) (*) DirectFB/misc/memcpy: using MMXEXT optimized memcpy() (!) DirectFB/core/fbdev: Error opening `/dev/fb0'! --> No such device (!) DirectFB/Core: Could not initialize 'system' core! --> Not supported! (!) DirectFB/Core: Error during initialization (Not supported!) vo_directfb2.c <315>: (#) DirectFBError [DirectFBCreate (&dfb)]: Not supported! Not surprising, right? The framebuffer device /dev/fb0 is not created. So what does it mean to use directfb without enabling the framebuffer console? >The rivafb driver and nv should nicely coexist. The nvidia driver is still >not compatible with rivafb. > > Good point, I'll try that. Cheers, Dave |
From: Antonino A. D. <ad...@ho...> - 2004-11-12 06:21:58
|
On Friday 12 November 2004 08:02, David Liontooth wrote: > Hi Tony, > > The directfb works great -- I can now play movies in the framebuffer > and the quality is as good as in x-windows (even though my fb.mode > has a depth of 8). CPU usage is below 50% (and that is running the > CPU at half speed using cpufreq), while in X it's around 75%. Very > cool actually. > > A quirk in the framebuffer: if I touch the mouse while playing a movie > with mplayer, everything freezes and I have to hardboot. I can't even > ssh into the machine. I wanted the mousewheel as a way of fast > forwarding in the movie. It's possible that this might be fixed in the latest mm kernel, if the bug is indeed in the kernel framebuffer. Otherwise, the bug can be part of DirectFB itself. > > I'm also wondering if it's possible to tell the rivafb module to use > the right mode when loading -- at the moment it loads into 640x480 > and then I use fbset to change it to 1280x854. Here's the first > entry in my /etc/fb.modes: > Currently, no. You have to add your modeline into the kernel's modeline table which is located in drivers/video/modedb.c (unless your mode is already present). > # > # Sample video modes > # > > # Generated using modeline2fb, 1280x854, 85.266 MHz dotclock > > mode "fullscreen" > geometry 1280 854 1280 26201 8 > timings 11728 240 16 31 0 256 7 > hsync low > vsync low > endmode > > The module doesn't seem to accept mode parameters, however. It does, except for the startup mode, so if rivafb is compiled as a module (and this is true for most drivers), it will only use the default mode. > > >>The main remaining annoyance is that you can't remove the rivafb module, > > > >You can actually, as long as you don't enable the framebuffer console. > > This sequence should work: > > > >modprobe rivafb > >mplayer -vo directfb > >rmmod rivafb > > > >Of course you will only have a vga console. > > Not sure I understand -- you don't mean I can insert rivafb while > the nvidia module is still inserted? In that case I get this: No, I was answering the part of your question about being able to remove rivafb, and the answer is yes you can, as long as the framebuffer console is disabled. > > > ---------------------- DirectFB v0.9.20 --------------------- > (c) 2000-2002 convergence integrated media GmbH > (c) 2002-2003 convergence GmbH > ----------------------------------------------------------- > > (*) Single Application Core. (with MMX support) (2004-01-20 10:18) > (*) DirectFB/misc/memcpy: using MMXEXT optimized memcpy() > (!) DirectFB/core/fbdev: Error opening `/dev/fb0'! > --> No such device > (!) DirectFB/Core: Could not initialize 'system' core! > --> Not supported! > (!) DirectFB/Core: Error during initialization (Not supported!) > vo_directfb2.c <315>: > (#) DirectFBError [DirectFBCreate (&dfb)]: Not supported! > > Not surprising, right? The framebuffer device /dev/fb0 is not created. > So what does it mean to use directfb without enabling the framebuffer > console? As I've mentioned above, you can load the framebuffer driver, but not load the framebuffer console, and it should work. Set CONFIG_FRAMEBUFFER_CONSOLE=n. Tony |
From: David L. <lio...@co...> - 2004-11-12 19:56:45
|
Hi Tony, Thank you for the hints and suggestions. >>I'm also wondering if it's possible to tell the rivafb module to use >>the right mode when loading -- at the moment it loads into 640x480 >>and then I use fbset to change it to 1280x854. Here's the first >>entry in my /etc/fb.modes: >> >> >Currently, no. You have to add your modeline into the kernel's >modeline table which is located in drivers/video/modedb.c (unless >your mode is already present). > > I added these lines: { /* 1280x854 @ 85 Hz, 47.58 kHz hsync */ NULL, 85, 1280, 854, 11723, 240, 16, 31, 0, 256, 7, FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED }, and these (shifting the numbers down): /* 18 1280x854-85 VESA */ { NULL, 85, 1280, 854, 11723, 240, 16, 31, 0, 256, 7, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA }, But got no effect. It's not critical. >>The module doesn't seem to accept mode parameters, however. >> >> >It does, except for the startup mode, so if rivafb is compiled as a module >(and this is true for most drivers), it will only use the default mode. > > I don't think I understand -- do you mean that a parameter can be passed if the driver is compiled into the kernel? >...I was answering the part of your question about being able to >remove rivafb, and the answer is yes you can, as long as the framebuffer >console is disabled. > > Got it -- I rebuilt the kernel with the framebuffer console as a module, and can confirm that directfb still works under rivafb, which now can be removed. I run a dual monitor setup, so when I remove rivafb, the built-in laptop screen flickers and only the second, attached LCD reverts to a usable console (with slightly mangled fonts). The main downside is that the graphics quality is now clearly inferior -- the picture is fuzzy -- and there's no sound in my case. With the framebuffer console loaded, the graphics are excellent and the sound perfect -- if anything, it's nicer to watch movies this way than in X. To sum up, what works for me is this: * modify drivers/video/riva/fbdev.c as you suggest * add the correct mode to /etc/fb.modes (modeline2fb -d 8 /etc/X11/XF86Config-4) * rmmod nvidia && modprobe fbcon and rivafb * fbset the new mode * mplayer -vo directfb *.vob * fbi *.jpg -t 5 -autozoom -edit for slideshows The framebuffer console and rivafb are really attractive -- great crisp graphics and fonts, low cpu usage, minimal overhead. There are still kinks that need to be ironed out -- * moving the mouse in mplayer freezes the system * EDID isn't working on N17, works fine in XFree86 -- so wrong initial screen size/resolution -- which cannot easily be corrected in modedb.c -- mouse stays in a 640x480 area even after resizing * cannot unload fbcon+rivafb * resolution poor in rivafb without fbcon (and so what?) I think this is really cool work -- and thanks for giving me such detailed feedback. I've been wanting to have this working for years. Cheers, Dave |
From: Antonino A. D. <ad...@ho...> - 2004-11-12 20:55:16
|
On Saturday 13 November 2004 03:55, David Liontooth wrote: > Hi Tony, > > Thank you for the hints and suggestions. > > >>I'm also wondering if it's possible to tell the rivafb module to use > >>the right mode when loading -- at the moment it loads into 640x480 > >>and then I use fbset to change it to 1280x854. Here's the first > >>entry in my /etc/fb.modes: > > > >Currently, no. You have to add your modeline into the kernel's > >modeline table which is located in drivers/video/modedb.c (unless > >your mode is already present). > > I added these lines: > > { > /* 1280x854 @ 85 Hz, 47.58 kHz hsync */ > NULL, 85, 1280, 854, 11723, 240, 16, 31, 0, 256, 7, > FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED > }, > > and these (shifting the numbers down): > > /* 18 1280x854-85 VESA */ > { NULL, 85, 1280, 854, 11723, 240, 16, 31, 0, 256, 7, > FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, > FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA }, > > But got no effect. It's not critical. Not in there, in the first database, struct fb_videomode *modedb. Tony |
From: Antonino A. D. <ad...@ho...> - 2004-11-12 22:01:15
|
On Saturday 13 November 2004 04:54, Antonino A. Daplas wrote: > On Saturday 13 November 2004 03:55, David Liontooth wrote: > > Hi Tony, > > > > Thank you for the hints and suggestions. > > > > >>I'm also wondering if it's possible to tell the rivafb module to use > > >>the right mode when loading -- at the moment it loads into 640x480 > > >>and then I use fbset to change it to 1280x854. Here's the first > > >>entry in my /etc/fb.modes: > > > > > >Currently, no. You have to add your modeline into the kernel's > > >modeline table which is located in drivers/video/modedb.c (unless > > >your mode is already present). > > > > I added these lines: > > > > { > > /* 1280x854 @ 85 Hz, 47.58 kHz hsync */ > > NULL, 85, 1280, 854, 11723, 240, 16, 31, 0, 256, 7, > > FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, > > FB_VMODE_NONINTERLACED }, Ah, you already inserted the entry into the correct database. rivafb as a module will not accept modeline options, but you should be able to boot with: video=rivafb:1280x854@85; Tony |
From: Geert U. <ge...@li...> - 2004-11-13 10:05:18
|
On Fri, 12 Nov 2004, David Liontooth wrote: > There are still kinks that need to be ironed out -- > > * moving the mouse in mplayer freezes the system > * EDID isn't working on N17, works fine in XFree86 > -- so wrong initial screen size/resolution > -- which cannot easily be corrected in modedb.c > -- mouse stays in a 640x480 area even after resizing ^^^^^ Which mouse do you mean here? MPlayer (probably not cfr. above)? Gpm? I remember seeing similar problems with gpm when having multiple virtual consoles using different resolutions (and hence different number of text columns and rows): gpm would use the number of columns/rows it found on the active virtual console on startup. That was a few years ago, though, in 2.4.x. 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 |