problem with colour database - Xwindows

This is a discussion on problem with colour database - Xwindows ; years ago i augmented the X colour database on my machines to have the option of using dark, saturated, graded colors for window decorations, menu bg's, etc, e.g., $ grep deepblue /etc/X11/rgb.txt 44 44 178 deepblue 44 44 178 deepblue1 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: problem with colour database

  1. problem with colour database

    years ago i augmented the X colour database on my machines to have the
    option of using dark, saturated, graded colors for window decorations,
    menu bg's, etc, e.g.,

    $ grep deepblue /etc/X11/rgb.txt
    44 44 178 deepblue
    44 44 178 deepblue1
    41 41 165 deepblue2
    35 35 142 deepblue3
    24 24 98 deepblue4

    all was good until XOrg's X 7.1.1 (or so i think), but now

    $ xsetroot -solid deepblue
    xsetroot: unknown color "deepblue"

    it doesn't work anymore

    grepping for rgb in X's log

    $ grep rgb /var/log/Xorg.0.log
    (==) RgbPath set to "${prefix}/share/X11/rgb"

    leads to the this last investigation:

    $ ls -l /usr/share/X11/rgb.txt
    lrwxrwxrwx 1 root root 16 Sep 21 10:04 /usr/share/X11/rgb.txt -> /etc/X11/rgb.txt

    in summary, all is good, or so it seems, but X pretends that i have no
    extra colours

    boring details, my system is debian unstable and:

    $ X -version

    X Window System Version 7.1.1
    Release Date: 12 May 2006
    X Protocol Version 11, Revision 0, Release 7.1.1
    Build Operating System: UNKNOWN
    Current Operating System: Linux boffi95 2.6.17-2-686 #1 SMP Wed Sep 13 16:34:10 UTC 2006 i686
    Build Date: 07 July 2006
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
    Module Loader present


    thank you, ciao
    g
    --
    Hai capito benissimo quello che intendevi. -- AirCraft, in ISC

  2. Re: problem with colour database

    Giacomo Boffi writes:

    > [X, apparently, does not read .../rgb.txt]


    i straced X, but, always apparently, it doesn't open any .../rgb.txt,
    so i typed

    $ grep rosybrown /usr/bin/Xorg
    Binary file /usr/bin/Xorg matches
    $

    leading to the question:
    afaYct, the colour names were always built-in in the server binary?
    --
    giampippetto, coso, come si chiama? ah! si` "Sharazade" ha scritto:
    > avere le idee un po' + chiare di concetti come "senza se e senza ma"
    > al di là dei contenuti e della condivisione d'intenti.


  3. Re: problem with colour database

    Giacomo Boffi writes:

    > afaYct, the colour names were always built-in in the server binary?


    to answer my Q, no, they were built in (in xfree86, at least) from
    june 2005...
    --
    non ho capito un apascio -- pp, tra se e se

  4. Re: problem with colour database

    In comp.windows.x, Giacomo Boffi

    wrote
    on Wed, 27 Sep 2006 22:28:55 +0200
    <86d59hkq9k.fsf@boffi95.stru.polimi.it>:
    > Giacomo Boffi writes:
    >
    >> afaYct, the colour names were always built-in in the server binary?

    >
    > to answer my Q, no, they were built in (in xfree86, at least) from
    > june 2005...


    I'll admit I frankly don't know all of the issues here,
    but on my Gentoo system the color database is positioned
    at /usr/share/X11/rgb.txt and is not a symbolic link.
    This is as of xorg 1.0.2 (Gentoo r7).

    It is likely an update broke the link and put the file
    there.

    Gentoo is reflecting massive upstream changes as well;
    xorg apparently fragmented the entire X server project.
    You may need to look for the 'rgb' application somewhere
    in your Debian dpkg/dselect list. This should give you
    two things: the rgb.txt file, which you can probably
    modify, and a program called 'showrgb'.

    --
    #191, ewill3@earthlink.net
    Linux. Because it's there and it works.
    Windows. It's there, but does it work?

  5. Re: problem with colour database

    The Ghost In The Machine writes:

    > I'll admit I frankly don't know all of the issues here, but on my
    > Gentoo system the color database is positioned at
    > /usr/share/X11/rgb.txt and is not a symbolic link. This is as of
    > xorg 1.0.2 (Gentoo r7).
    >
    > It is likely an update broke the link and put the file there.
    >
    > Gentoo is reflecting massive upstream changes as well; xorg
    > apparently fragmented the entire X server project.


    debian is second to none in the fragmentation business...
    /etc/X11/rgb.txt and the symlink /usr/share/X11/rgb.txt are installed
    by the x11-common package

    > You may need to look for the 'rgb' application somewhere in your
    > Debian dpkg/dselect list. This should give you two things: the
    > rgb.txt file, which you can probably modify, and a program called
    > 'showrgb'.


    apt-file search returns only
    xmanpages-ja: usr/share/man/ja/man1/showrgb.1x.gz

    i'm now convinced that there's a bug [1] in debian or upstream, i'll
    start reporting the bug to debian...

    thank you,
    gb

    [1] a bug masked by the intelligent decision of dumping the color
    db into the server binary
    --
    sono sicuro che sotto, sotto SdC è uno dei nostri -- MMAX, in IFQ+IPI

  6. Re: problem with colour database

    Giacomo Boffi writes:

    > The Ghost In The Machine writes:
    >
    >> I'll admit I frankly don't know all of the issues here, but on my
    >> Gentoo system the color database is positioned at
    >> /usr/share/X11/rgb.txt and is not a symbolic link. This is as of
    >> xorg 1.0.2 (Gentoo r7).
    >>
    >> It is likely an update broke the link and put the file there.
    >>
    >> Gentoo is reflecting massive upstream changes as well; xorg
    >> apparently fragmented the entire X server project.

    >
    > debian is second to none in the fragmentation business...
    > /etc/X11/rgb.txt and the symlink /usr/share/X11/rgb.txt are installed
    > by the x11-common package
    >
    >> You may need to look for the 'rgb' application somewhere in your
    >> Debian dpkg/dselect list. This should give you two things: the
    >> rgb.txt file, which you can probably modify, and a program called
    >> 'showrgb'.

    >
    > apt-file search returns only
    > xmanpages-ja: usr/share/man/ja/man1/showrgb.1x.gz
    >
    > i'm now convinced that there's a bug [1] in debian or upstream, i'll
    > start reporting the bug to debian...
    >
    > thank you,
    > gb
    >
    > [1] a bug masked by the intelligent decision of dumping the color
    > db into the server binary


    oh, it looks like it was a deliberate decision

    from /use/share/doc/xserver-xorg-core/changelog.gz

    ,----
    | 2006-02-15 Keith Packard
    |
    | * Makefile.am:
    | [...]
    | Replace rgb text file loading with static rgb color table.
    `----

    imho it's an error because X should be configurable

    --
    If you grow tired of the friends you make
    Never ever turn the back on them
    Say they were the best of time you ever had
    The best of times with the thougthless kind -- John Cale

  7. Re: problem with colour database

    Giacomo Boffi writes:

    > Giacomo Boffi writes:
    >
    >> The Ghost In The Machine writes:
    >>
    >>> I'll admit I frankly don't know all of the issues here, but on my
    >>> Gentoo system the color database is positioned at
    >>> /usr/share/X11/rgb.txt and is not a symbolic link. This is as of
    >>> xorg 1.0.2 (Gentoo r7).
    >>>
    >>> It is likely an update broke the link and put the file there.
    >>>
    >>> Gentoo is reflecting massive upstream changes as well; xorg
    >>> apparently fragmented the entire X server project.

    >>
    >> debian is second to none in the fragmentation business...
    >> /etc/X11/rgb.txt and the symlink /usr/share/X11/rgb.txt are installed
    >> by the x11-common package
    >>
    >>> You may need to look for the 'rgb' application somewhere in your
    >>> Debian dpkg/dselect list. This should give you two things: the
    >>> rgb.txt file, which you can probably modify, and a program called
    >>> 'showrgb'.

    >>
    >> apt-file search returns only
    >> xmanpages-ja: usr/share/man/ja/man1/showrgb.1x.gz
    >>
    >> i'm now convinced that there's a bug [1] in debian or upstream, i'll
    >> start reporting the bug to debian...
    >>
    >> thank you,
    >> gb
    >>
    >> [1] a bug masked by the intelligent decision of dumping the color
    >> db into the server binary

    >
    > oh, it looks like it was a deliberate decision
    >
    > from /use/share/doc/xserver-xorg-core/changelog.gz
    >
    > ,----
    > | 2006-02-15 Keith Packard
    > |
    > | * Makefile.am:
    > | [...]
    > | Replace rgb text file loading with static rgb color table.
    > `----
    >
    > imho it's an error because X should be configurable


    You could try to convince someone at Xorg.

    I think user defined colors could raise some portability
    and performance problems.

  8. Re: problem with colour database

    Dan Espen writes:

    hi Dan, thank you for your comments

    > Giacomo Boffi writes:
    >>> [1] a bug masked by the intelligent decision of dumping the color
    >>> db into the server binary

    >>
    >> oh, it looks like it was a deliberate decision
    >>
    >> from /use/share/doc/xserver-xorg-core/changelog.gz
    >> | 2006-02-15 Keith Packard
    >> |
    >> | * Makefile.am:
    >> | [...]
    >> | Replace rgb text file loading with static rgb color table.
    >> imho it's an error because X should be configurable

    >
    > You could try to convince someone at Xorg.


    and i hoped that someone at Xorg could read c.w.x. ...
    is there an user's mailing list?

    > I think user defined colors could raise some portability
    > and performance problems.


    portability? as long as i limit myself to augment the names' database
    in my personal workstation, i foresee no problems, otherwise
    (removing color names) it's just me shooting in my foot, as usual.
    maybe there are other issues that i'm not fully aware of,
    e.g. software vendors that hack _my_ rgb.txt...

    performance? maybe, it is possible, but it's a feature (reading a
    possibly modified rgb.txt) that's been there for eons, used on
    systems low on memory and with low grade video subsystems

    i understand that the developers at Xorg want more control for
    legitimate reasons, but i feel mostly gratuitously constricted by this
    particular decision

    ciao
    gb
    --
    vabbụ parliamo d'altro -- Agnosco, in IFQ

  9. Re: problem with colour database

    Giacomo Boffi writes:

    > Dan Espen writes:
    >
    > hi Dan, thank you for your comments
    >
    >> Giacomo Boffi writes:
    >>>> [1] a bug masked by the intelligent decision of dumping the color
    >>>> db into the server binary
    >>>
    >>> oh, it looks like it was a deliberate decision
    >>>
    >>> from /use/share/doc/xserver-xorg-core/changelog.gz
    >>> | 2006-02-15 Keith Packard
    >>> |
    >>> | * Makefile.am:
    >>> | [...]
    >>> | Replace rgb text file loading with static rgb color table.
    >>> imho it's an error because X should be configurable


    I'm pretty sure, this would not be the first
    X program using a compiled in color name table.

    >> You could try to convince someone at Xorg.

    >
    > and i hoped that someone at Xorg could read c.w.x. ...


    Maybe.

    > is there an user's mailing list?


    Sure, visit their web site.

    >> I think user defined colors could raise some portability
    >> and performance problems.

    >
    > portability? as long as i limit myself to augment the names' database
    > in my personal workstation, i foresee no problems, otherwise
    > (removing color names) it's just me shooting in my foot, as usual.
    > maybe there are other issues that i'm not fully aware of,
    > e.g. software vendors that hack _my_ rgb.txt...


    I'm just trying to look at this the way the xorg developers
    might review your request.
    Any app developed using 'superspiffyblue' is going to raise
    a bunch of issues if you try to install it on someone elses
    machine. All of a sudden installers will have to deal with
    updating user and system level color databases.

    > > performance? maybe, it is possible, but it's a feature (reading a
    > > possibly modified rgb.txt) that's been there for eons, used on
    > > systems low on memory and with low grade video subsystems


    Sure it's going to take more time to read a rgb.txt file
    instead of using a compiled in rgb database possible already presorted
    for binary searches or hashed for direct access.

    > > i understand that the developers at Xorg want more control for
    > > legitimate reasons, but i feel mostly gratuitously constricted by this
    > > particular decision


    I don't think they want control, they want to produce the best
    software possible.

  10. Re: problem with colour database

    Dan Espen writes:

    > Giacomo Boffi writes:


    >> portability? as long as i limit myself to augment the names' database
    >> in my personal workstation, i foresee no problems, otherwise
    >> (removing color names) it's just me shooting in my foot, as usual.
    >> maybe there are other issues that i'm not fully aware of,
    >> e.g. software vendors that hack _my_ rgb.txt...

    >
    > I'm just trying to look at this the way the xorg developers
    > might review your request.
    > Any app developed using 'superspiffyblue' is going to raise
    > a bunch of issues if you try to install it on someone elses
    > machine.


    of course i'll send that developer to develop the oil fields in the
    north of siberia... i'm just trying to use better (darker) color
    schemes in my personal twm+xterm+xemacs+xfig setup!

    >> > performance? maybe, it is possible, but it's a feature (reading a
    >> > possibly modified rgb.txt) that's been there for eons, used on
    >> > systems low on memory and with low grade video subsystems

    >
    > Sure it's going to take more time to read a rgb.txt file instead of
    > using a compiled in rgb database possible already presorted for
    > binary searches or hashed for direct access.


    if i recall correctly, once upon a time, seeking for speed, the rgb
    database was dumped into real berkeley db files... the present measure
    looks like time machine at work

    >> > i understand that the developers at Xorg want more control for
    >> > legitimate reasons, but i feel mostly gratuitously constricted by
    >> > this particular decision

    >
    > I don't think they want control, they want to produce the best
    > software possible.


    their will to produce the best software possible is the most prominent
    of the legitimate reasons i wrote above, but their will for more
    control is, in the case here discussed, one of the most irrilevant
    ways to reach their goal

    ciao
    gb
    --
    janis> p.s. che vuol dire l'espressione "diversamente avvantaggiata"?
    pls> vuol dire che stai scontando una sorta di isolamento sociale.

  11. Re: problem with colour database

    Giacomo Boffi writes:

    > Dan Espen writes:
    >
    >> Giacomo Boffi writes:

    >
    >>> portability? as long as i limit myself to augment the names' database
    >>> in my personal workstation, i foresee no problems, otherwise
    >>> (removing color names) it's just me shooting in my foot, as usual.
    >>> maybe there are other issues that i'm not fully aware of,
    >>> e.g. software vendors that hack _my_ rgb.txt...

    >>
    >> I'm just trying to look at this the way the xorg developers
    >> might review your request.
    >> Any app developed using 'superspiffyblue' is going to raise
    >> a bunch of issues if you try to install it on someone elses
    >> machine.

    >
    > of course i'll send that developer to develop the oil fields in the
    > north of siberia... i'm just trying to use better (darker) color
    > schemes in my personal twm+xterm+xemacs+xfig setup!


    I think there's something in X called ?color managment? that deals
    with things like darkening colors.

+ Reply to Thread