# [UNSOLVABLE]Nvidia 9400M: accelerated framebuffer without X?

## VanFanel

Hello there

I'm building a small embedded-like system for experimental purposes here. It's based around a Core2Duo with Nvidia 9400M (MCP79) and it whouldn't have X, so it should have an accelerated framebuffer insted for multimedia playback without too much CPU usage.

The problem here is that:

-NvidiaFB doesn't seem to support Nvidia9400M. Has that situation changed in the last months?

-There's Nouveau, that seems to include an accelerated framebuffer, but then agan:

    *Does Nouveau support 9400M? I believe it doesn't.

    *Does NouveauFB work without X? I believe it needs another boot-time framebuffer, then it provides it's own framebuffer from X...

I don't need ANY 3D acceleration here. Just an accelerated framebuffer.

any ideas? Thanks!Last edited by VanFanel on Mon Mar 15, 2010 10:05 am; edited 1 time in total

----------

## d2_racing

Hi, maybe you should try the default framebuffer , I mean vesafb?

----------

## VanFanel

VesaFB and uVesaFB (by Spock) work great, yes, but they're slow as hell for scaling and color conversion.

I need an accelerated framebuffer.

----------

## Rexilion

Your card is part of the nv50 generation of nouveau cards. While nouveau might not specifically support your card, it will almost definitely be better than nv. Why? nVidia cards use a generic architecture, each card add's new features in comparison to the old card, and other cards from the nv50 are known to even support 3D!. And since the framebuffer is rather 'low-tech' (in comparison to a 3D driver for example), I think your card will be really well supported (read: hw accelerated framebuffer!) in that case.

And as a sidenote, you don't use X so you can safely use the staging nouveau driver in the kernel  :Smile:  . That will allow you to compile the module into the kernel and safe you a lot of trouble messing around with modules.

----------

## VanFanel

 *Quote:*   

> nVidia cards use a generic architecture, each card add's new features in comparison to the old card

 

@Rexilion & the rest: so it would be teorically possible to "patch" the old nvidiafb sources in the kernel to support new nvidia chips ?

For example, in /drivers/video/nvidia/nvidia.c, I see:

```

static u32 __devinit nvidia_get_arch(struct fb_info *info)

{

   struct nvidia_par *par = info->par;

   u32 arch = 0;

   switch (par->Chipset & 0x0ff0) {

   case 0x0100:      /* GeForce 256 */

   case 0x0110:      /* GeForce2 MX */

   case 0x0150:      /* GeForce2 */

   case 0x0170:      /* GeForce4 MX */

   case 0x0180:      /* GeForce4 MX (8x AGP) */

   case 0x01A0:      /* nForce */

   case 0x01F0:      /* nForce2 */

      arch = NV_ARCH_10;

      break;

   case 0x0200:      /* GeForce3 */

   case 0x0250:      /* GeForce4 Ti */

   case 0x0280:      /* GeForce4 Ti (8x AGP) */

      arch = NV_ARCH_20;

      break;

   case 0x0300:      /* GeForceFX 5800 */

   case 0x0310:      /* GeForceFX 5600 */

   case 0x0320:      /* GeForceFX 5200 */

   case 0x0330:      /* GeForceFX 5900 */

   case 0x0340:      /* GeForceFX 5700 */

      arch = NV_ARCH_30;

      break;

   case 0x0040:      /* GeForce 6800 */

   case 0x00C0:      /* GeForce 6800 */

   case 0x0120:      /* GeForce 6800 */

   case 0x0140:      /* GeForce 6600 */

   case 0x0160:      /* GeForce 6200 */

   case 0x01D0:      /* GeForce 7200, 7300, 7400 */

   case 0x0090:      /* GeForce 7800 */

   case 0x0210:      /* GeForce 6800 */

   case 0x0220:      /* GeForce 6200 */

   case 0x0240:      /* GeForce 6100 */

   case 0x0290:      /* GeForce 7900 */

   case 0x0390:      /* GeForce 7600 */

   case 0x03D0:

      arch = NV_ARCH_40;

      break;

   case 0x0020:      /* TNT, TNT2 */

      arch = NV_ARCH_04;

      break;

   default:      /* unknown architecture */

      break;

   }

   return arch;

}

```

So all I should do is adding my card's PCI ID there in the NV_ARCH_40 block?

According to LSPCI:

```
02:00.0 VGA compatible controller: nVidia Corporation Device 0861 (rev b1)

```

[Edit]: I will force NV40 and see if it works.

static u32 __devinit nvidia_get_arch(struct fb_info *info) simply uses info->par->Chipset to decide the architecture. It's as easy as par->Chipset=<whatever chipset listed in the NV40 block> or simply 

```
--    par->Architecture = nvidia_get_arch(info);

++  par->Architecture = NV_ARCH_40;

```

