openSUSE 13.2, fglrx: Alt-Fx terminals use 80x25 text mode only

Hi all,

up to 13.1 there was no issue with the terminal screens and my Radeon HD 7870 (running under fglrx). Now, with 13.2, the terminals seem to use the good old 80x25 text mode instead of the framebuffer. I tried different settings for the video mode in the kernel boot line, but to no avail.

This can already be seen during booting. When I use radeon (kernel parameters unchanged), the screen switches to framebuffer mode as expected before the boot output appears. With fglrx, the screen stays in the 80x25 text mode.

Any ideas how to get a framebuffer display with fglrx?

I already thought about dropping the fglrx in favor of radeon, but despite some claims that the radeon driver has significantly improved, it is largely useless for me, sadly. The first game I tried (Antichamber) was already unplayable because lines and text were not shown in the scenes. I wonder whether the radeon devs actually test their driver against some current games.

Problem with games is that they often use graphic extensions that may not be available to the OS developers. It is unclear how you “tried different settings for the video mode in the kernel boot line” What option and what procedure did you use??

YaST offers settings for the bootloader; tab “Kernel parameters”, text field “VGA mode”. I changed them to different values, rebooted, but each time I’m getting the 80x25 text output.

In contrast, using the OS radeon driver, there was no issue at all; the framebuffer output was available at the very same settings where it failed for fglrx.

As for the games, I’m not blaming the devs to be sloppy, yet I’m a bit disappointed that the radeon driver is currently no option for me.

It is not sloppy it is features that the opensource driver may not be able to use because of patents or other IP issues.

Here is a lit that comes up in Eternal Lands game

[17:54:08] GL_ARB_multitexture extension found, using it.
[17:54:08] GL_ARB_texture_env_combine extension found, using it.
[17:54:08] GL_EXT_compiled_vertex_array extension found, using it.
[17:54:08] GL_ARB_point_sprite extension found, using it.
[17:54:08] GL_ARB_texture_compression extension found, using it.
[17:54:08] GL_EXT_texture_compression_s3tc extension found, using it.
[17:54:08] GL_SGIS_generate_mipmap extension found, using it.
[17:54:08] GL_ARB_shadow extension found, using it.
[17:54:08] GL_ARB_vertex_buffer_object extension found, using it.
[17:54:08] GL_EXT_framebuffer_object extension found, using it.
[17:54:08] GL_EXT_draw_range_elements extension found, using it.
[17:54:08] GL_ARB_texture_non_power_of_two extension found, using it.
[17:54:08] GL_ARB_fragment_program extension found, using it.
[17:54:08] GL_ARB_vertex_program extension found, using it.
[17:54:08] GL_ARB_fragment_shader extension found, using it.
[17:54:08] GL_ARB_vertex_shader extension found, using it.
[17:54:08] GL_ARB_shader_objects extension found, using it.
[17:54:08] GL_ARB_shading_language_100 extension found, using it.
[17:54:08] GL_ARB_texture_mirrored_repeat extension found, NOT using it...
[17:54:08] GL_ARB_texture_rectangle extension found, NOT using it...
[17:54:08] GL_EXT_fog_coord extension found, NOT using it...
[17:54:08] Couldn't find the GL_ATI_texture_compression_3dc extension, not using it...
[17:54:08] Couldn't find the GL_EXT_texture_compression_latc extension, not using it...
[17:54:09] Using vertex program for actor animation.

Some of those extensions are simply not supported in the OS drivers AMD or NVIDIA. If I use the nouveau driver I get a naked character on an empty plain with out trees house or other actors. But render speed is fine so 3D accel is more or less up to the proprietary driver.

I don’t know for sure why those extensions are not in the OS drivers but a good guess is patents.

OK, here’s some research from me:

  1. As for the rendering issues of radeon in Antichamber, this is obviously the effect of the missing S3TC (texture compression), as you said, patent-infested. (I just can’t eat enough for what I’d like to throw up.) After installing an additional library and forcing Steam to use it, Antichamber renders correctly again. I was pointed to that issue because Portal also refused to load, but actually complained about the missing feature.

Still, both Portal and Antichamber are noticeably jerky when turning around, so radeon is still not reaching up to the performance of fglrx. You can see it most obviously in Antichamber when watching the “Riot Balls”.

  1. Framebuffer issue:

When radeon is installed, dmesg delivers:

    0.000000] Console: colour VGA+ 80x25
    0.000000] console [tty0] enabled
    3.691828] fbcon: radeondrmfb (fb0) is primary device
    3.719514] Console: switching to colour frame buffer device 240x75
    3.722873] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device

When fglrx is installed, the line “switching to colour frame buffer” is missing.

In Xorg.0.log I could find this:

     7.091] (II) fglrx(0): pEnt->device->identifier=0xa45be0
     7.091] (II) fglrx(0): === [xdl_xs116_atiddxPreInit] === begin
     7.091] (II) fglrx(0): FB driver is not enabled
     7.091] (II) Loading sub module "vgahw"
     7.091] (II) LoadModule: "vgahw"
     7.092] (II) Loading /usr/lib64/xorg/modules/
     7.092] (II) Module vgahw: vendor="X.Org Foundation"

So this seems to be the source of the problem. Anything I can do about it? I mean, I can live with that, usually I do not use the terminals but use konsole within KDE, but I do feel better when the system is running flawlessly.