Suse 12.3 ATI rage mobility M4 AGP display problem

Hello

I used Suse 10.1 some years ago on the same Inspiron 8000, without any display problem, and full satisfaction.

Yesterday I did a Suse 12.3 fresh install.
I have a display problem, screen is made of 3 tiles overlapping in horizontal direction, with a strange mouse behavior.

The only mode where display is correct is debug mode (last entry in Grub start choices)

I did some search .
I found: https://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/advanced-how-faq-read-only/438705-opensuse-graphic-card-practical-theory-guide-users.html

but I am not sure that this fully applies to 12.3 version ?

  1. there is no more xorg.conf
  2. There are files in /etc/X11/xorg.conf.d/ than you can edit to force use of a driver like vesa or r128 or ati
  3. I tried vesa, as indicated in the link above, but Suse don’t end booting anymore and stay stuck at xserver launch step.

I am a little bit anxious about what to try next.
Any help, advice or useful link will be welcomed.

Thanks

Caty

  • you can still use an xorg.conf file if you want, but you generally don’t need to
  • yes, you can use the xorg.conf.d/ files, but (again) usually you don’t need to
  • can you post your /var/log/Xorg.0.log file to suse paste and then provide a link: SUSE Paste … I suspect you’re having EDID issues with the monitor
  • just a quick note, there is no longer a 3D driver available for your device (so all 3D will been done in software/cpu) … practical consequence of this is that desktop effects or desktops like GNOME will give you a terrible user experience, so make sure not to use them

Thanks for answering so fast !
So I did a normal start that gives me the scrambled screen
here is the suse paste: SUSE Paste

In order to compare I did next a safe start (debug mode) that gives normal screen
SUSE Paste

i hope you may find some tracks in above pastes

By the way I use KDE…

Thanks

Caty

Its a bit out of date. I’ve been asked to update it, but that takes a lot of time, and as a volunteer I have been short of time of late.

I note from a old Phoronix article that support for the R128 (which is the driver traditionally used in the past for the rage hardware) has been stopped: [Phoronix] Legacy Mesa Drivers Receive Their Death Sentence](Legacy Mesa Drivers Receive Their Death Sentence - Phoronix)

Its clear from the many R128(0) entries in the Xorg.0.log file that an attempt is being made to load an old version of the rage driver. As noted in the Phoronix article, this won’t work well with Mesa.

I looked at the Xorg.0.log and saw these warnings :


    39.331] (WW) R128(0): Unable to estimate virtual size
......
    39.389] (II) R128(0): Acceleration of RENDER operations will be enabledupon successful loading of DRI and EXA
    39.402] (WW) R128(0): Static buffer allocation failed -- need at least 9216 kB video memory
......
    39.422] (==) R128(0): DPMS enabled
    39.422] (WW) R128(0): Direct rendering disabled
......

but I don’t know enough about that to be precise in any recommendations.

I note some users with different older AMD hardware (such as x200) had to perform custom edits to their /etc/X11/xorg.conf.d/50-device.conf file to get the radeon driver working for them (see post #8 here: https://forums.opensuse.org/english/get-technical-help-here/hardware/470304-monitor-flashing-ati-card-issue.html) where they disabled both dri and dri2. They also had to specify an appropriate modeline for their monitor in the /etc/X11/xorg.conf.d/50-monitor.conf file, where they needed to use the program ‘cvt’ to obtain the necessary mode line information.

Its possible you may need to do the same … and this is speculation on my part.

Possibly try something like this in the /etc/X11/xorg.conf.d/50-device.conf


Section "Device"
  Identifier "Default Device"

  Driver "r128"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"


EndSection

Section "Module"
  Disable "dri"
  Disable "dri2"
EndSection

I may have the driver entry wrong. Maybe it should be “R128” instead of “r128” (I don’t know). That is very wild speculation on my part. Still I am curious if it will work.

The safe start gets you the low performance FBDEV driver. Note instead of booting to the safe settings, you could also likely boot with ‘nomodeset’ boot code which may accomplish the same. I don’t have a guide to point to, but take a look at this: https://forums.opensuse.org/blogs/jdmcdaniel3/how-start-opensuse-12-2-grub-2-into-run-level-3-112/ and instead of entering ‘3’ , enter ‘nomodeset’.

More speculation, … an alternative may be something like:


Section "Device"
  Identifier "Default Device"

  Driver "r128"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

  Option  "NoAccel"  "True"
EndSection


Again I may have the driver entry wrong and maybe it should be “R128” instead of “r128” (I don’t know).

Since this is rather wild ‘try this’ , not work , ok then ‘try that’, no … etc … speculation on my part, it may be just better to wait for someone who actually knows the solution (or who has a better idea than I) to chime in and help.

… a further note … at the risk of stating the obvious.

In a terminal, typing the command:


man r128

will provide guidance on the various options available for the r128 driver. I don’t have sufficient experience with this hardware to recommend which, if any, might help if applied.

The primary problem is:

    39.315] (II) R128(0): VESA VBE DDC read failed
  • there is an outside chance (though I’m not expecting it) that the generic modesetting driver is wrecking some havoc, so you could add it to your modprobe blacklist
  • do NOT disable the DRI module if you wish to use the modicum of 2D acceleration that is available
  • most likely you will have to set a modeline (this is one of those cases where using the xorg.confd/ comes into play) … you could probably copy that used by the generic fbdev driver in the recovery/safe mode – see the lines 172 of the 2nd paste file … also see: (II) R128(0): VESA VBE DDC read failed - Google Suche (first hit should give you examples)
  • you seem to have a evdev driver issue for one of your input devices … I’ll let some one else address that
  • be sure to turn off Desktop Effects on KDE

Clarification: There is no longer a dri driver (i.e. 3D driver), as it (r128_dri.so) was stripped out of Mesa, along with all the other legacy dri1 drivers.

There are, however, still the kernel DRM driver (r128.ko) and the userspace xorg driver (r128_drv.so). The DRM does not support KMS.

Its clear from the many R128(0) entries in the Xorg.0.log file that an attempt is being made to load an old version of the rage driver.
No, this is incorrect, nor should we expect X to report loading of the dri driver. We can, however, find allusion to the fact that the dri driver is not present by the AIGLX and GLX lines:

    39.571] (II) AIGLX: Screen 0 is not DRI2 capable
    39.571] (II) AIGLX: Screen 0 is not DRI capable
   40.118] (II) AIGLX: Loaded and initialized swrast
    40.118] (II) GLX: Initialized DRISWRAST GL provider for screen 0


Possibly try something like this in the /etc/X11/xorg.conf.d/50-device.conf

Section “Module”
Disable “dri”
Disable “dri2”
EndSection

Disabling the DRI module will disable the EXA support:


    38.509] Initializing built-in extension XFree86-**DRI**
    38.509] Initializing built-in extension DRI2
...
    39.389] (II) R128(0): Acceleration of RENDER operations will be enabledupon successful** loading of DRI **and EXA
    39.403] (II) R128(0): Loading EXA module...
...
    39.422] (II) R128(0): EXA Acceleration enabled

I may have the driver entry wrong. Maybe it should be “R128” instead of “r128” (I don’t know).
Should not matter.

The safe start gets you the low performance FBDEV driver. Note instead of booting to the safe settings, you could also likely boot with ‘nomodeset’ boot code which may accomplish the same. I don’t have a guide to point to, but take a look at this: https://forums.opensuse.org/blogs/jdmcdaniel3/how-start-opensuse-12-2-grub-2-into-run-level-3-112/ and instead of entering ‘3’ , enter ‘nomodeset’.
It (using nomodeset here) will have no effect.

I did puzzle over the AIGLX entries in the Xorg.0.log file that were than in addition to the dozens of R128(0) entries. Inside (approx) one of the set of lines you quoted, I note this:


    39.422] (WW) R128(0): Direct rendering disabled
    39.423] (==) RandR enabled
    39.571] (II) AIGLX: **Screen 0 is not DRI2 capable**
    39.571] (II) AIGLX: **Screen 0 is not DRI capable**