I have a clear feeling it won't work, but hey, it's my computer, nothing important will be lost it it blows up the entire house with me inside  :Very Happy: 

----------

## Rexilion

Erm, that *could* be possible. But the nvidiafb only provides a framebuffer with more features (maybe a little bit of acceleration?), the nouveau framebuffer provides an hardware accelerated framebuffer so even if you get nvidiafb to work, it won't do media playback without stuttering.

----------

## VanFanel

But the NouveauFB DOES need X running, doesn't it? It uses the DRM infraestructure, wich I believe is part of X... correct me if I'm wrong.

And look at Directfb's acceleration support for Nvidia: 

http://www.directfb.org/index.php?path=Support/Graphics

It uses "nvidiafb"'s /dev/fb (among other backends). So I think it means nvidiafb is accelerated after all. But correct me if I'm wrong...

----------

## Rexilion

 *VanFanel wrote:*   

> But the NouveauFB DOES need X running, doesn't it? It uses the DRM infraestructure, wich I believe is part of X... correct me if I'm wrong.
> 
> And look at Directfb's acceleration support for Nvidia: 
> 
> http://www.directfb.org/index.php?path=Support/Graphics
> ...

 

You definitly don't need X to get an accelerated framebuffer using nouveau. And about the question for drm, you only need to use the nouveau module for an accelerated framebuffer, NO DRM required (yes, it's somehow part of X).

About the page you just gave, yes it seems that nvidiafb supports some form of acceleration. However, I guess you get more performance with nouveau. Plus, nvidiafb doesn't support your card. So, why patching an old driver to support your new card when another one already does (and probably does even better!)?

----------

## VanFanel

@Rexilion: You're right, but I don't think DirectFB will recognize Nouveau's /dev/fb ... I should try that first, yes, then I'd go for old driver patching if necessary.

----------

## Rexilion

 *VanFanel wrote:*   

> @Rexilion: You're right, but I don't think DirectFB will recognize Nouveau's /dev/fb ... I should try that first, yes, then I'd go for old driver patching if necessary.

 

I'm entering unknown territory here to be honest, but wasn't a framebuffer an device independant abstraction?

Looking at the DirectFB useflags, I see a fbcon driver (which you have activated right?). Shouldn't you simply only use that fbcon driver, the nouveau framebuffer as /dev/fb and get it running???

----------

## VanFanel

The fbcon USE flag is for /dev/fb support as a backend. I suppose this /dev/fb is different if the driver offers acceleration, etc... I don't think /dev/fb is a hardware-independant abstraction in that sense... Maybe you can write/read from it Unix-style (and it could be considerend a hardware-independant abastraction in that sense) , but there is much more to it regarding blitting operations, scaling, etc... I believe.

I've never programmed on the framebuffer (not yet) but it's a very attractive posibility if I get an accelerated one.

----------

## Rexilion

 *VanFanel wrote:*   

> The fbcon USE flag is for /dev/fb support as a backend. I suppose this /dev/fb is different if the driver offers acceleration, etc... I don't think /dev/fb is a hardware-independant abstraction in that sense... Maybe you can write/read from it Unix-style (and it could be considerend a hardware-independant abastraction in that sense) , but there is much more to it regarding blitting operations, scaling, etc... I believe.
> 
> I've never programmed on the framebuffer (not yet) but it's a very attractive posibility if I get an accelerated one.

 

Yes, it would be really great if it's really device independent. It could be that you are right, but looking at the kernel documentation made doubt that statement:

```
11   The frame buffer device provides an abstraction for the graphics hardware. It

12   represents the frame buffer of some video hardware and allows application

13   software to access the graphics hardware through a well-defined interface, so

14   the software doesn't need to know anything about the low-level (hardware

15   register) stuff.
```

IF it were to use another interface, then it would be forbidden to show up as /dev/fbX as that would cause confusion I think...

----------

## VanFanel

Just in case someone still cares about the accelerated framebuffer (and you guys should, it's a VERY powerfull feature):

---Nouveau's framebuffer is very basic. It doesn't allow video mode changing dir DirectFB apps. It's NOT  accelerated in any way.

---Patching the nvidiafb so it detects my NV50 as a NV40 just doesn't work. It's not that easy.

I can't mark this one as solved, but I'll try to ask in the kernel mailing list, to see if anyone there has a patchs for nvidiafb to properly support NV50.

regards

----------

## VanFanel

More info on this:

-Nouveufb will NEVER be accelerated, according to nouveau's developers on IRC: framebuffer on X86 machines is considered legacy by now, and it won't get any batter.

-NV50 support on nvidiafb is NOT trivial as I had tohough,. Tried to force it into NV_ARCH_40 and all I get is system freeze. According to nouveau's developers, NV50 is VERY different from NV40.

that's all, folks. Use uvesafb or code your own accelerated framebuffer for NV50. A sad situation for me.

----------

