linux-fbdev-users — Generic mailing list for users of frame buffers

Re: [Linux-fbdev-users] Radeonfb driver in kernel 2.6

[Otto W. <ott...@or...>]

Torgeir Veimo wrote:
> 
> Are you using the new or the old radeonfb driver? The new one is in the
> aty src directory.
> 
I tried the Debian/Sarge kernel, currently 2.6.8, I guess it still use
the old driver. I switched back to 2.4.26 where it worked correct.

> I run with the new radeonfb successfully from kernel 2.6.10 in
> 1280x720-50, but am still struggling with directfb.
> 
Fine, I'd prefer I to stick with an ordniary Debian package but I may
try to build the new driver since I know now it's working.

> The radeonfb driver needs a patch to set the correct acceleration id,
> but I think it is being sent upstream.
> 
DirectFB is another story, luckally I'm not in a hurry. As far as I know
it worked a little bit with 2.4.24 when I tried my check app (see
"http://wyodesktop.sourceforge.net/index.php?page=checkapp.html"), at
leased it showed some colours.

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

Re: [Linux-fbdev-users] Radeonfb driver in kernel 2.6

[Torgeir V. <to...@po...>]

On Sat, 2005-01-15 at 09:41 +0100, Otto Wyss wrote:
> I've tried to use the Debian 2.6.8-2 kernel but radeonfv driver still
> doesn't work correct, the screen is switched to 1280x1024-60 but still
> shows 640x480. This is a known bug and I'd like to know in which
> kernel
> this bug is fixed. Does anyone use the radeonfb driver and can tell me
> with which kernel version?
> 
> Or is it possible to disable the malfunctioning accelerated code? How?

Are you using the new or the old radeonfb driver? The new one is in the
aty src directory.

I run with the new radeonfb successfully from kernel 2.6.10 in
1280x720-50, but am still struggling with directfb.

The radeonfb driver needs a patch to set the correct acceleration id,
but I think it is being sent upstream.

-- 
Torgeir Veimo <to...@po...>

[Linux-fbdev-users] Radeonfb driver in kernel 2.6

[Otto W. <ott...@or...>]

I've tried to use the Debian 2.6.8-2 kernel but radeonfv driver still
doesn't work correct, the screen is switched to 1280x1024-60 but still
shows 640x480. This is a known bug and I'd like to know in which kernel
this bug is fixed. Does anyone use the radeonfb driver and can tell me
with which kernel version?

Or is it possible to disable the malfunctioning accelerated code? How?

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

Re: [Linux-fbdev-users] setting accelerator id for radeon fb

[Antonino A. D. <ad...@ho...>]

On Thursday 13 January 2005 20:25, Torgeir Veimo wrote:
> Could someone get the following patches upstream in the mainline kernel?

Will do.

Tony

[Linux-fbdev-users] setting accelerator id for radeon fb

[Torgeir V. <to...@po...>]

Could someone get the following patches upstream in the mainline kernel?

in drivers/video/aty/

[vigor10 aty]# diff radeon_base.c radeon_base.c-orig
1783,1784d1782
<       else
<               info->fix.accel = FB_ACCEL_ATI_RADEON;

-- 
Torgeir Veimo <to...@po...>

Re: [Linux-fbdev-users] matroxfb: non active head doesn't u

[Uns L. <uns...@mi...>]

On Tue, 11 Jan 2005, Petr Vandrovec wrote:
> On 11 Jan 05 at 13:32, Uns Lider wrote:
> > I just upgraded from 2.4.9 to 2.6.10. I have a G100 quad, and VCs on
> > multiple heads. With 2.4.9 if I ran programs on two heads they would both
> > update the screen. Now only the one on the current VC updates, and the
> > other head is frozen until I switch to its VC. I remember some older
> > kernel versions being like this too. Is this a bug or do I have to
> > reconfigure something?
> Yes, 2.6.x kernels do not support this feature at all, it was removed...
>
> You need to apply
> http://platan.vc.cvut.cz/ftp/pub/vmware/matrox-latest/matroxfb-2.6.10.gz
> to your 2.6.10 kernel.  Then text on both heads should update

I've applied the patch and it works now, thanks!

-- uns

Re: [Linux-fbdev-users] matroxfb: non active head doesn't u

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

On 11 Jan 05 at 13:32, Uns Lider wrote:
> I just upgraded from 2.4.9 to 2.6.10. I have a G100 quad, and VCs on
> multiple heads. With 2.4.9 if I ran programs on two heads they would both
> update the screen. Now only the one on the current VC updates, and the
> other head is frozen until I switch to its VC. I remember some older
> kernel versions being like this too. Is this a bug or do I have to
> reconfigure something?

Yes, 2.6.x kernels do not support this feature at all, it was removed...  

You need to apply
http://platan.vc.cvut.cz/ftp/pub/vmware/matrox-latest/matroxfb-2.6.10.gz
to your 2.6.10 kernel.  Then text on both heads should update
(if you use matroxfb, radeonfb or vesafb; other drivers are not
tested as I do not have another hardware).
                                                Petr

[Linux-fbdev-users] matroxfb: non active head doesn't update

[Uns L. <uns...@mi...>]

I just upgraded from 2.4.9 to 2.6.10. I have a G100 quad, and VCs on
multiple heads. With 2.4.9 if I ran programs on two heads they would both
update the screen. Now only the one on the current VC updates, and the
other head is frozen until I switch to its VC. I remember some older
kernel versions being like this too. Is this a bug or do I have to
reconfigure something?

My lilo.conf has `append="video=matrox:sgram video=scrollback:0"' which
used to be required to work around some problem(s), not sure if it still
is.

-- uns

Re: [Linux-fbdev-users] latest version of radeonfb

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Olaf L. <le...@ne...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Torgeir V. <to...@po...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Olaf L. <le...@ne...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Torgeir V. <to...@po...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Olaf L. <le...@ne...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Otto W. <ott...@or...>]

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

Re: [Linux-fbdev-users] latest version of radeonfb

[Torgeir V. <to...@po...>]

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

[Linux-fbdev-users] latest version of radeonfb

[Olaf L. <le...@ne...>]

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

Re: [Linux-fbdev-users] rivafb + NV17

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

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

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] rivafb + NV17

[David L. <lio...@co...>]

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

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

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

Re: [Linux-fbdev-users] rivafb + NV17

[David L. <lio...@co...>]

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