Phoronix Forums  

Go Back   Phoronix Forums > Linux Graphics / X.Org Drivers > X.Org & Mesa

X.Org & Mesa Discussion of X.Org and Mesa / Gallium3D. This includes the discussion of the X Server, RandR, OpenGL, Kernel-based Mode-Setting, and other X components not covered by other forums.

Reply
 
Thread Tools Display Modes
  #1  
Old 07-15-2008, 10:30 AM
phoronix phoronix is offline
Phoronix News Bot
 
Join Date: Jan 2007
Posts: 3,103
Default Persistent Configuration Options For X.Org Drivers

Phoronix: Persistent Configuration Options For X.Org Drivers

In recent times, the xorg.conf file once used for configuring all static X-related server options has been shrinking in size. Thanks to more reliable EDID (Extended Display Identification Data) on LCD panels, it's generally no longer needed to manually specify mode-lines within this X.Org configuration file. With improvements for auto-detection, in many circumstances it's no longer even needed to manually specify your graphics driver and other options. However, the X Server currently lacks an infrastructure for supporting persistent device properties.

http://www.phoronix.com/vr.php?view=12615
Reply With Quote
  #2  
Old 07-15-2008, 05:08 PM
Grifter Grifter is offline
Junior Member
 
Join Date: Jul 2008
Location: Svea Rike
Posts: 1
Default

Forgive my ignorance, but couldn't this be done with a pseudo-filesystem like /proc, doing changes on the fly, while writing a hardcopy alternative xorg.conf whenever a change is made, ensuring a persistent setting?
Reply With Quote
  #3  
Old 07-16-2008, 05:13 AM
birdie birdie is offline
Junior Member
 
Join Date: Jul 2008
Location: Russia
Posts: 16
Thumbs down

The problem is that Linux lacks ANY API for managing X server options and xorg.conf was meant to be absolutely static.

And now we once again face a situation when everyone tries to invent its own wheel (the first to attempt to do that was Corel with its Corel Linux).

We have Fedora/Suse/Mandriva/Ubuntu/Arch all having different methods of managing such a simple file. This situation sucks immensely. Now we see an advent of a new hell of competing solutions of managing X server runtime configuration.
Reply With Quote
  #4  
Old 07-16-2008, 10:11 AM
Fixxer_Linux Fixxer_Linux is offline
Senior Member
 
Join Date: Sep 2007
Location: Paris, France
Posts: 176
Default

There's a thing called "LSB" for "Linux Standard Base". Couldn't they define an official architecture for such problems, in order to have something standard accross the various distros ??

This non standardisation of linux is its weakness. Windows at least managed to create a standard for everyone.
For example, DirectX. You can either love or hate DirectX, but DirectX has at least permitted the standardisation of the programming language for 3D apps. At the time of launching DirectX as a common language for everyone, there was the S3 Virge which had his own language, 3DFX which had another and there was OpenGL which was more or less reserved for professionnals.
At least, now, everything is standard with DirectX.

The only problem, is that this standard is based on proprietary software, and depends on the will of a single editor.

I'm perhaps wrong as I'm not informed of all what happens in the linux world, but I fell that the linux side should take more time to have standards, as this would simplify the compatibility between distros and save therefore a lot of time for the dev of enhancements.
Reply With Quote
  #5  
Old 07-16-2008, 02:04 PM
Ex-Cyber Ex-Cyber is offline
Senior Member
 
Join Date: Jan 2008
Posts: 269
Default

Quote:
Originally Posted by Fixxer_Linux View Post
Windows at least managed to create a standard for everyone.
Actually, that's an illusion, which takes a considerable amount of effort (by both the Windows teams and application developers) to maintain. It may be a useful illusion, but it doesn't just happen because someone waved a document around (c.f. the World Wide Web, for which standards have been known to sit around for 5-10 years before anyone seriously attempts to conform).

Quote:
Originally Posted by Fixxer_Linux View Post
For example, DirectX.
Would that be DirectX 9 or DirectX 10?
Reply With Quote
  #6  
Old 07-16-2008, 04:52 PM
Louise Louise is offline
Senior Member
 
Join Date: May 2008
Posts: 470
Default

It is not clear to me what "persisting driver configuration" is, but it sounds like something like

Include "/etc/X11/confs/*.conf"

could do the trick?

Suse does this with Apache, with its advantages and DISadvanges[0].

[0] Just think of the include order.
Reply With Quote
  #7  
Old 07-17-2008, 12:11 AM
DanL DanL is offline
Senior Member
 
Join Date: Oct 2007
Posts: 247
Default

Sigh... I prefer xorg.conf IF the driver writers document the options properly. Give me the manual, give the n00bs a GUI.
Reply With Quote
  #8  
Old 07-18-2008, 12:39 AM
reavertm reavertm is offline
Junior Member
 
Join Date: Jul 2008
Location: Wrocław/Poland
Posts: 25
Default

I just hope they're not going to remove ModeLine support from X.org as it's the only way I can use 1280x960@85 mode on ATI proprietary driver with my setup (x1950 PRO AGP 512MB + AOC 9k+ 19" CRT connected via DVI2DSUB connector).
The only driver with proper modesetting is radeonhd - it doesn't even need monitor configuration in xorg.conf - just disabling XRandr and it works like a charm.
Latest ATI proprietary (8.06) needs explicit ModeLine option to make it work.. Other Open Source driver (xf86-video-radeon) on the other hand seems to have broken modesetting at all (and they're thinking on 3D still having broken modesetting?!) - unable to set this resolution, ignoring ModeLine, disabling terminal completely after X to VT switch (redirecting output to secondary ??) - ati radeon just doesn't work - no matteer what I change in xorg.conf. And with this state of things there are ideas of persistent configuration options for X.org drivers with no ModeLine because nowadays nobody uses them?
EDID autodetection is well implemented in all drivers I tested (I examined logs and all required modelines were dumped) but logic and some actions taken based on those modes are plain wrong and xf86-video-ati seems to revert to "default" 1280x1024@60 - is this hardcoded in xf86-video-ati?
Seriously - finish modesetting first - then proceed to 3D/compiz.
(I'm talking about git versions that is).
I would be glad to help testing modesetting (at least on my machine).

Last edited by reavertm; 07-18-2008 at 12:44 AM.
Reply With Quote
  #9  
Old 08-04-2008, 01:09 PM
energyman energyman is offline
Senior Member
 
Join Date: Jul 2008
Posts: 1,037
Default

I hope they don't do something incredible stupid and use that gconf crap for this.

What is wrong with good old plain text files and a man page explaining them? (hint: nothing, except that users might understand them)
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 12:50 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2004 - 2009 by Phoronix Media.