[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Elektrified X.org released (was: X configuration paradigm, and a proposal)



tir, 30.11.2004 kl. 14.25 skrev Avi Alkalay:
> For people that still don't know the Elektra Project
> (http://elektra.sourceforge.net), it provides an alternative back-end
> for text configuration files. So instead, for example, the
> human-readable-only xorg.conf file, we'll have a hierarchy of
> key/value pairs easily and precisely accessible by X.org and also any
> other programs through an API or command, and human beings too.
> Same concept as GConf, but designed for system-wide use.
> 
> We've been working on X.org source code to do exactly what we just
> described above. And it is ready for use, tested even with very
> complex X.org configurations. A patched X server will convert your
> xorg.conf file automatically, even the most complex ones, including
> non-documented parameters.
> 
> It is available at 
> http://sourceforge.net/project/showfiles.php?group_id=117521
> http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136552
> 
> You'll find there the patch against X.org source, the patch against
> Fedora Core 3 RPM spec file (to see how to build it), and the README
> file, which is pasted in this e-mail bellow.
> 
> We'll write patches for other software, and everybody is invited to
> join this integration effort.
> 
> Thank you,
> Avi Alkalay
> Elektra Project <http://elektra.sf.net>
> 
> ----------------------README-------------------------
> ELEKTRIFIED X.ORG: PRECISE AND PROGRAMATICALY EASY X CONFIGURATION
> 
>    Your X server has to work with your installed video card, monitor, find
>    your font server and dirs, modules, extensions, drivers, plugins.
>    You have to tell him how to integrate it all through its xorg.conf file.
>    If you need to change something, you start a text editor and use your
>    human brain and eyes to find the correct line, understand it, have the
>    skills to change it, and change it in order to work.
>    
>    This is good for advanced technical guys, but very bad for people that
>    don't have this skills, and in fact, don't really want to. He just
>    wants to change the screen resolution to make that projector work with his
>    laptop, and go ahead with his sales presentation. This is just an example.
>    
>    The point is: it is very difficult to make simple programs or scripts
>    that make simple changes to X configuration. Another example is a monitor
>    vendor that wants to support X, and for this he'd like to provide easy
>    installation of his product, without having to ask his user to read
>    documentation about horizontal Sync, and vertical refresh rates. For him
>    again is difficult to write some simple software that preciselly changes X
>    configuration to work correctly with his product.
>    
>    The xorg.conf file (as most Unix configuration files) was designed for
>    human beings.
>    
>    The Elektra Project (http://elektra.sourceforge.net) introduces a new way
>    to handle configurations through a clean API (or command line
>    tool) that accesses atomic configuration data, into a standarized
>    hierarchycal tree of key-value pairs. It is similar to GConf, but
>    designed for system-wide use, which also implies it does not have
>    dependencies.
>    
>    And this is what this patch is about: to make the X server look for its
>    configurations into a machine-ready tree of key-value pairs, instead of
>    the human-ready xorg.conf.
>   
>    So where you had to look for "Device radeon" into a "Section Device",
>    with the key/value tree, X and other programs can look for it
>    preciselly at
>    
>       system/sw/xorg/current/Devices/Videocard0/Driver = radeon
> 
>    
>    Where you once had to "vi" your "Section Monitor", now X and other
>    programs can do it accessing the keys:
>    
>       system/sw/xorg/current/Monitors/Monitor0/HorizSync = 31.5 - 48.5
>       system/sw/xorg/current/Monitors/Monitor0/VertRefresh = 40.0 - 70.0
>       system/sw/xorg/current/Monitors/Monitor0/ModelName = IBM T40 LCD Panel
>       system/sw/xorg/current/Monitors/Monitor0/VendorName = IBM
>       system/sw/xorg/current/Monitors/Monitor0/Options/dpms
>   
>    
>    Where once the salesman above had to "vi" the Screen Section to change
>    the resolution, color depth, etc, a program can help him accessing:
>    
>       system/sw/xorg/current/Screens/Screen0/Displays/00/Depth=24
>       system/sw/xorg/current/Screens/Screen0/Displays/00/Modes=1024x768
> 
>    
>    And so on....
>    
>    We believe an elektrified X server can leverage more plug-and-play
>    configurations, providing configuration power to HW vendors in a
>    very simple way, and making users experience less painfull.
>    
>    
> 
>    
>       
> 
> BEHAVIOR OF AN ELEKTRIFIED X SERVER
> 
>    A patched X server will look for its configuration keys under the
>    namespace:
>    
>       system/sw/xorg/current   first, then if not found it tries
>       system/sw/xorg
>       
>    If not found, it will default to some xorg.conf file, parse it, and store
>    in its internal structures, then convert and commit it to a set of
>    keys under system/sw/xorg/current, and reload these keys.
>    
>    So you get automatic one-time conversion from xorg.conf to the
>    hierarchycal configuration key/value pairs 
>    
>    Very complex examples of xorg.conf files were tested for conversion. Even
>    undocumented configuration parameters (because the original source was
>    used as the reference).
>    
>    The Elektrifyied X server also works for the Red Hat Graphical Boot,
>    where you still don't have mounted partitions, network, etc.
> 
>    
>       
> 
> 
> ELEKTRIFING X.ORG
> 
>    You'll need the elektra-devel package installed in order to build X with
>    Elektra support.
> 
>      1. Download and unpack X.org source code from
>      2. Download the xorg-x11-6.8.1-elektra.patch file from
>          http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136552
>      3. Apply it:
>          ~/src/xc$ cd ..
>          ~/src$ patch -p0 < xorg-x11-6.8.1-elektra.patch
>          ~/src$ cd xc
>          ~/src/xc$ # ...configure your build in host.def
>      4. Enable the patch:
>          ~/src/xc$ echo "#define UseElektra" >> config/cf/host.def
>      5. Build X.Org
> 
>    You'll find the new X server as file xc/programs/Xserver/Xorg .
>    
>    The patch will add the following files:
> 
>       xc/programs/Xserver/hw/xfree86/parser/
>         elektra.h (exported methods)
>         elektra.c (key fetching and X structs integration business logic)
>         xorg-example.conf (a very complex conf file to test conversion)
>         xelektrify.c (cmd to convert xorg.conf->keys and vice-versa)
>         README.Elektra (this file)
>    
>    And it will instrument 
>    xc/programs/Xserver/hw/xfree86/common/xf86Config.c::xf86HandleConfigFile()
>    to trigger the one-time conversion, and key fetching logic.
>    
>    And instrument the Imakefiles for correct builds:
>    
>       xc/programs/Xserver/hw/xfree86/parser/Imakefile
>       xc/programs/Xserver/hw/xfree86/common/Imakefile
>       xc/programs/Xserver/Imakefile
>       
>    If "#define UseElektra" is not present in host.def, the patch is
>    completelly disabled, and you'll get a binary-identicall built as before
>    applying the patch. All patched code are surrounded by #ifdefs.
> 
>    
>    
>       
> 
> ELEKTRA MEETS X.ORG SOURCE CODE
> or how we wrote the patch....
> 
>    X.org has an xorg.conf parser that takes this steps to handle
>    configuration:
>    
>       1. Lexically parse the xorg.conf file
>       2. Put each Section info in an equivalent struct
>       3. Encapsulate all structs together and pass them to a validator
>       4. Use structs to define X behavior
> 
>    This process is triggered by the xf86HandleConfigFile() method from
>    
>       xc/programs/Xserver/hw/xfree86/common/xf86Config.c
>    
>    Each xorg.conf Section has an equivalent structure defined in
> 
>       xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h
>       
>    and the lexycall analyzer code to parse each Section is under
>    
>       xc/programs/Xserver/hw/xfree86/parser/
>    
>    A fully parsed file has its equivalent structures encapsulated in a
>    parent XF86Config struct. We have:
>    
>       struct XF86ConfModuleRec for the "Section Modules"
>       struct XF86ConfMonitorRec for the "Section Monitor"
>       struct XF86ConfDeviceRec for the "Section Device"
>       etc...
>       
>    These structs are a pure computer representation of the text in each
>    Section, so the methods under "parser/" convert text to structs, and
>    the structs to text. This is how original X.org source handles xorg.conf.
>    
>    The Elektrification add methods that act in steps 1 and 2 above. And also
>    include methods to convert each struct to a KeySet. Both old (xorg.conf)
>    and new (Elektra) ways to get configuration information can live together
>    and they are actually used to automatically convert xorg.conf to keys. So
>    at the first time you'll run your elektrified X server, it will:
> 
>       1. Not find configuration keys (because it is the first time)
>       2. Parse xorg.conf into structs
>       3. Convert structs to Keys
>       4. Commit the keys to key database
>       5. Reload configurations from the key database
> 
>    See the behavior in the previous section.
>       
>    After assembling the XF86Config C structure, X will decode all its info
>    into more practicall parameters for its further operation.
>    
>    As a side note, with a key/value pair configuration hierarchy paradigm,
>    the XF86Config assembling code (the parser) could be avoided, making X
>    look for its configurations in a programatically easier, yet
>    human-readable, configuration organization.
>    We worked at the parser level to keep compatibility and to not go too
>    deep in X.org source code.
> 
>    
> http://elektra.sourceforge.net
> The Elektra Project
> Avi Alkalay
> November 2004

While i am all for the *idea*, what happens if your X11 server breaks
down and you *have* to use VIM to "save" it? While i am not opposed to
creating an easily learned api for config-file configuration, i am
*strongly* opposed to not be able to hack into that xorg.conf file from
a crude command line (hell, i have vim'ed config files with /bin/bash as
my init process and a half borked kernel that would boot 1/5 times...).

I don't want my config's to be put all in the hands of some program, to
*have* to use a config program (with all the odds and ends it migth
have...) in order to fix a broken config. Now imagine that program
needed another program, which needed a service wich needed ... the thing
you where just trying to fix.

Kyrre


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]