Results 1 to 9 of 9

Thread: Persistent Configuration Options For X.Org Drivers

  1. #1
    Join Date
    Jan 2007
    Posts
    15,434

    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

  2. #2
    Join Date
    Jul 2008
    Location
    Svea Rike
    Posts
    2

    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?

  3. #3

    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.

  4. #4
    Join Date
    Sep 2007
    Location
    Paris, France
    Posts
    217

    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.

  5. #5
    Join Date
    Jan 2008
    Posts
    772

    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?

  6. #6
    Join Date
    May 2008
    Posts
    598

    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.

  7. #7
    Join Date
    Oct 2007
    Posts
    1,312

    Default

    Sigh... I prefer xorg.conf IF the driver writers document the options properly. Give me the manual, give the n00bs a GUI.

  8. #8
    Join Date
    Jul 2008
    Location
    Wrocław/Poland
    Posts
    37

    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 01:44 AM.

  9. #9
    Join Date
    Jul 2008
    Posts
    1,731

    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •