No announcement yet.

Persistent Configuration Options For X.Org Drivers

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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
      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
        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
          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).

          Originally posted by Fixxer_Linux View Post
          For example, DirectX.
          Would that be DirectX 9 or DirectX 10?


          • #6
            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
              Sigh... I prefer xorg.conf IF the driver writers document the options properly. Give me the manual, give the n00bs a GUI.


              • #8
                I just hope they're not going to remove ModeLine support from as it's the only way I can use [email protected] 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 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" [email protected] - 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; 18 July 2008, 12:44 AM.


                • #9
                  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)