where in addition to quoting the Phoronix article about the R128 support being stripped out of Mesa, I should have noted those lines were one reason why I suggested the /etc/X11/xorg.conf.d/50-device.conf file edit to disable DRI and DRI2 with :


Section "Device"
  Identifier "Default Device"

  Driver "r128"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

EndSection

Section "Module"
  Disable "dri"
  Disable "dri2"
EndSection

… but that was speculation on my part, so I don’t “know” if that is appropriate. I was just a suggestion to see if it may be an improvement over the current FBDEV with the safe settings selection.

The other suggestion to set ‘no acceleration’ came from another GNU/Linux distribution thread on the r128, where the user noted vaguely similar symptoms to the OP and advised that allowed them to boot to a GUI with the R128, but while they achieved a GUI the performance was rather bad.


Section "Device"
  Identifier "Default Device"

  Driver "r128"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

  Option  "NoAccel"  "True"
EndSection

@ catyburtyt, I recommend you go with any suggestions of Tyler_K, as I have no direct experience with your hardware, and no in depth experience in graphics, and my posts are based more on speculation and surfing, rather than hard knowledge/experience. Further, I should state that the very general graphics guides I put together for openSUSE were done in the past mainly because no one else had produced such a guide, and at the time something was better than nothing. I’ve always hoped someone more knowledgeable than I would take over author ship of the guides:

where I note neither of those specifically address the R128.

Thanks a lot oldcpu and Tyler_K, you gave me a lot of tracks.

Here are some results :

As predicted nomodeset don’t change scrambled screen

I did not disabled dri.

Driver “r128” or Driver “ati” in /etc/X11/xorg.conf.d/50-device.conf don’t change scrambled screen

Turning out desktop effects don’t change scrambled screen but speed up a lot reaction time from mouse click.

Driver “fbdev” in /etc/X11/xorg.conf.d/50-device.conf makes normal start, with normal screen but medium resolution …. As fallback

Now I have a question: you wrote there is an outside chance (though I’m not expecting it) that the generic modesetting driver is wrecking some havoc, so you could add it to your modprobe blacklist
I am a little lost : how to find the name of generic modesetting driver to put in blacklist ?

And I still have to dig https://wiki.ubuntu.com/X/Troubleshooting/Resolution you provided.

caty

The driver’s name is modesetting_drv.so, however, what I wrote is wrong – the modesetting driver, like all the other Xorg drivers, is userspace, whereas modprobe deals with kernel modules. So, in that case, a udev rule would likely do the trick. However, instead of monkeying around with that (udev rules), an even simpler thing would be to just uninstall the package the driver comes in (xf86-video-modesetting). lol! In any regard, as I mentioned, I don’t expect there to be any change in behaviour without the modesetting driver being loaded.

