linux-fbdev-users Mailing List for Linux Frame Buffer Device Development

On Saturday 20 November 2004 00:01, Olaf Leidinger wrote:
> Hello!
>
> > Which kernel is this? My 2.6.10-rc1 kernel doesn't define the
> > radeon_noaccel_ops.. Or is it the old radeon driver?
> >
> > The new one is the one in aty/* .
>
> I know ... I modified radeon_base.c, which is part of the new driver.
>
> What I did was adding
>
> if (noaccel)
> {
> info->flags |= FBINFO_HWACCEL_DISABLED;
> info->fix.accel = FB_ACCEL_NONE;
> }
> else
> info->fix.accel = FB_ACCEL_ATI_RADEON;
>
> around line 1750 to make fbset and directfb believe hw accel is
> switched on.
>
Ok, that's a bug in radeon. However the correct way is simply like this:
info->fix.accel = FB_ACCEL_ATI_RADEON;
if (noaccel)
	info->flags |= FBINFO_HWACCEL_DISABLED;
info->fix.accel is used as an identifier and should be enabled whether
console acceleration is disabled or not. To disable userspace from
using the hardware, then either set:
1. info->fix.accel = FB_ACCEL_NONE; or
2. info->fix.mmio_len = 0;
Both of which will disable user space usage of the hardware.
Tony

On Friday 19 November 2004 23:39, Olaf Leidinger wrote:
> Am Fr, den 19.11.2004 schrieb Antonino A. Daplas um 1:00:
> > On Friday 19 November 2004 07:20, Olaf Leidinger wrote:
> > > Hello!
> > >
> > > > Do you have a list of the patches you found?
> > >
> > > Well, no ... but when searching the archive of this list for
>
> "radeonfb
>
> > > patch" ( - Require All Words - checked ) you'll find the patches I
> > > found ;-)
> > >
> > > The accel-patch I tried is located at:
> > > http://sourceforge.net/mailarchive/message.php?msg_id=7134262
> >
> > That's already in mainline for a long time, not the exact patch of
>
> course.
>
> > You're probably looking at a different file, the accel ops are in
>
> radeon_accel.c
>
> Okay... but when booting using the fb providet by radeonfb I get no
> accel (fbset -i tells it is deactivated) . So I patched radeonfb to set
> info->fix.accel = FB_ACCEL_ATI_RADEON (similar to the aty-driver). Now
> directfb loads its radeon driver but it exits immediately...
>
Any messages from directfb? Maybe this is a directfb problem?
Tony

Hello!
> Which kernel is this? My 2.6.10-rc1 kernel doesn't define the
> radeon_noaccel_ops.. Or is it the old radeon driver? 
> The new one is the one in aty/* .
I know ... I modified radeon_base.c, which is part of the new driver.
What I did was adding 
 if (noaccel)
 {
 info->flags |= FBINFO_HWACCEL_DISABLED;
 info->fix.accel = FB_ACCEL_NONE;
 }
 else
 info->fix.accel = FB_ACCEL_ATI_RADEON;
around line 1750 to make fbset and directfb believe hw accel is
switched on.
So I didn't use radeonfb_noaccel_ops.
I use gentoo-dev-sources-2.6.9
Ciao,
Olaf

On Fri, 2004年11月19日 at 12:55 +0100, Olaf Leidinger wrote:
> Okay... but when booting using the fb providet by radeonfb I get no
> accel (fbset -i tells it is deactivated) . So I patched radeonfb to set
> info->fix.accel = FB_ACCEL_ATI_RADEON (similar to the aty-driver). Now
> directfb loads its radeon driver but it exits immediately...
> 
> This part of the patch I discoverd after I tried my self-made hack seems
> to do the same (if not more ;-) ) but it isn't part of radeon_base.c as
> it ships with linux-2.6.9
> -	if (noaccel)
> -	 info->fix.accel = FB_ACCEL_NONE;
> -	else
> -		info->fix.accel = FB_ACCEL_ATI_RADEON;
> -
> -	fb_alloc_cmap(&info->cmap, 256, 0);
> -
> -	if (noaccel)
> +	if (noaccel) {
> +		info->fix.accel = FB_ACCEL_NONE;
> 		info->var.accel_flags &= ~FB_ACCELF_TEXT;
> -	else
> +		info->fbops = &radeonfb_noaccel_ops;
> +	} else {
> +		info->fix.accel = FB_ACCEL_ATI_RADEON;
> 		info->var.accel_flags |= FB_ACCELF_TEXT;
> +		info->fbops = &radeonfb_ops;
> +	}
> +	fb_alloc_cmap(&info->cmap, 256, 0);
> 
> Nor the lines that the patch removes are part of the official radeon_base.c
Which kernel is this? My 2.6.10-rc1 kernel doesn't define the
radeon_noaccel_ops.. Or is it the old radeon driver? The new one is the
one in aty/* .
-- 
Torgeir Veimo <to...@po...>

Am Fr, den 19.11.2004 schrieb Antonino A. Daplas um 1:00:
> On Friday 19 November 2004 07:20, Olaf Leidinger wrote:
> > Hello!
> >
> > > Do you have a list of the patches you found?
> >
> > Well, no ... but when searching the archive of this list for
"radeonfb
> > patch" ( - Require All Words - checked ) you'll find the patches I
> > found ;-)
> >
> > The accel-patch I tried is located at:
> > http://sourceforge.net/mailarchive/message.php?msg_id=7134262
>
> That's already in mainline for a long time, not the exact patch of
course.
>
> You're probably looking at a different file, the accel ops are in
radeon_accel.c
Okay... but when booting using the fb providet by radeonfb I get no
accel (fbset -i tells it is deactivated) . So I patched radeonfb to set
info->fix.accel = FB_ACCEL_ATI_RADEON (similar to the aty-driver). Now
directfb loads its radeon driver but it exits immediately...
This part of the patch I discoverd after I tried my self-made hack seems
to do the same (if not more ;-) ) but it isn't part of radeon_base.c as
it ships with linux-2.6.9
 - if (noaccel)
 - info->fix.accel = FB_ACCEL_NONE;
 - else
 - info->fix.accel = FB_ACCEL_ATI_RADEON;
 -
 - fb_alloc_cmap(&info->cmap, 256, 0);
 -
 - if (noaccel)
 + if (noaccel) {
 + info->fix.accel = FB_ACCEL_NONE;
 info->var.accel_flags &= ~FB_ACCELF_TEXT;
 - else
 + info->fbops = &radeonfb_noaccel_ops;
 + } else {
 + info->fix.accel = FB_ACCEL_ATI_RADEON;
 info->var.accel_flags |= FB_ACCELF_TEXT;
 + info->fbops = &radeonfb_ops;
 + }
 + fb_alloc_cmap(&info->cmap, 256, 0);
Nor the lines that the patch removes are part of the official
radeon_base.c
They should be around line 1750
Ciao,
Olaf

On Fri, 2004年11月19日 at 00:20 +0100, Olaf Leidinger wrote:
> 
> Although it's nearly ten months old it isn't in the kernel source tree
> (at least not in my one ;-) ) That's why I asked what happend to this
> patch...
So I guess just setting the acceleration id didn't work for you? 
I'd assume any other problem would be directfb related, as a framebuffer
can be quite dumb, the acceleration can live in directfb.
-- 
Torgeir Veimo <to...@po...>

On Friday 19 November 2004 07:20, Olaf Leidinger wrote:
> Hello!
>
> > Do you have a list of the patches you found?
>
> Well, no ... but when searching the archive of this list for "radeonfb
> patch" ( - Require All Words - checked ) you'll find the patches I
> found ;-)
>
> The accel-patch I tried is located at:
> http://sourceforge.net/mailarchive/message.php?msg_id=7134262
That's already in mainline for a long time, not the exact patch of course.
You're probably looking at a different file, the accel ops are in radeon_accel.c
Tony

Hello!
> Do you have a list of the patches you found?
Well, no ... but when searching the archive of this list for "radeonfb
patch" ( - Require All Words - checked ) you'll find the patches I
found ;-)
The accel-patch I tried is located at:
http://sourceforge.net/mailarchive/message.php?msg_id=7134262
Although it's nearly ten months old it isn't in the kernel source tree
(at least not in my one ;-) ) That's why I asked what happend to this
patch...
Ciao,
Olaf

Olaf Leidinger wrote:
> 
> I'm looking for the latest version of radeonfb. The version included
> with linux-2.6.9 seems to be a bit outdated, as the hw accel patch I
> found in the devel-list doesn't apply. Then I've noticed some more
> patches in the devel-archives. Is there a place from which I can
> download the latest version (or at least a patch that works with
> linux-2.6.9). The CVS only contains the source code of it's homepage ;-(
> 
Not completely. The sources for the Intel 810/815 (i810fb) driver are there.
When I reworked this website I thought it might a good idea if the
source code is located here as well. But it's completely up to the
maintainer of a driver if he wants or nor. Just ask the maintainer of
your driver if he moves the newest source over here or if he can tell
you where its so you could do it. 
IMO it would be perfect if all the sources where here and the Makefiles
for kbuild were available. That would allow for a much better and faster
development cycle. So if anyone wants it to do for his driver, just
contact me direct for the CVS access rights.
O. Wyss
-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

On Thu, 2004年11月18日 at 19:01 +0100, Olaf Leidinger wrote:
> 
> 
> I'm looking for the latest version of radeonfb. The version included
> with linux-2.6.9 seems to be a bit outdated, as the hw accel patch I
> found in the devel-list doesn't apply.
Do you have a list of the patches you found?
There's not a lot of answers to be found on this mailing list I'm
afraid...
-- 
Torgeir Veimo <to...@po...>

Hello!
I'm looking for the latest version of radeonfb. The version included
with linux-2.6.9 seems to be a bit outdated, as the hw accel patch I
found in the devel-list doesn't apply. Then I've noticed some more
patches in the devel-archives. Is there a place from which I can
download the latest version (or at least a patch that works with
linux-2.6.9). The CVS only contains the source code of it's homepage ;-(
Thanks a lot,
Ciao,
Olaf

On 2004年11月12日, 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

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

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

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

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

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

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

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

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

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 .&checktime(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

On 2004年11月07日 the mental interface of
Antonino A. Daplas told:
> On Sunday 07 November 2004 03:30, Elimar Riesebieter wrote:
> > On 2004年10月28日 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > > > On 2004年10月27日 the mental interface of
> > > >
> > > > Antonino A. Daplas told:
> > > > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > Can you try choosing the l6 color logo in the kernel kconfig. Or you=
 can
> > > try this patch instead. Let me know which one or if both works.
> >
> > That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9
>=20
> Ok, too many changes in radeon. Try this one, specific for 2.6.9. Note
> that the same fix is available in the bk or mm tree.
>=20
> Tony
>=20
> diff -uprN linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c linux-2.6.=
9/drivers/video/aty/radeon_monitor.c
> --- linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c	2004年11月07日 03:45:=
56.000000000 +0800
> +++ linux-2.6.9/drivers/video/aty/radeon_monitor.c	2004年11月07日 03:48:14.72=わ
7342552 +たす0800
> @@ -8,7 +8,7 @@
> =20
> static struct fb_var_screeninfo radeonfb_default_var =3D {
> 640, 480, 640, 480, 0, 0, 8, 0,
> - {0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
> + {0, 8, 0}, {0, 8, 0}, {0, 8, 0}, {0, 0, 0},
> 0, 0, -1, -1, 0, 39721, 40, 24, 32, 11, 96, 2,
> 0, FB_VMODE_NONINTERLACED
> };
This one gives me the bootlogo back ;-)
Thx
Elimar
--=20
 Learned men are the cisterns of knowledge,=20
 not the fountainheads ;-)

On Sunday 07 November 2004 03:30, Elimar Riesebieter wrote:
> On 2004年10月28日 the mental interface of
>
> Antonino A. Daplas told:
> > On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > > On 2004年10月27日 the mental interface of
> > >
> > > Antonino A. Daplas told:
> > > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > Can you try choosing the l6 color logo in the kernel kconfig. Or you can
> > try this patch instead. Let me know which one or if both works.
>
> That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9
Ok, too many changes in radeon. Try this one, specific for 2.6.9. Note
that the same fix is available in the bk or mm tree.
Tony
diff -uprN linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c linux-2.6.9/drivers/video/aty/radeon_monitor.c
--- linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c	2004年11月07日 03:45:56.000000000 +0800
+++ linux-2.6.9/drivers/video/aty/radeon_monitor.c	2004年11月07日 03:48:14.727342552 +0800
@@ -8,7 +8,7 @@
 
 static struct fb_var_screeninfo radeonfb_default_var = {
 640, 480, 640, 480, 0, 0, 8, 0,
- {0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
+ {0, 8, 0}, {0, 8, 0}, {0, 8, 0}, {0, 0, 0},
 0, 0, -1, -1, 0, 39721, 40, 24, 32, 11, 96, 2,
 0, FB_VMODE_NONINTERLACED
 };

On 2004年10月28日 the mental interface of
Antonino A. Daplas told:
> On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > On 2004年10月27日 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> >
> > White cursor is back :-))
>=20
> Great.
>=20
> > Bootlogo isn't shown?
>=20
> Can you try choosing the l6 color logo in the kernel kconfig. Or you can
> try this patch instead. Let me know which one or if both works.
That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9
Ciao
Elimar
--=20
 "Talking much about oneself can also=20
 be a means to conceal oneself."
 -Friedrich Nietzsche

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