But today after an update it seems that X is ignoring this settings. DRI is disabled again, and according to the Xorg-log it is trying out all drivers instead of using radeonhd directly.
I have no idea what I can do, has anybody radeonhd with Factory working? Or is there any way to get fglrx working with the 2.6.34-kernel?
Any chance your xorg.conf is simply bad (ie needs updating to coincide with what ever “unknown” update you did ) ?
As for trying out other options before using radeonhd, are you certain that is NOT nominal behaviour? Do you have an xorg.0.log from before to compare this to ?
I had 11.3 M4 and 11.3 M5 working (from the liveCD) with the radeon driver on an HD3450. A few minutes ago a read of an 11.3 M6 user having the radeon driver working on an HD3450. In all cases, the radeon driver was chosen automatically. No xorg.0.log needed.
In fact, going one step further, my experience is the “radeon” driver is currently working better for the Radeon HD34xx than the “radeonhd” driver, and IMHO you should try the “radeon” driver.
IMHO you should not be running Factory. It is for testing purposes and known to have (upto severe) issues.
xorg.conf will completely disappear, you may have arrived at the point where it’s ignored.
I didn’t saved any old log because it was working. But I know that it was just trying the radeonhd-driver after using this xorg.conf.
Ok I will try to remove the radeonhd-driver to get the radeon-driver used.
I have to use Factory because 11.2 is not working on this notebook, I tried a lot to get 11.2 working.
If xorg.conf will disappear there will be no way to force any xorg-settings?
Update: I have uninstalled radeonhd and the radeonhd-driver and the radeon-driver which is now used automatically is working perfect
I was also having issues with the radeonhd driver, and after uninstalling it, the system automatically started using the radeon driver, and its performance is much better.
From the release notes for milestone 6, it looks like the radeonhd driver is being deprecated from milestone-6, and being replaced with the radeon driver.
From the release notes for milestone 6, it looks like the radeonhd driver is being deprecated from milestone-6, and being replaced with the radeon driver.
First I’ve heard about this. It doesn’t make sense as the radeonhd driver is still being developed. Can you post the source of this info? (I haven’t been able to find any info online about this).
Thanks for that link. After reading this, it doesn’t sound as bad as it first appears. It looks like the ati (radeon) driver now offers functional advantages anyway.
Now though the RadeonHD driver has perhaps suffered its final blow as the RadeonHD driver is no longer being used as the default within Novell’s own openSUSE distribution. As is said in the OpenSUSE 11.3 Milestone 6 notes, “radeon video driver has superseded radeonhd, providing KMS/DRI support.”
These days the xf86-video-ati driver supports more hardware and features than the xf86-video-radeonhd driver does, and every other major desktop Linux distribution these days use xf86-video-ati with kernel mode-setting, but now Novell has abandoned its child within openSUSE.
Further to this, I note this Phoronix article mentions that with the new X-server (being included with openSUSE 11.3), there is support being developed for the use of configuration files located within /etc/X11/xorg.conf.d directory. If the traditional xorg.conf is present, then any included settings will take presidence over the new conf files, and if both are missing, ‘the X Server will fall-back to its usual auto-detection routines.’
Indeed some of the “old” xorg.conf sections, such as “device”, “screen”, and “monitor” appear to have their own files now, with 50-screen.conf, 50-device.conf, 50-monitor.conf being present in /etc/X11/xorg.conf.d where on my sandbox 11.3 M6 LXDE install I note the contents inside are all commented out.
As I struggle to see a benefit to the user, given the extra files to check for monitor/graphic card config sets, a positive thought occurred to me. More clicks to see a combined config, but with no xorg.conf, “scrolling” is reduced lol!. The X devs strike a blow for productivity (or not).
To replace the device option handling that was previously done through HAL FDI files, the X Server is picking up support for reading configuration files from a directory rather than just the conventional /etc/X11/xorg.conf.
The X Server will continue to support reading options from the traditional xorg.conf and these options will take precedent over any values set within xorg.conf.d, where the other options can be stored. Within the xorg.conf.d directory could be a file for your mouse, a file for your input tablet, joystick, and any other devices. If there is no xorg.conf or any configuration files within this new directory, the X Server will fall-back to its usual auto-detection routines.
… the X server uses udev instead of HAL for input device detection and xorg.conf InputClass configuration
…
**xorg.conf.d **
The X server now supports the configuration directories /etc/X11/xorg.conf.d and /usr/share/X11/xorg.conf.d. The former is for user-specific configuration and the latter provides configurations by the distribution vendors. Changes to files in the latter directory may be overwritten. The following focuses on the user-specific configuration directory.
Files with the suffix .conf in this directory are parsed by the X server upon startup and treated like part of the traditional xorg.conf configuration file. Files in this directory may contain one or more sections; for a description of the options in a section and the general layout please refer to xorg.conf(5). Files in the /etc/X11/xorg.conf.d directory are parsed in-order before the xorg.conf has been parsed fully with precedence is given to the xorg.conf, then to the last configuration entry where applicable. The X server essentially treats the collection of configuration files as one big file with entries from xorg.conf at the end. Users are encouraged to put custom configuration into /etc/xorg.conf and leave the directory for configuration snippets provided by the distribution.
Oldcpu, Thanks for posting that and the further reading. It reminds me of the VirtualBox/usb/udev scenario, and I suppose audio configuration went a similar way. A form of standardization must benefit project development generally, and more specifically at the distro level. Separating user mods from distro mods must be a good thing, and aids recovery from failed user mods.