oldcpu’s suggestion of turning off the accel is worth a shot too, to see if it is causing the problem – the EXA support for the r128 xorg driver is relatively new (summer of '2012), so perhaps its inclusion has inadvertently affected other behaviour.

A quick google shows that (while I did not look at it closely) someone else using openSUSE has recently had similar troubles with it: opensuse-factory - Re: 12.3 RC1 R128 trouble (was: …install mysteries)

In the end, I’m guessing that the addition of a simple modeline will be the quick fix for the video problem

ps -

Driver “r128” or Driver “ati” in /etc/X11/xorg.conf.d/50-device.conf don’t change scrambled screen
the “ati” xorg driver is for radeon hardware only … in days gone by, it used to be a wrapper for radeon, r128 and mach64, but the later have been split out and are uniquely contained now.

Because the three essential driver parts are (in this case) similarly named (r128*), much of the key to understanding boils down to context. In the xorg log, all the r128 line entries refer to prints from the r128 xorg driver (a.k.a. the so called ddx - device dependent x code - driver), and the other entries will be particular to the X environment, so you won’t see messages from the DRM or Mesa driver (though there can be inferences to those parts).

And speaking of context: “DRI” is a good example of a troublemaker – as one has to know whether we’re talking about the infrastructure (Direct Rendering Infrastructure), the X protocol, or specifically about a 3D/dri driver (i.e one of the components pieces within the DRI)

The other suggestion to set ‘no acceleration’ came from another GNU/Linux distribution thread on the r128, where the user noted vaguely similar symptoms to the OP and advised that allowed them to boot to a GUI with the R128, but while they achieved a GUI the performance was rather bad.
yes, that’s a good idea to check out (see message above).

OK

I don’t understand all your last ideas, may be because I left linux universe 3 years ago
to jump into a really fascinating Hackintosh universe !

But i did a simple thing:
I copy my xorg.conf from my old Suse 10.1 in 12.3 /etc/X11/

and it works 90% I don’t have any more blurred screen, graphical response is smooth

I have some minor color problems still to solve but I am waiting for a memory upgrade
in a few days, 256 Mb is too short for 12.3
Then I will continue to investigate

I posted my solution on the other forum, just to help.

Thanks a lot for your help

Caty

That is good to read.

Please, for my own education, could you copy your xorg.conf to SUSE Paste , press create, and then post here the web-address/url where the xorg.conf has been copied (on susepaste) ? I’m hoping to learn one or two things by looking at its content.

You may find LXDE desktop runs best with only 256MB of RAM.

Apologies (possibly I missed it in a post above in this thread) but I don’t know what forum/web address that may be.

Hello oldcpu

There is the link to xorg.conf
SUSE Paste

I plan to adjust its content and check, on corresponding /var/log/Xorg0, the result of modification.
I hope I can solve last missing details this way: color defects on some boxes and 1600x1200 not yet working.

By the way, 12.3 documentation says : 512 Mb is a minimum required.

And there is the other fellow opensuse-factory - Re: 12.3 RC1 R128 trouble (was: …install mysteries)

Caty

Thankyou for posting that.

Its interesting.

What interest me the most is :

  • Section “Monitor” which devices the monitor as LCD (together with different (wider) HorizSync and VertRefresh settings than the nominal openSUSE setup defaults)
  • Section “Modes” which defines a host of different modelines
  • Section “Screen” which defines a host of different display mode settings
  • Section “Device” where the ‘ati’ driver, and not the ‘r128’ driver use is defined.
  • Section “DRI”, where I had thought ‘dri’ no longer useable with your hardware with the latest Mesa

I suspect with the above, one could replace the /etc/X11/xorg.conf file that you posted the link to (and are using now) with appropriate edits to the

  • /etc/X11/xorg.conf.d/50-device.conf
  • /etc/X11/xorg.conf.d/50-monitor.conf
  • /etc/X11/xorg.conf.d/50-screen.conf

I think the ‘DRI’ information, if kept, could go in the 50-device.conf. The “Modes” information would go in either the 50-monitor.conf or 50-screen.conf files. I suspect the former but my knowledge is not strong enough to do more than speculate.

Out of curiousity, if the ‘ati’ in the ’ Driver “ati” line (in the " Device" section is replaced with “r128”), does your PC still boot to a GUI ?

ie I’m curious if this works in that xorg.conf section instead of what is in there now for Section Device:


Section "Device"
  BoardName    "Rage 128 Mobility MF"
  BusID        "1:0:0"
  Driver       "r128"
  Identifier   "Device[0]"
  Screen       0
  VendorName   "Rage"
EndSection

Change that to test ONLY if you are confident you can boot to safe settings to reverse the change if it causes the GUI not to work.

yes indeed, and that is good advice. But having typed that, I have booted LXDE on with much less RAM than that on openSUSE. Its slow, and one is heavily into ‘swap’, but it still functions. :smiley: … 512 MB provides much better LXDE performance.

[QUOTE=catyburtyt;2571519]
And there is the other fellow [

That’s interesting. I see he noted " HorizSync and VertRefresh " need to be modified, and I note your xorg.conf does that (especially it widens the HorizSync). This makes me speculate that you may have been able to do without the xorg.conf file, and just widen the HorizSync in the 50-monitor.conf (possibly have changed both the HorizSync and VertRefresh ). I do emphasize the word speculate on my part. I’m not very knowledgeable in this.](“http://opensuse.14.x6.nabble.com/Re-12-3-RC1-R128-trouble-was-install-mysteries-td4984686.html”)

Some answers for you oldcpu

I fixed the color problems. In Section “screen” Defaultdepth was set to 16.Changing to 24 did the trick.

Now I stay with the xorg.conf in /etc/X11/
I changed ati by r128, its working: no scrambled screen.
but I can’t access to full screen, resolution that is 1600 x 1400 (under XP)

Now some questions for you:

Looking through Xorg0.log, it seems that Suse at startup reject all resolutions and choose arbitrary 1400x1050.
So I was expecting to change resolution using xrandr
but it is alaws answering: xrandr can 't open display
I read somewhere that xrandr don’t work with ati ?
I don’t know if it is true or not.
There is a lack in good documentation on debugging display problems in recent linux distribution.
(I tried cvt to get modeline I pasted into xorg.conf, reducing possible scanning modes to one per format
this gave me same result.)

Do you know other command in term I can use to test higher resolution It may help to progress.
Thanks;)

Caty

I don’t know why xrandr does not work. Does it not work if you simply type ‘xrandr’ , or does it not work if you add a number of arguments ?

Nominally one can run an application to find the settings for a new modeline, add the modeline, and then use the modeline. I don’t know if your non-functional xrandr will affect that.

There are modeline settings for 1600 x 1200 in the xorg.conf file you posted but no 1600x1400. Are you certain you have that resolution correct ? It does look clear to me that 1600x1400 would not have worked on your previous older openSUSE version with that xorg.conf…

If one does not have the modeline settings, normally one will check their monitor and graphic device specs to confirm the resolution they want to use is supported, and then use the application ‘cvt’ or the application ‘gtf’ , both with specific arguments, to figure out the modeline settings.
For example, for 1600 x 1400 at say 60 Hz , you could try:


cvt 1600 1400

or possibly


gtf 1600 1400 60

… I don’t know if ‘60’ (60Hz) is the right frequency for 1600x1400 in your setup.

But lets assume , as an example, that it is a good frequency, then you could get something like:


user@userspc:-> gtf 1600 1400 60
  # 1600x1400 @ 60.00 Hz (GTF) hsync: 86.94 kHz; pclk: 189.18 MHz
  Modeline "1600x1400_60.00"  189.18  1600 1712 1888 2176  1400 1401 1404 1449  -HSync +Vsync

Armed with that information (and you need to use YOUR PC settings and not the example values I am showing) you would test it with:


 xrandr --newmode 1600x1400_60.00"  189.18  1600 1712 1888 2176  1400 1401 1404 1449  -HSync +Vsync

Then you would switch to that resolution as a test with the appropriate xrandr command:


xrandr --output VGA-0 --mode 1600x1400_60.00

… but ‘VGA-0’ may not be correct. I need to see a nominal ‘xrandr’ output and you say it is not working.

Once one confirms this works, then one can add the appropriate entries in to one’s configuration file.

Having typed the above, without xrandr working, I don’t believe I know enough to assist you.

oldcpu, this is for you !

Some answers first:

  1. I just discover that xrandr is very funny !
    running as root it always says Can’t open display
    but running as normal user it works :wink:
    So now I will be able to experiment some new settings for display.

  2. you wrote:
    There are modeline settings for 1600 x 1200 in the xorg.conf file you posted but no 1600x1400
    You are perfectly right. Idid a confusuin: I am trying to get 1600x1200 that is the upper limit for this screen.
    but right now I have only 1400x1050

  3. I already used cvt & gtf and edited modlines as you suggested in your last post.
    Thanks for the trick.
    I discarded most of modelines keeping only one line per screen resolution.
    You can see my last xorg.conf simplified here SUSE Paste
    and my last Xorg.log.0 here SUSE Paste
    you can have a look on the last one, it seems to be clean.

And just one question now:
But I don’t understand why I can’t have at boot the highest resolution (1600x1200)

Thanks

I still need to play now with xrandr …

Caty

Can you run ‘xrandr’ in a bash shell/terminal, and post here the output ?