NVidia framebuffer driver to replace vesafb

[Loial]

I'm currently using the UNaccelerated vesafb driver that is in the Linux kernel. My grub kernel line:
kernel /bzImage root=/dev/hda3 hdc=ide-scsi hdd=ide-scsi vga=0x346 video=vesa:mtrr,ywrap:1600x1200@60

Now I was wondering if it would be possible for NVidia to provide a driver to replace this generic console driver and make it possible to use all resolutions and colordepths that are also available in XFree86 and provide accelerated graphics for us console lovers? I can only run 1600x1200@16 bits atm, and that was a pain to find out (no decent docs available anywhere on the web at the time)

There is atm the rivafb driver which does some acceleration, but it won't swallow my Geforce2 GTS let alone more recent cards. This is a concern for me, which I would like to see resolved so I can buy a replacement videocard and know that it is being put in full service and not that it is idling on some oldschool unaccelerated vesa thingies.

Hopefully, such a driver in the kernel can also fix a problem I've been having, that changing between XFree and console messes things up badly when running a framebuffer application, because now it keeps resulting in me doing a reboot to reinitialize and fix things.

I would like to know if such a driver is planned or if it is already being developed (I'm sure you will have thought of similar things a thousand times already:P)

[broose]

Yes please Nvidia!

Would love to be able to use the features of my MX420 and 440 in framebuffer console.

[ribx]

since i registered here i am trying to find a solution for your problem. i realy love the console, but i can only run it at a max of 640x480 .. and this is realy ugly on my 19" screen. i am using lilo and i will try to use your settings.. i hope it will work :) we ll see

but now the main problem: i dont see any experenced people here in the linux section.. i think they dont care about us..

WHAT CAN WE DO TO CONTAKT A MOD or AN ADMIN here in the linux forum?
start a new thread in the open forum???

i think i ll do this if i cant find a solution soon

_____________
NV18

[bactrimel]

If all you want is a nice, big text mode (e.g. 192x60@70Hz) you could try using a patched version of SVGATextMode. See here:

http://www.nvnews.net/vbulletin/showthread.php?s=&postid=233721#post233721

[broose]

:confused: Hi

I'm sure I read somewhere, SVGATextMode is no longer being developed.

[broose]

Originally posted by Loial
I'm currently using the UNaccelerated vesafb driver that is in the Linux kernel. My grub kernel line:
kernel /bzImage root=/dev/hda3 hdc=ide-scsi hdd=ide-scsi vga=0x346 video=vesa:mtrr,ywrap:1600x1200@60

Now I was wondering if it would be possible for NVidia to provide a driver to replace this generic console driver and make it possible to use all resolutions and colordepths that are also available in XFree86 and provide accelerated graphics for us console lovers? I can only run 1600x1200@16 bits atm, and that was a pain to find out (no decent docs available anywhere on the web at the time)

There is atm the rivafb driver which does some acceleration, but it won't swallow my Geforce2 GTS let alone more recent cards. This is a concern for me, which I would like to see resolved so I can buy a replacement videocard and know that it is being put in full service and not that it is idling on some oldschool unaccelerated vesa thingies.

Hopefully, such a driver in the kernel can also fix a problem I've been having, that changing between XFree and console messes things up badly when running a framebuffer application, because now it keeps resulting in me doing a reboot to reinitialize and fix things.

I would like to know if such a driver is planned or if it is already being developed (I'm sure you will have thought of similar things a thousand times already:P)

I am still trying to get someone at nVidia to comment on support for 2D/3D acceleration in the Linux console framebuffer.

I for one am more than satisfied with the drivers nVidia supply for X-windows, have had no problems with any of thier driver. Keep up the good work.

X-windowing system is a great piece of kit, for those who utilise all its facilities, but there are people using thier computers to just read e-mails, surf the web, write letters etc; in other areas where people are restricted to old/low resource hardware i.e. schools, X then becomes overkill and is too resource hungry.

I have two machines at home:

Machine A has Athlon 2200+, nVidia GForce4 64Mb, vesafb.
Machine B has Pentium 200, 3Dfx Voodoo2 16Mb, tdfxfb.

and have compiled the demo app that comes with TrollTech's Qt-Embedded (that uses the framebuffer only) and the app runs faster and smoother on Machine B. Just think how fast that app would run on Machine A if it had an nVidiafb, and ribx could have better resolution on his/her 19" monitor.

Thaks for listening, sorry, reading.

broose

[analogue]

We need framebuffer support ! Could you at least release the 2D specs of your chips so we get a decent framebuffer module ?

Actually it just make our computers crash :/

[broose]

Originally posted by analogue
We need framebuffer support ! Could you at least release the 2D specs of your chips so we get a decent framebuffer module ?

Actually it just make our computers crash :/

Why?

[nyteryda]

Have there been any answers on this yet as it is what i am looking for as im looking at XDirectFB instead of XFree/Xorg

[LordMorgul]

I spend lots of time staring at VTs (using vesafb) and would appreciate the ability to control refresh rates in high resolution modes above all else (I find the speed adequate). There is no way to do this that I am aware of -- you get 60Hz. Unfortunately.. since the vesafb module is initialized very early in the kernel I believe such support from nvidia may require some level of bootstrapping in the mainline kernel at least -- they could not release a driver that would handle 2/3D accelerated framebuffers without part of the code being included in the kernel it is to run on. Comments?

Update: Yes it takes code active at kernel boot.. but VTs can be run in higher refresh rates with vesafb.
Here's the thread (http://forums.gentoo.org/viewtopic.php?t=71570) where I found out how, and got the patches -- Gentoo forums to the rescue once again. Updated patches are linked from the very end, page 9 right now. This still works with the nVIDIA driver just fine -- no its not the accellerated solution others would like.

[mklemm]

I think NVIDIA should change the driver architecture on Linux such that the X specific stuff will be based on a kernel mode driver that also could be used by a NVIDIA-specific framebuffer device. This will avoid problems most people currently have with the open source rivafb driver, and all graphics stuff could be based on a common architecture. Other OSes (like e.g. Solaris) already do this: They have a good framebuffer driver, and X just sits on top of it. Why should it be so hard to do that on Linux?

[SuLinUX]

Thats down to the kernel devs and distro developers, SuSE works and other are fine so why would is be upto nvidia for a framebuffer?

[elektronisch]

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

[LordMorgul]

If you think vesafb sucks then take a look at vesafb-tng (http://dev.gentoo.org/~spock/#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 (http://www.nvnews.net/vbulletin/showthread.php?t=29603), 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

[mikearthur]

If you think vesafb sucks then take a look at vesafb-tng (http://dev.gentoo.org/~spock/#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?PageID=420&OSID=20&CatID=2260&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/showpost.php?p=2304773&postcount=2