NVidia framebuffer driver to replace vesafb

[elektronisch]

Obviously they have to since we don't have the specs on the card.

[LordMorgul]

If you think vesafb sucks then take a look at vesafb-tng. Where I found it in my above post -- had to correct myself.

[jerickson314]

There may be a solution to use normal vesafb with the drivers, as we discussed in this thread, thanks to mixer030. Adding the lines:

Option "ConnectedMonitor" "CRT"
Option "IgnoreDisplayDevices" "TV"

to XF86Config seems to fix the problem. (You may have to use "ConnectedMonitor" "DFP" if you have a DVI flat panel, hopefully that would work as well). Also, I think this fix would disable using multiple video outputs. I did notice the problem occurred (prior to the above fix) on both cards I have used that had 3 outputs, but it worked fine on the card that had only two outputs. (See the other thread for more details).

I reported my findings to linux-bugs@nvidia.com yesterday and received a reply today asking for more information. At least we know nVidia is working on it!

[mklemm]

I strongly dislike the current graphics architecture under Linux that is built entirely around X as the only fully supported Graphics/UI-System.
Normally, graphics stuff - accelerated or not - should be handled on a documented and interfaceable layer below the UI system. The trouble we experience currently around XFree and xorg shows how important it is to have something that just does graphics without dependencies on anything UI specific.
The XFree architecture since 4.0 already has been a step in this direction, now it's time to push this one step further.
I'm thinking of something like the current X-Vesafb-Server, but with full 2D/3D acceleration support.

Well, what should be done is:
1. The kernel developers should specify a complete, stable and fast X-independent kernel mode graphics API and driver interface with full acceleration support
2. The XFree or xorg architects should develop a generic X server that builds on this kernel mode graphics API
3. NVIDIA should release a stable and fast generic driver for the low-level API with no X-specific stuff in it

I'm sure it's possible to get accelerated OpenGL support into this architecture, too, with only very few (if any) performance impact on GLX and 3D-apps running under X.
(The generic API doesn't have to be all "kernel mode" ... That's just how the framebuffer device is implemented at the moment... Concerns could be seperated between kernel and user space as performance and stability considerations dictate).

[jsmerritt]

Solution found - see below:

It appears that some folks are able to use vesafb to obtain a higher resolution console. I've tried every combination of vga= and video=vesa:... and have come up empty Whenever I respond to the vga=ask with a graphics vesa mode, the screen immediately goes blank and stays that way. The info pop-up window on the monitor confirms that the pixel resolution has changed, but the blank screen is hampering further diagnosis (:

I've been assuming that the remaining kernel boot messages should appear on the screen at the new video resolution. Is this assumption correct, or do I have to wait until a virtual console is redirected to the frame buffer device ???

Gainward SlientFX Ultra/980 (GeForce FX 5700) - Pentium IV @ 3.0 GHz
Stock Redhat 9 with all current RedHat patches (Kernel NOT recompiled)

Thanks, Scott.

--------------------------------------------------------------------------------------------------
Solution:

SSH from separate machine showed "vesafb: abort, cannot ioremap video
memory 0x10000000 @ 0xd0000000". Following a hunch, I included "mem=512" on the kernel command line and WOLLA it works (Note that machine is configured with 2GB of RAM). Best regards, Scott.

[julius]

Hi!

Interesting thread!
As far as I can see, atm there's no framebuffer support from nvidia side?!?!?
I am running under SARGE a Geforce FX 5200 on my satellite m30-642 and obviously there's no chance except using the damn vesafb module for using a higher console resolution.
That`s disappointing :-((

Cheers
julius

[Thunderbird]

If people really want a framebuffer driver, there's enough public source code to build one (xfree86 nv driver and much more ..). Further another nice solution for a framebuffer driver is to use scitechsoft's "free" (for personal use) snap graphics driver. This driver is crossplatform and includes support for Linux. The nice thing about is that the driver has an SDK using which it is possible to build custom drivers including a framebuffer driver. This driver will then be optimal for all hardware supported by snap... (writing this driver shouldn't be hard)

[catimimi]

I'm able to get high resolution vesafb if I want.
When a TV vable RCA or Svideo is connected on the output, vesafb is limited to 800x600, it seems to be a hardware limitation in order to enable TVout. This happens at boot and then even if Tvout is disabled in XF86Config !!

But if no cable is connected you have access to all vesafb resolutions.

Since this seems to be limited by hardware, I can't imagine which nvidiafb could solve the problem.

Michel

Originally Posted by LordMorgul

If you think vesafb sucks then take a look at vesafb-tng. Where I found it in my above post -- had to correct myself.

Bumping this to ask why NVIDIA is doing nothing.
Surely there must be a way for nvidiafb and the nvidia kernel driver to coexist peacefully?
Those of us running AMD64 non-x86 archs are suffering, as we can't use vm86.

Any reason why this isn't possible, NVIDIA?

[zbiggy]

Via provides proprietary all in one framebuffer driver for all their integrated graphics:
http://www.viaarena.com/default.aspx...0&SubCatID=109
This package contains the console framebuffer driver Source Code supporting CLE266/CN400/CN700/KM400/KN400/PM880/PM800/PN880/PN800/P4M800CE/P4M800Pro/VN800 UniChrome family integrated chipsets for Linux kernels 2.4 and 2.6. This file is 100kb size.

So why Nvidia can't?
This is the same situation like with mpeg-4 acceleration for X - Via can support it for cheap integrated graphics but Nvidia can't.

Nvidia's own accelerated framebuffer driver could solve random freezing during vesafb console<->X switching.

[BSD]

Sorry for bumping, but what is the status of this?

[Gusar]

Dude, this thread is four years old! Anyway, the status is, Nvidia is not interested: http://www.nvnews.net/vbulletin/show...73&postcount=2