My guess is that you simply forgot to install the correct (proprietary) firmware for your card.

Add the non-free repository to /etc/apt/sources.list (if you like, you could add the contrib repo while you're at it). Don't forget the update repos. It should look something like this, basically you just add non-free (and eventually contrib) at the end of each line:

1deb http://httpredir.debian.org/debian jessie main contrib non-free
2deb-src http://httpredir.debian.org/debian jessie main contrib non-free
3
4deb http://httpredir.debian.org/debian jessie-updates main contrib non-free
5deb-src http://httpredir.debian.org/debian jessie-updates main contrib non-free
6
7deb http://security.debian.org/ jessie/updates main contrib non-free
8deb-src http://security.debian.org/ jessie/updates main contrib non-free

Update the package lists:

1apt-get update

Install the non-free firmware package, the necessary firmwares shoult be in it:

1apt-get install firmware-linux-nonfree

...and reboot when it's done. That should be it 😀

kaputnik wrote:

My guess is that you simply forgot to install the correct (proprietary) firmware for your card. […]
Show full quote

My guess is that you simply forgot to install the correct (proprietary) firmware for your card.

Add the non-free repository to /etc/apt/sources.list (if you like, you could add the contrib repo while you're at it). Don't forget the update repos. It should look something like this, basically you just add non-free (and eventually contrib) at the end of each line:

Copy code to clipboard

1deb http://httpredir.debian.org/debian jessie main contrib non-free
2deb-src http://httpredir.debian.org/debian jessie main contrib non-free
3
4deb http://httpredir.debian.org/debian jessie-updates main contrib non-free
5deb-src http://httpredir.debian.org/debian jessie-updates main contrib non-free
6
7deb http://security.debian.org/ jessie/updates main contrib non-free
8deb-src http://security.debian.org/ jessie/updates main contrib non-free

Update the package lists:

Copy code to clipboard

1apt-get update

Install the non-free firmware package, the necessary firmwares shoult be in it:

Copy code to clipboard

1apt-get install firmware-linux-nonfree

...and reboot when it's done. That should be it 😀

Thank for your post. I already have installed that package when I tried the Radeon R100 and it was looking for that microcode firmware. 😵
I begin to think something is also related to the "alias" that call the module from the xorg conf. I didn't install any other drivers only the one already inside xorg.
For example the S3 Savage 4 (Diamond) I tried, I put "savage" in the xorg.conf and it boot with vmware driver and in the log it say it couldn't find the savage module so it unloaded it. (?) The savage ko and so file are in their directories from where is it trying to load it?

i do wonder a bit what is going on here: drivers now are in kernel space, optimally as .ko modules which are then loaded automagically during boot (firmware required at this point), later xorg just takes over drawing - thats all; xorg.conf is a thing of the past;

386SX wrote:

Thank for your post. I already have installed that package when I tried the Radeon R100 and it was looking for that microcode firmware. 😵
I begin to think something is also related to the "alias" that call the module from the xorg conf. I didn't install any other drivers only the one already inside xorg.
For example the S3 Savage 4 (Diamond) I tried, I put "savage" in the xorg.conf and it boot with vmware driver and in the log it say it couldn't find the savage module so it unloaded it. (?) The savage ko and so file are in their directories from where is it trying to load it?

Oh, so you already got it installed. Have you tried simply deleting your xorg.conf, to see if Xorg's automatic hardware probing does the trick?

I'm far from an expert on the subject as the only Debian installation I'm using on a daily basis is a CLI only server one, but as mrau mentions, in most cases xorg.conf is a thing of the past. Nowadays it's only used for customization, or if the hardware probing fails for some reason.

kaputnik wrote:

I'm far from an expert on the subject as the only Debian installation I'm using on a daily basis is a CLI only server one, but as mrau mentions, in most cases xorg.conf is a thing of the past. Nowadays it's only used for customization, or if the hardware probing fails for some reason.

This is indeed the case, it should autodetect just fine.
For Nvidia you do need to install one of the driver sets (either Legacy or current) depending on the card.
For AMD/Ati you could follow the same route or just go with the opensource one (not sure how it covers current cards).

Drivers used to link libraries and stuff, mixing Nvidia and AMD is not the way to go.

elod wrote:

For AMD/Ati you could follow the same route or just go with the opensource one (not sure how it covers current cards).

i would worry more about old cards frankly, on an r200 in the past performance went down to hell on software update

For the R100, R200 and TNT/Geforce I almost had no problems and, beside the microcode firmware nonfree update, now they are almost functional without any config. It also configure the opengl acceleration with the right mesa dri drivers. But for older cards it seems that the boot is more complicated. I would expect the savage cards to load just as simple as the others but it load vmware instead same thing for other cards like the Kyro2 I'd like to use or a Mystique pci, or the Rage128 (that show also some graphic problem in desktop with two different cards).
I created the xorg.conf cause without I couldn't get any acceleration from the cards, only some clear software rendering.
In the system profiler and benchmark, when I see vmware gallium driver I know something was wrong at boot.

mrau wrote:

i do wonder a bit what is going on here: drivers now are in kernel space, optimally as .ko modules which are then loaded automagically during boot (firmware required at this point), later xorg just takes over drawing - thats all; xorg.conf is a thing of the past;

That's true only for cards that have full KMS support, which at this point is only current on-CPU Intel and some AMD Radeons, AFAIK. There might be KMS for Matrox G200/G400 cards too, since specs for those have been available to kernel devs for a long time. Most others need a userspace driver in Xorg along with a kernel module to handle direct rendering for 3D acceleration. The userspace driver handles all the 2D acceleration, though. Xorg.conf is mostly a thing of the past - though you can still use it - because X correctly autodetects most things now, not because the kernel fully handles the device.

Note that anything that uses the fbdev driver will have only as much acceleration as the kernel framebuffer module provides, which varies, and you'll never get 3D with that. There's also the "vesa" driver, which works with almost anything modern, but has no acceleration outside of any hacks the card's own VESA BIOS does.

For example, trying the Savage 4 I get this on Xorg.0.log:

(II) LoadModule: "savage"
(WW) Warning, couldn't open module savage
(II) UnloadModule: "savage"
(II) Unloading savage
(EE) Failed to load module "savage" (module does not exist, 0)

and the it try other until the vbe driver and it go to the desktop I think with a software renderer (I see Gallium 0.4 on llvmpipe etc.. of Vmware in display info).

Why? savage_drv.so and .ko are in the directories where I find radeon and nouveau...

386SX wrote:

For example, trying the Savage 4 I get this on Xorg.0.log: […]
Show full quote

For example, trying the Savage 4 I get this on Xorg.0.log:

(II) LoadModule: "savage"
(WW) Warning, couldn't open module savage
(II) UnloadModule: "savage"
(II) Unloading savage
(EE) Failed to load module "savage" (module does not exist, 0)

and the it try other until the vbe driver and it go to the desktop I think with a software renderer (I see Gallium 0.4 on llvmpipe etc.. of Vmware in display info).

Why? savage_drv.so and .ko are in the directories where I find radeon and nouveau...

The .ko should go where the other kernel modules are - (/lib/modules/<kernel version>), so if they're in the same directory as the radeon and noveau .so files, it's in the wrong place. savage_drv.so should be there, though. I'm not sure how the vmware driver is getting pulled in at all: are you running this in a VM with PCI passthrough?

Also, double-check permissions, unless you're running this as root.

I don't use any vmware application, is a fresh debian installation. I am not expert in debian but I think that is a driver that is labeled "vmware" as provider when no other correct drivers are found just like a generic "svga driver" of the old win systems. Maybe is the same that is used in the virtual systems to emulate a graphic card.
I don't boot as root, only in terminal when needed. How and which permission should I check?
Thank

Ah, I understood the permission problem you're saying, I've added my user to video group with usermod command, I'll try later and update if it works. 😉

386SX wrote:

I don't use any vmware application, is a fresh debian installation. I am not expert in debian but I think that is a driver that is labeled "vmware" as provider when no other correct drivers are found just like a generic "svga driver" of the old win systems. Maybe is the same that is used in the virtual systems to emulate a graphic card.
I don't boot as root, only in terminal when needed. How and which permission should I check?
Thank

Also, look at the permissions/mode set on the savage_drv.so file itself (ls -lha <filename>). Make sure it's read/execute for world and/or a group that your user is in (or the user that X runs as, if it's setuid/setgid, which it usually isn't, but...)

The vmware driver bit is weird - the generic driver should be "vesa", actually. Virtualbox and VMWare have their own odd virtual graphics hardware, which is mostly VESA-compatible for 2D, but has its own accelerated driver that hooks into acceleration in the host graphics system (Windows, Mac, X, or OpenGL for the 3D bits). I have no idea why it'd be invoking that.

Some more tests, I tried the savage again but it still can't load the module. But with the G450 and the Voodoo3 it seems from the log that it loaded the module ok. Still I have for the Opengl one the vmware gallium renderer loaded. For the radeon and nouveau drivers, the opengl driver was loaded automatically correct but not with these cards.

At the end I tried different cards enabling DRI and various acceleration and it seems to load eventually the modules but even when everything seems started ok, performances seems far from ok. Radeon open driver or the geforce one, seems to performs better and with the right opengl libs.

I was trying also to make the powernow feature of the athlon xp mobile cpu to correctly run but it has problem reading the PST table of the bios that probably support the cpu (it's seen as mobile at boot) but not in the way linux is expecting (for example the k6-2+ version ondemand powernow runs perfectly). So the cpu is running fixed at its maximun frequency without scaling down.
I've seen there was a patch with some code to inser a fake pst table fot the cpu but I was hoping something easier to try.