Framebuffer on a modern graphics card?
Alan Mackenzie
be a graphics card. I would like to get an ATI PCI-express card, or
something similar.
I use framebuffer text mode extensively on my current (8 year old) Matrox
card. How do I go about discovering whether any particular graphics card
has framebuffer support?
I've tried scanning wikipedia, the framebuffer site at sourceforge (which
is virtually content free), and various HOWTOs (which are mostly of the
same vintage as my Matrox card).
Does anybody know if framebuffer is still being maintained?
Thanks in advance for any help!
--
Alan Mackenzie (Nuremberg, Germany).
Aragorn
identifying as Alan Mackenzie wrote...
> I'm looking to acquire a new PC soon. Part of this will clearly have
> to be a graphics card. I would like to get an ATI PCI-express card,
> or something similar.
My advice would be to get an nVidia card instead. The ATi/AMD cards are
good, but their Linux drivers suck. You really don't want to go there,
trust me. ;-)
> I use framebuffer text mode extensively on my current (8 year old)
> Matrox card. How do I go about discovering whether any particular
> graphics card has framebuffer support?
Most graphics adapter cards have a framebuffer driver in the Linux
kernel, either brand- and type-specific, or via the /vesafb/
or /uvesafb/ drivers.
> I've tried scanning wikipedia, the framebuffer site at sourceforge
> (which is virtually content free), and various HOWTOs (which are
> mostly of the same vintage as my Matrox card).
>
> Does anybody know if framebuffer is still being maintained?
Of course it is. ;-) As the matter of fact, I have a GeForce FX-5200 in
this machine here, which uses a 1280*600 pixel (160*60 character)
resolution in character mode, using the /vesafb/ framebuffer driver,
which is the default in most distributions. (The Gentoo documentation
even recommends /vesafb/ over the nVidia-specific framebuffer drivers
if you're using the proprietary nVidia X11 driver.)
--
*Aragorn*
(registered GNU/Linux user #223157)
philo
Yes I agree, the support for NVidia is excellent
Note: With NVidia you have the option to use proprietary drivers
which some purists may frown on. For me...all I care about is:
Does it work?
Alan Mackenzie
> On Sunday 08 November 2009 22:54 in comp.os.linux.setup, somebody
> identifying as Alan Mackenzie wrote...
>> I'm looking to acquire a new PC soon. Part of this will clearly have
>> to be a graphics card. I would like to get an ATI PCI-express card,
>> or something similar.
> My advice would be to get an nVidia card instead. The ATi/AMD cards
> are good, but their Linux drivers suck. You really don't want to go
> there, trust me. ;-)
Ah. OK. I'd heard, vaguely, that nVidia was not cooperating with
producing proper free drivers for their cards. Or something like that.
>> I use framebuffer text mode extensively on my current (8 year old)
>> Matrox card. How do I go about discovering whether any particular
>> graphics card has framebuffer support?
> Most graphics adapter cards have a framebuffer driver in the Linux
> kernel, either brand- and type-specific, or via the /vesafb/
> or /uvesafb/ drivers.
How does one go about associating a particular graphics card (or graphics
chip) with a framebuffer driver for it? Is their some recipe which
doesn't involve the invokation of black magic?
>> I've tried scanning wikipedia, the framebuffer site at sourceforge
>> (which is virtually content free), and various HOWTOs (which are
>> mostly of the same vintage as my Matrox card).
>> Does anybody know if framebuffer is still being maintained?
> Of course it is. ;-)
With all due respect, there's no "of course" about it. Framebuffer's
predecessor, vgatextmode, fell into desuetude 8 or 9 years ago.
> As the matter of fact, I have a GeForce FX-5200 in this machine here,
> which uses a 1280*600 pixel (160*60 character) resolution in character
> mode, ....
Wow!
> ...., using the /vesafb/ framebuffer driver, which is the default in
> most distributions. (The Gentoo documentation even recommends /vesafb/
> over the nVidia-specific framebuffer drivers if you're using the
> proprietary nVidia X11 driver.)
I'm planning on building a Gentoo system when I've got the new box. Back
when I was paying attention to these things, I think the word was that
vesafb was a sluggish, lowest common denominator sort of driver which
would work, sort of, but that a specific driver, such as matroxfb was
really needed.
Thanks for your (very rapid) help!
John Hasler
> My advice would be to get an nVidia card instead.
I currently have an Nvidia card, my first ever. It will be my last.
Ever.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Aragorn
identifying as Alan Mackenzie wrote...
> Aragorn <ara...@chatfactory.invalid> wrote:
>> On Sunday 08 November 2009 22:54 in comp.os.linux.setup, somebody
>> identifying as Alan Mackenzie wrote...
>
>>> I'm looking to acquire a new PC soon. Part of this will clearly
>>> have
>>> to be a graphics card. I would like to get an ATI PCI-express card,
>>> or something similar.
>
>> My advice would be to get an nVidia card instead. The ATi/AMD cards
>> are good, but their Linux drivers suck. You really don't want to go
>> there, trust me. ;-)
>
> Ah. OK. I'd heard, vaguely, that nVidia was not cooperating with
> producing proper free drivers for their cards. Or something like
> that.
Well, that is partly true. Their drivers are still proprietary and
closed source, but the part of the driver which interfaces with the
kernel is supplied as source code, which the /dkms/package can compile
on the fly if you update the kernel and/or the driver.
>>> I use framebuffer text mode extensively on my current (8 year old)
>>> Matrox card. How do I go about discovering whether any particular
>>> graphics card has framebuffer support?
>
>> Most graphics adapter cards have a framebuffer driver in the Linux
>> kernel, either brand- and type-specific, or via the /vesafb/
>> or /uvesafb/ drivers.
>
> How does one go about associating a particular graphics card (or
> graphics chip) with a framebuffer driver for it? Is their some recipe
> which doesn't involve the invokation of black magic?
Well, like I said, /vesafb/ supports most graphics cards, and the
chipset-specific framebuffer drivers are easily identifiable by name.
For instance, /rivafb/ for Riva TNT-based cards, /radeonfb/ for
Radeon-based cards, etc. This is all documented.
For most part however, you'll be quite happy using /vesafb/ as it
supports all modern video adapters and it has very advanced features.
>>> I've tried scanning wikipedia, the framebuffer site at sourceforge
>>> (which is virtually content free), and various HOWTOs (which are
>>> mostly of the same vintage as my Matrox card).
>
>>> Does anybody know if framebuffer is still being maintained?
>
>> Of course it is. ;-)
>
> With all due respect, there's no "of course" about it. Framebuffer's
> predecessor, vgatextmode, fell into desuetude 8 or 9 years ago.
I've been following Linux kernel development for quite a number of years
already, and just about every kernel Changelog has references to
improvements to the various framebuffer drivers in it.
>> As the matter of fact, I have a GeForce FX-5200 in this machine here,
>> which uses a 1280*600 pixel (160*60 character) resolution in
>> character mode, ....
>
> Wow!
Yeah, pretty nifty. :-) I can bump it up to 1600*1200 on this card
here, but then the fonts would be so small on this 19" monitor that
they wouldn't be readable anymore. :-) I do use 1600*1200 for X11
though, with the proprietary nVidia driver.
>> ...., using the /vesafb/ framebuffer driver, which is the default in
>> most distributions. (The Gentoo documentation even recommends
>> /vesafb/ over the nVidia-specific framebuffer drivers if you're using
>> the proprietary nVidia X11 driver.)
>
> I'm planning on building a Gentoo system when I've got the new box.
> Back when I was paying attention to these things, I think the word was
> that vesafb was a sluggish, lowest common denominator sort of driver
> which would work, sort of, but that a specific driver, such as
> matroxfb was really needed.
Hmm... No, I think you are confusing a few things. There *is* an X11
VESA driver which also makes use of the generic framebuffer in the
videocard but this is indeed slow as it doesn't use the GPU. It does
all of its "acceleration" via the main processor on the motherboard and
in RAM, rather than in video RAM.
But this is not the console framebuffer driver, this is something
totally different, which you would only use if your videocard is not
supported by any X11 driver.
> Thanks for your (very rapid) help!
Oh, I was in the vicinity anyway... ;-)
Aragorn
identifying as John Hasler wrote...
> Aragorn writes:
>
>> My advice would be to get an nVidia card instead.
>
> I currently have an Nvidia card, my first ever. It will be my last.
> Ever.
I don't know what card you have, nor do I know what problems you have
had with it to jump to such a conclusion.
You probably have your reasons for saying that, but I have used one ATi
card - actually, a GeCube Radeon 9250 PCI card with 256 MB - and while
this card performed really beautifully in character mode with
the /radeonfb/ framebuffer driver, it totally sucked in X11, both with
the proprietary ATi driver and with the open source driver.
Not only was the driver extremely unstable - and you *are* aware that
these things run in kernel mode, don't you? - but the color rendering
on that card was simply abominable. I have used multiple nVidia cards
in the past and I have never had any such bad results with them as with
the ATi.
Your mileage may vary, but given the cynicism in your reply, I felt the
need to point out some facts from my own experience.
philo
> Aragorn writes:
>> My advice would be to get an nVidia card instead.
>
> I currently have an Nvidia card, my first ever. It will be my last.
> Ever.
Just out of curiosity...what kinds of problems did you have?
which distribution are you using and which card?
Alan Mackenzie
> Aragorn writes:
>> My advice would be to get an nVidia card instead.
> I currently have an Nvidia card, my first ever. It will be my last.
> Ever.
Would you care to expand on the reasons why? Is the card so good that
you'll never need to replace it? ;-)
Alan Mackenzie
> On Sunday 08 November 2009 23:35 in comp.os.linux.setup, somebody
> identifying as Alan Mackenzie wrote...
>> Aragorn <ara...@chatfactory.invalid> wrote:
>>> On Sunday 08 November 2009 22:54 in comp.os.linux.setup, somebody
>>> My advice would be to get an nVidia card instead. The ATi/AMD cards
>>> are good, but their Linux drivers suck. You really don't want to go
>>> there, trust me. ;-)
>> Ah. OK. I'd heard, vaguely, that nVidia was not cooperating with
>> producing proper free drivers for their cards. Or something like
>> that.
> Well, that is partly true. Their drivers are still proprietary and
> closed source, but the part of the driver which interfaces with the
> kernel is supplied as source code, which the /dkms/package can compile
> on the fly if you update the kernel and/or the driver.
Clarification: I can still link this into the kernel, can I? Or do I
have to use it as a module?
>>> Most graphics adapter cards have a framebuffer driver in the Linux
>>> kernel, either brand- and type-specific, or via the /vesafb/ or
>>> /uvesafb/ drivers.
>> How does one go about associating a particular graphics card (or
>> graphics chip) with a framebuffer driver for it? Is their some recipe
>> which doesn't involve the invokation of black magic?
> Well, like I said, /vesafb/ supports most graphics cards, and the
> chipset-specific framebuffer drivers are easily identifiable by name.
> For instance, /rivafb/ for Riva TNT-based cards, /radeonfb/ for
> Radeon-based cards, etc. This is all documented.
Where is it documented? I found quite a lot of documentation for
framebuffer, but little (if anything) understandable without specialised
kernel knowledge. The HOWTO I found was dated 27th February 2000 (or was
it 2001?). Is there some nice comfy documentation which explains things
at the level of somebody just wanting to build fb into his kernel?
> For most part however, you'll be quite happy using /vesafb/ as it
> supports all modern video adapters and it has very advanced features.
OK, that's just great! How could I have found this out for myself?
>> With all due respect, there's no "of course" about it. Framebuffer's
>> predecessor, vgatextmode, fell into desuetude 8 or 9 years ago.
> I've been following Linux kernel development for quite a number of
> years already, and just about every kernel Changelog has references to
> improvements to the various framebuffer drivers in it.
I was over at kernel.org trying to find a "viewgit" program, to see if
anything in the fb area had changed in the last few years. Does
kernel.org have a means of grepping Changelogs? Is there a nice
convenient way of browsing the history of an individual file (without
having to use git, of course)?
>>> As the matter of fact, I have a GeForce FX-5200 in this machine here,
>>> which uses a 1280*600 pixel (160*60 character) resolution in
>>> character mode, ....
>> Wow!
> Yeah, pretty nifty. :-) I can bump it up to 1600*1200 on this card
> here, but then the fonts would be so small on this 19" monitor that
> they wouldn't be readable anymore. :-) I do use 1600*1200 for X11
> though, with the proprietary nVidia driver.
Has fb advanced to the point where I could switch between 128 x 48 and
160 x 60 at runtime?
>> I'm planning on building a Gentoo system when I've got the new box.
>> Back when I was paying attention to these things, I think the word was
>> that vesafb was a sluggish, lowest common denominator sort of driver
>> which would work, sort of, but that a specific driver, such as
>> matroxfb was really needed.
> Hmm... No, I think you are confusing a few things. There *is* an X11
> VESA driver which also makes use of the generic framebuffer in the
> videocard but this is indeed slow as it doesn't use the GPU. It does
> all of its "acceleration" via the main processor on the motherboard and
> in RAM, rather than in video RAM.
That's not really how I'm planning on using the extra processing power
I'll be buying. ;-)
> But this is not the console framebuffer driver, this is something
> totally different, which you would only use if your videocard is not
> supported by any X11 driver.
>> Thanks for your (very rapid) help!
> Oh, I was in the vicinity anyway... ;-)
:-)
Aragorn
identifying as Alan Mackenzie wrote...
> Aragorn <ara...@chatfactory.invalid> wrote:
>> On Sunday 08 November 2009 23:35 in comp.os.linux.setup, somebody
>> identifying as Alan Mackenzie wrote...
>
>>> Aragorn <ara...@chatfactory.invalid> wrote:
>>>> On Sunday 08 November 2009 22:54 in comp.os.linux.setup, somebody
>
>>>> My advice would be to get an nVidia card instead. The ATi/AMD
>>>> cards
>>>> are good, but their Linux drivers suck. You really don't want to
>>>> go there, trust me. ;-)
>
>>> Ah. OK. I'd heard, vaguely, that nVidia was not cooperating with
>>> producing proper free drivers for their cards. Or something like
>>> that.
>
>> Well, that is partly true. Their drivers are still proprietary and
>> closed source, but the part of the driver which interfaces with the
>> kernel is supplied as source code, which the /dkms/package can
>> compile on the fly if you update the kernel and/or the driver.
>
> Clarification: I can still link this into the kernel, can I? Or do I
> have to use it as a module?
The proprietary video driver - and this goes for all proprietary
kernelspace drivers - must always be used as a loadable module, because
the code is supplied in binary form only, so you cannot statically link
that into the kernel.
The part of the driver which is supplied as source code is only an
interface to bind the proprietary binary driver code to the kernel,
because Linus refuses - and for good reasons - to provide for a stable
kernel ABI. As the kernel ABI changes between versions, that part of
the video driver code which must interface with the kernel is therefore
supplied as source code which must be compiled against the running
kernel - either by the video driver vendor's installation tool or by
the /dkms/ tool supplied with most distributions - so as to make it
possible to load the binary driver into the kernel without having to
recompile the entire driver code, which in itself would of course be
the prerogative of the proprietary driver vendors themselves, given
that they won't release the entire source code to their drivers.
The various framebuffer drivers however are GPL'd and are supplied as
part of the vanilla kernel sources, and I believe that most of them are
probably already linked statically into the kernel image in most
distributions, and when I build my own kernels I usually make them
non-modular with regard to everything that's supplied as source code.
>>>> Most graphics adapter cards have a framebuffer driver in the Linux
>>>> kernel, either brand- and type-specific, or via the /vesafb/ or
>>>> /uvesafb/ drivers.
>
>>> How does one go about associating a particular graphics card (or
>>> graphics chip) with a framebuffer driver for it? Is their some
>>> recipe which doesn't involve the invokation of black magic?
>
>> Well, like I said, /vesafb/ supports most graphics cards, and the
>> chipset-specific framebuffer drivers are easily identifiable by name.
>> For instance, /rivafb/ for Riva TNT-based cards, /radeonfb/ for
>> Radeon-based cards, etc. This is all documented.
>
> Where is it documented?
In the kernel documentation, supplied with each kernel sources tarball.
For instance, if you look at the sources for 2.6.31.1, which I happen
to have unpacked here in my home directory, and you peruse
the "./linux-2.6.31.1/drivers/video" directory, you already get a nice
overview of the various framebuffer drivers supported by the vanilla
kernel.
> I found quite a lot of documentation for framebuffer, but little (if
> anything) understandable without specialised kernel knowledge. The
> HOWTO I found was dated 27th February 2000 (or was it 2001?).
Oh yeah, you just gotta love how up to date those HowTos are. :p
> Is there some nice comfy documentation which explains things at the
> level of somebody just wanting to build fb into his kernel?
Well, if you are experienced at building your own kernels, then there's
nothing to it. In the kernel configurator - "menuconfig", "xconfig"
and friends - you'll see a section about video framebuffer support.
Just select "Y" on that and then once more on the framebuffer driver
you wish to build into the kernel - again, I recommend /vesafb/ for
most adapter cards.
The next thing you do is append a "video=vesafb" (along with any
required parameters regarding screen resolution in pixels, vertical
refresh frequency and colordepth) as a kernel boot parameter in GRUB,
or on the "append" line in LILO. Alternatively, you can also use
the "vga=[resolution_code_here]" statement in the bootloader.
>> For most part however, you'll be quite happy using /vesafb/ as it
>> supports all modern video adapters and it has very advanced features.
>
> OK, that's just great! How could I have found this out for myself?
Ehm, by looking around? :-)
>>> With all due respect, there's no "of course" about it.
>>> Framebuffer's predecessor, vgatextmode, fell into desuetude 8 or 9
>>> years ago.
>
>> I've been following Linux kernel development for quite a number of
>> years already, and just about every kernel Changelog has references
>> to improvements to the various framebuffer drivers in it.
>
> I was over at kernel.org trying to find a "viewgit" program, to see if
> anything in the fb area had changed in the last few years. Does
> kernel.org have a means of grepping Changelogs? Is there a nice
> convenient way of browsing the history of an individual file (without
> having to use git, of course)?
I'm afraid I cannot answer you on that. I'm not a developer and I only
peruse the individual Changelog files when a new kernel (or release
candidate) comes out. kernel.org does maintain an extensive archive,
though.
>>>> As the matter of fact, I have a GeForce FX-5200 in this machine
>>>> here, which uses a 1280*600 pixel (160*60 character) resolution in
>>>> character mode, ....
>
>>> Wow!
>
>> Yeah, pretty nifty. :-) I can bump it up to 1600*1200 on this card
>> here, but then the fonts would be so small on this 19" monitor that
>> they wouldn't be readable anymore. :-) I do use 1600*1200 for X11
>> though, with the proprietary nVidia driver.
>
> Has fb advanced to the point where I could switch between 128 x 48 and
> 160 x 60 at runtime?
Hmm... I have never felt the need to try that and so I have not
researched the possibility, but apparently this would indeed be
possible if you use the rather new /uvesafb/ driver. This puts part of
the framebuffer control stuff in userspace, but last I heard it was
still somewhat experimental.
There *is* documentation about it on the web though - that's where I got
my information from - but I have not bookmarked that link or anything.
I think there is a section about it on either SourceForge or on the
Gentoo website.
>>> I'm planning on building a Gentoo system when I've got the new box.
>>> Back when I was paying attention to these things, I think the word
>>> was that vesafb was a sluggish, lowest common denominator sort of
>>> driver which would work, sort of, but that a specific driver, such
>>> as matroxfb was really needed.
>
>> Hmm... No, I think you are confusing a few things. There *is* an
>> X11 VESA driver which also makes use of the generic framebuffer in
>> the videocard but this is indeed slow as it doesn't use the GPU. It
>> does all of its "acceleration" via the main processor on the
>> motherboard and in RAM, rather than in video RAM.
>
> That's not really how I'm planning on using the extra processing power
> I'll be buying. ;-)
Well, unfortunately, this is something I have had to do once upon a time
when a company that I had ordered a custom-built computer from and who
knew very well that I was only going to use the machine with GNU/Linux
had put in a videocard that was not supported with Linux 2.6, nor with
SMP systems - and this *was* an SMP system.
It's a long and sad story, which basically boils down to that I was
conned, and I had no other choice but to accept things as they were and
use the X11 VESA driver instead with that card. Of course, anything
OpenGL-related was simply out of the question. It was slower than
molasses.
The way I see it, there are currently three main choices:
- Intel, which has open source drivers, but these are still in their
infancy, and so far Intel only makes on-board video adapters for
the notebook/laptop market.
- ATi/AMD, which has open source drivers, but these are also still in
their infancy because when AMD purchased ATi, part of the driver code
turned out covered by NDAs and patents, and so in order to open up the
source code, they had to rewrite the drivers from scratch. The
proprietary, binary-only drivers are also still available, but ATi has
always had a far smaller team of Linux driver developers than nVidia
and so their Linux drivers were always crappy as hell. The cards
themselves are good, but what good will that do if the drivers suck?
- nVidia, which has excellent drivers, but those drivers are only
available in binary-only, proprietary form. There is an open source
initiative called /nouveau/ which works pretty well for 2D stuff but
still doesn't offer satisfactory 3D functionality.
If it has to "just work" - and isn't that why you buy a powerful
graphics adapter in the first place? - then nVidia is your best bet, in
my humble opinion, and in the not so humble opinion of many other
GNU/Linux users. ;-)
Aragorn
identifying as Aragorn wrote...
> [...] As the matter of fact, I have a GeForce FX-5200 in this machine
> here, which uses a 1280*600 pixel (160*60 character) resolution in
> character mode, using the /vesafb/ framebuffer driver, [...]
Ehm, there's a typo there... It's 1280*1024 pixels, which translates in
160*60 characters in "text mode" at 16-bit color depth, with
the /vesafb/ driver. In X11, and with the proprietary nVidia driver, I
have a 1600*1200 pixel resolution at 24-bit color depth.
John Hasler
> I currently have an Nvidia card, my first ever. It will be my last.
> Ever.
philo writes:
> Just out of curiosity...what kinds of problems did you have? which
> distribution are you using and which card?
I have a GeForce 6800 GS (I don't need the performance but I got it
cheap). It doesn't work with the nv driver (which would be adequate for
my needs) and the closed-source one is buggy, unsupported, and makes
kernel upgrades a PITA.
In the future I intend to avoid, as far as possible, any hardware
requiring closed-source drivers.
Mark Hobley
> You probably have your reasons for saying that, but I have used one ATi
> card - actually, a GeCube Radeon 9250 PCI card with 256 MB - and while
> this card performed really beautifully in character mode with
> the /radeonfb/ framebuffer driver, it totally sucked in X11, both with
> the proprietary ATi driver and with the open source driver.
Why not just use the open source "radeon" driver (not the radeonfb driver)?
That works just fine.
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Mark Hobley
> I use framebuffer text mode extensively on my current (8 year old) Matrox
> card. How do I go about discovering whether any particular graphics card
> has framebuffer support?
Doesn't the framebuffer just provides a facility to emulate text mode on
a graphics card that is not capable of text mode?
(I know it is also used to overlay a penguin, or display an Ubuntu
startup logo, by switching to graphics mode during the early boot
stages.)
Mark Hobley
> Ah. OK. I'd heard, vaguely, that nVidia was not cooperating with
> producing proper free drivers for their cards. Or something like that.
This is true. I would choose ATI or Intel. (I have seen good results on
both ATI and Intel based cards, and GL 3d graphics work fine on these.)
philo
> I wrote:
>> I currently have an Nvidia card, my first ever. It will be my last.
>> Ever.
>
> philo writes:
>> Just out of curiosity...what kinds of problems did you have? which
>> distribution are you using and which card?
>
> I have a GeForce 6800 GS (I don't need the performance but I got it
> cheap). It doesn't work with the nv driver (which would be adequate for
> my needs) and the closed-source one is buggy, unsupported, and makes
> kernel upgrades a PITA.
>
> In the future I intend to avoid, as far as possible, any hardware
> requiring closed-source drivers.
I'm using the GeForce 8400 gs and it works well for me.
I found that it works just fine without the proprietory drivers...but if
I use them I can pick up a few extra features (that I don't really need).
My experience has also been that if I do not load the proprietory
drivers I can upgrade the kernel and not have any problems with the video.
However, if I use the NVidia installer, the drivers will break with a
kernel upgrade.
I am now using Ubuntu...and if I use Ubuntu's hardware installer,
it will take care of the changes automatically.
There was a similar work-around when I used to use Fedora.
So depending on which distribution you are using...
there might very well be a simple way to get the NVidia drivers to work.
Anyway...though I am not a gamer nor do I care much about video or
animations...I am a photographer...and the extremely crisp and clear
video I get is amazing.
It makes me a firm believer in not only NVidia...but Linux as well.
I multi-boot and on the same machine can also run XP , Vista or Win7
even with the latest NVidia Windows drivers...the video quality is
superior with Linux. (RedHat or Debian-based distributions...to be exact)
Alan Mackenzie
> Alan Mackenzie <a...@muc.de> wrote:
>> I use framebuffer text mode extensively on my current (8 year old)
>> Matrox card. How do I go about discovering whether any particular
>> graphics card has framebuffer support?
> Doesn't the framebuffer just provides a facility to emulate text mode on
> a graphics card that is not capable of text mode?
There's no "just" about it. :-) It also provides a sensible resolution
(say, 128 x 48) for a screen larger than 12". I think all graphic cards
can do 80 x 25 at boot time, but that gets quite tedious quite fast on a
17+" monitor.
> (I know it is also used to overlay a penguin, or display an Ubuntu
> startup logo, by switching to graphics mode during the early boot
> stages.)
Seriously, the compromises a GUI puts on your screen are not wanted when
you're doing pure text work. For this, you want an optimised text
screen. (On this, of course, you run Emacs.)
> Mark.
Nico Kadel-Garcia
Support *of* NVidia is good. Support *by* NVidia has historically
sucked goat rocks, due to their publication of closed source OpenGL
libraries which don't integrate properly with *anyone's* distribution.
Fortunately, 3rd party semi-legal repositories such as Livnia
repackage them into far more sensible releases, including the kernel
widgets. But due to their proprietary licensing, you *cannot* include
the NVidia driver kernel components in a published Linux distribution
because NVidia chooses to continue to work outside the GPL.
Their reasons are understandable, but it makes deploying NVidias in
large numbers of Linux boxes awkward, and complicates support for them.
Nico Kadel-Garcia
> You probably have your reasons for saying that, but I have used one ATi
> card - actually, a GeCube Radeon 9250 PCI card with 256 MB - and while
> this card performed really beautifully in character mode with
> the /radeonfb/ framebuffer driver, it totally sucked in X11, both with
> the proprietary ATi driver and with the open source driver.
I have that card in an odd system without an AGP slot, although I have
the 1 Gig version. I suspect your pain and suffering is significantly
due to its being a remodeled AGP based card shoved in a PCI slot, not
the ATI vendor. It was the only way I could play Half-Life on that
machine, although it was dual-boot and I wasn't pushing the Fedora
Linux hard visually.
> Not only was the driver extremely unstable - and you *are* aware that
> these things run in kernel mode, don't you? - but the color rendering
> on that card was simply abominable. I have used multiple nVidia cards
> in the past and I have never had any such bad results with them as with
> the ATi.
PCI video cards? They're an old technology and these days, a niche
market.
> Your mileage may vary, but given the cynicism in your reply, I felt the
> need to point out some facts from my own experience.
Facts are good. Careful about that PCI difference, though: PCI Express
lends a different set of constraints to the issue.
Thad Floryan
> [...]
> Support *of* NVidia is good. Support *by* NVidia has historically
> sucked goat rocks, due to their publication of closed source OpenGL
> libraries which don't integrate properly with *anyone's* distribution.
> Fortunately, 3rd party semi-legal repositories such as Livnia
> repackage them into far more sensible releases, including the kernel
> widgets. But due to their proprietary licensing, you *cannot* include
> the NVidia driver kernel components in a published Linux distribution
> because NVidia chooses to continue to work outside the GPL.
>
> Their reasons are understandable, but it makes deploying NVidias in
> large numbers of Linux boxes awkward, and complicates support for them.
There's always (at least) two sides to every story. :-)
I found the following on Slashdot a few weeks ago:
" Andy Ritger, who leads the NVIDIA UNIX Graphics Team responsible
" for creating drivers on Linux, FreeBSD and Solaris has answered
" many questions at Phoronix about the state of Linux graphics,
" gaming, and drivers. Ritger shares some interesting facts, such
" as: the Linux graphics driver download rate is 0.5% that of their
" Windows driver downloads at NVIDIA.com; how the Nouveau developers
" are doing an incredible job; creating an AMD-like open-source
" strategy at NVIDIA would be time intensive and unlikely; and
" development problems for the Linux platform. Also commented on are
" new features that may come to their Linux driver within the next
" twelve months.
Article is here: <http://www.phoronix.com/vr.php?view=14278>
The following comment from the above Phoronix article is something
that's an all too common problem with Linux:
" The lack of a stable API in the Linux kernel.
" [...]
" That said, the kernel API churn sometimes seems unfortunate:
" in some cases, working interfaces are broken or replaced
" with broken ones for no seemingly good reason. In some
" other cases, APIs that were previously available to us are
" rendered unusable.
Which brings us to the insight provided by this cartoon:
:-)
Aragorn
identifying as Nico Kadel-Garcia wrote...
> On Nov 8, 5:51 pm, Aragorn <arag...@chatfactory.invalid> wrote:
>
>> You probably have your reasons for saying that, but I have used one
>> ATi card - actually, a GeCube Radeon 9250 PCI card with 256 MB - and
>> while this card performed really beautifully in character mode with
>> the /radeonfb/ framebuffer driver, it totally sucked in X11, both
>> with the proprietary ATi driver and with the open source driver.
>
> I have that card in an odd system without an AGP slot, although I have
> the 1 Gig version.
The machine I was speaking of also has no AGP slot. It's a long story,
but in short, it boils down to this: I ordered a machine with
custom-picked parts and this machine was seriously flawed, so after a
long flamewar in which they were blaming either GNU/Linux - "because it
worked flawlessly under Windows" - or myself or both, I got them to
take it back and inspect it.
It took them another two years to build me a new machine because they
couldn't get the original one working anymore, not even with new
processors and new motherboards - a lot of the lost time was also lost
because they simply didn't feel like helping me - and the new machine
was nothing like what I had ordered, apart from that it was a dual
processor machine with 4 GB of RAM and U160 SCSI disks. It was
supposed to be a workstation and they had picked an at that time not
even so recent anymore Intel server board without an AGP slot.
That machine was also not quite perfect and gradually started to become
more and more unstable. The guy who built the machine was supposed to
come and check it out but he simply wouldn't answer his phone anymore
when he saw that it was me calling him - not that I was stalking him or
anything, and apparently I'm not the only one whose calls he simply
chose to ignore - and the company he was working for when he built the
machine has in the meantime gone bankrupt. I have now handed that
machine over to a specialized firm (which doesn't even do Windows -
they specialize in GNU/Linux and enterprise-grade server and
workstation stuff) for repair, if possible.
>> Not only was the driver extremely unstable - and you *are* aware that
>> these things run in kernel mode, don't you? - but the color rendering
>> on that card was simply abominable. I have used multiple nVidia
>> cards in the past and I have never had any such bad results with them
>> as with the ATi.
>
> PCI video cards? They're an old technology and these days, a niche
> market.
No, the nVidia cards I've used were AGP - several GeForce generations.
The Radeon card is PCI. I've also had one machine with an ATi AGP
card - this was when AGP was still a very new technology - but that
card could not be compared to anything recent.
It wasn't that bad, though. It only had 4 MB of memory and I believe it
was based upon the Mach64 chip. I think it was called ATi Rage Pro
Turbo or something.
Mark Hobley
> There's no "just" about it. :-) It also provides a sensible resolution
> (say, 128 x 48) for a screen larger than 12". I think all graphic cards
> can do 80 x 25 at boot time, but that gets quite tedious quite fast on a
> 17+" monitor.
Right. That is interesting. Some video cards can do that at hardware
level. I presumed that the video driver would do that without the framebuffer,
but I have not tested this. I remember when I used to write dos extenders that
I could switch to 128 x 48 just by running a simple video bios request without
having to run any kind of framebuffer.
> Seriously, the compromises a GUI puts on your screen are not wanted when
> you're doing pure text work.
I agree. I do not run a framebuffer here, and my display works extremely
well without a framebuffer (and without a penguin). That is why I am
curious as to why you asked about the framebuffer. I have never really
used it and my PCs have been working just fine.
Maurice Batey
> nVidia, which has excellent drivers, but those drivers are only
> available in binary-only, proprietary form. There is an open source
> initiative called /nouveau/ which works pretty well for 2D stuff
So if I wanted to use nVidia but avoid the drivers breaking after
any kernel change, I could simply choose to use the Linux-provided
'nouveau' drivers if I don't care about 3D?
(My current card is a Radeon 9600, with which I've had no problem
whatsoever with Mandriva or SuSE, but I'm wondering which card to use
in my next PC that will just work and keep on working...
No fancy graphics requirements here...)
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
John Hasler
> So if I wanted to use nVidia but avoid the drivers breaking after any
> kernel change, I could simply choose to use the Linux-provided
> 'nouveau' drivers if I don't care about 3D?
Description: X.Org X server -- Nouveau display driver (experimental)
This driver for the X.Org X server (see xserver-xorg for a further description)
provides support for NVIDIA Riva, TNT, GeForce, and Quadro cards.
.
Note that these drivers are INCOMPLETE, and are only really useful for testing
at this point. People needing a stable driver should use the "nv" driver
instead. Although the upstream nouveau drivers provide some 3D support, these
packages do not include the necessary files. Users requiring 3D support should
use the non-free "nvidia" driver.
.
This package is built from the FreeDesktop.org xf86-video-nouveau driver.
.
Users wishing to install these drivers should first use module-assistant to
build the drm kernel modules (via ``module-assistant auto-install drm'').
Homepage: http://nouveau.freedesktop.org/wiki/
Maurice Batey
> Nouveau display driver (experimental)
> ...
> Note that these drivers are INCOMPLETE, and are only really useful
> for testing at this point. People needing a stable driver should
> use the "nv" driver
Thanks, John!
By '"nv" driver' I assume you mean the driver that has to be
obtained from nVidia, and breaks if the kernel changes.
In this case I shall continue to steer well clear of nVidia cards...
John Hasler
> By '"nv" driver' I assume you mean the driver that has to be obtained
> from nVidia, and breaks if the kernel changes.
No.
Package: xserver-xorg-video-nv
Description: X.Org X server -- NV display driver
This driver for the X.Org X server (see xserver-xorg for a further description)
provides support for NVIDIA Riva, TNT, GeForce, and Quadro cards.
.
Note that this is not the same as the binary-only 'nvidia' driver, which
adds 3D support, but is binary-only and not supported.
.
More information about X.Org can be found at:
<URL:http://www.X.org>
<URL:http://xorg.freedesktop.org>
<URL:http://lists.freedesktop.org/mailman/listinfo/xorg>
.
This package is built from the X.org xf86-video-nv driver module.
Darren Salt
[snip]
> I was over at kernel.org trying to find a "viewgit" program, to see if
> anything in the fb area had changed in the last few years. Does kernel.org
> have a means of grepping Changelogs? Is there a nice convenient way of
> browsing the history of an individual file (without having to use git, of
> course)?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree
Just follow the links...
[snip]
> Has fb advanced to the point where I could switch between 128 x 48 and
> 160 x 60 at runtime?
fbset should cope with that, so long as the requisite modes (measured in
pixels, not characters) are available.
[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more. PRODUCE LESS CARBON DIOXIDE.
007 of Borg: Licence to Assimilate.
Nico Kadel-Garcia
> On Monday 09 November 2009 06:35 in comp.os.linux.setup, somebody
> identifying as Nico Kadel-Garcia wrote...
>
> > On Nov 8, 5:51 pm, Aragorn <arag...@chatfactory.invalid> wrote:
>
> >> You probably have your reasons for saying that, but I have used one
> >> ATi card - actually, a GeCube Radeon 9250 PCI card with 256 MB - and
> >> while this card performed really beautifully in character mode with
> >> the /radeonfb/ framebuffer driver, it totally sucked in X11, both
> >> with the proprietary ATi driver and with the open source driver.
>
> > I have that card in an odd system without an AGP slot, although I have
> > the 1 Gig version.
>
> The machine I was speaking of also has no AGP slot. It's a long story,
> but in short, it boils down to this: I ordered a machine with
> custom-picked parts and this machine was seriously flawed, so after a
> long flamewar in which they were blaming either GNU/Linux - "because it
> worked flawlessly under Windows" - or myself or both, I got them to
> take it back and inspect it.
OK. So given your other problems with this system, I don't think it's
fair to blame ATI for anything involving it, and perhaps you might
consider the recommendations of others of ATI more seriously. Does
that seem reasonable to you?
Aragorn
You make it sound as if you're taking this personally. Well, yes, it
does sound reasonable to me, but so do the tons of reports on how bad
the ATi drivers for GNU/Linux are - note: I say "drivers for
GNU/Linux", not the cards themselves. I have no doubt that the video
adapters themselves are of high quality.
In other words, just because that machine was flawed doesn't mean that
my problems with the ATi drivers were the result of these flaws,
considering that many more people are complaining about the poor
quality of ATi drivers, and I doubt that all of their machines are
flawed as well.
Baho Utot
I have not seen the problems that "others report".
I use ATI an currently have a 4670HD, works flawlessly with the radeon,
radeonhd driver or catalyst drivers.
No problems.
Nico Kadel-Garcia
Well, if I disagree with someone whose opinion I take seriously, such
as yourself, I want to make sure we disagree for good reasons.
> In other words, just because that machine was flawed doesn't mean that
> my problems with the ATi drivers were the result of these flaws,
> considering that many more people are complaining about the poor
> quality of ATi drivers, and I doubt that all of their machines are
> flawed as well.
No, but it was also a PCI card (which can cause serious adventures),
and an otherwise problematic system whose problems you've not
explained. So I'm gently questioning your claim that the problems were
due to the ATI drivers, especially because I used the model of card
myself, successfully.
Aragorn
Oh okay, fair enough then. ;-) Thanks for taking me serious, by the
way. :-)
>> In other words, just because that machine was flawed doesn't mean
>> that my problems with the ATi drivers were the result of these flaws,
>> considering that many more people are complaining about the poor
>> quality of ATi drivers, and I doubt that all of their machines are
>> flawed as well.
>
> No, but it was also a PCI card (which can cause serious adventures),
> and an otherwise problematic system whose problems you've not
> explained.
Well, it has lots of issues and it seems to be building up. It started
with occasionally having difficulties at recognizing all four virtual
CPUs - it's a dual Xeon with hyperthreading - and then whereas this
would at first rather be spurious, it would become commonplace later on
to only detect three out of the four virtual CPUs, and reporting things
like "3 processors of 7 found". Seven? It's a twin-socket SMP board,
and those processors are Pentium 4-based 32-bit Xeons with
hyperthreading and a 400 MHz front side bus. They're not even
dualcores.
Then it started spitting out SCSI errors - the original Adaptec U160
SCSI adapter and both IBM U160 SCSI disks have in the meantime been
replaced by a brandnew Adaptec 2130-SLP U320 SCSI RAID controller card
with two brandnew Hitachi 73 GB U320 disks - and the last thing it did
before I finally pulled the power plug and parked it in the living room
somewhere (by lack of place here in my computer room) was fill up the
BIOS ECC log with errors.
The machine had been running Mandrake 9.2 and 10.0, both purchased
PowerPack DVD editions, and both with different generations of
custom-built vanilla 2.6 kernels. When the U320 disks and the RAID
controller were put in, I threw on CentOS 5.3 but I haven't built a
custom kernel for it.
The machine is currently being examined and tested by professionals. A
preliminary report was that they had gotten it to recognize all four
virtual CPUs but whether this was haphazard or whether they've repaired
something, I don't know yet. My contactee at that company is not the
guy working on that machine, and another machine of mine which he is
currently working on - expanding, not repairing - has priority, so I
haven't further inquired about the other one yet. I don't want to put
any pressure on these people. They know what they're doing and they're
very forthcoming - unlike the company that built the faulty server - so
I'm giving them the time.
> So I'm gently questioning your claim that the problems were
> due to the ATI drivers, especially because I used the model of card
> myself, successfully.
Well I haven't given up on that card yet. In fact, I have put it into a
brandnew server - the one being equiped with some extra stuff as
mentioned above - for use (in character mode only) in the Xen dom0.