David Nusinow writes:
> I don't think that's really the method we want. Ideally, the server
> will use the built-in table unless we explicitly point it to an
> external file using xorg.conf. That way it just works in every
> situation and no one loses.
if the rgb.txt you ship WERE ALWAYS the b
Giacomo Boffi writes:
> Brice Goglin writes:
> > Hi Giacomo,
> >
> > I guess this problem with the RGB database being replaced by a
> > static table still occurs wth latest xserver-xorg-core 1.3, right?
> > For the record, it looks like we could revert to the old behavior
> > by defi
Brice Goglin writes:
> Hi Giacomo,
>
> I guess this problem with the RGB database being replaced by a
> static table still occurs wth latest xserver-xorg-core 1.3, right?
> For the record, it looks like we could revert to the old behavior
> by defining USE_RGB_BUILTIN to 0 during the build
On Sun, Jun 03, 2007 at 10:22:22PM +0200, Brice Goglin wrote:
> Hi Giacomo,
>
> I guess this problem with the RGB database being replaced by a static
> table still occurs wth latest xserver-xorg-core 1.3, right? For the
> record, it looks like we could revert to the old behavior by defining
> USE_
Hi Giacomo,
I guess this problem with the RGB database being replaced by a static
table still occurs wth latest xserver-xorg-core 1.3, right? For the
record, it looks like we could revert to the old behavior by defining
USE_RGB_BUILTIN to 0 during the build (see os/oscolor.c). However, I am
not su
5 matches
Mail list logo