Red Hat Bugzilla – Bug 140901
X client library interoperability problem - text colours not displayed correctly on Sun workstation
Last modified: 2007-11-30 17:07:05 EST
Description of problem:
I am unsure if this is the correct place to file this bug. Since I
started to use ES 3 - I've found that the colours of characters shown
by Mozilla and other applications running on the Linux box as an X
client to a Sun Workstation don't display correctly. Blue letters are
shown as Red and vice versa. There are other more subtle colour
changes caused by this. Graphics show correct colours.
There seems to be some mismatch between the client libraries running
on Linux and the Xsun server. Running the client on the Sun and
displaying on the Linux screen shows the correct colours.
The Sun is running Solaris 9 and the most current patches for
the Xsun server.
Version-Release number of selected component (if applicable):
My Redhat ES 3 system is fully up-to-date from Update2.
Steps to Reproduce:
1. Log onto a Sun running CDE or Gnome
2. remotely access the Linux box
3. start Mozilla - or Evolution.
colour pickers in Evolution show RED - but display Blue
Are you running Solaris on x86, or Sparc? If Sparc, I wonder if
there is some endian related issue going on. Can you test on
Solaris/x86 also (or sparc if using x86)?
Can you run a larger range of applications, including remote GNOME,
GTK, KDE, as well as Xt or other toolkit apps, and see what all
apps it occurs with? It could be a problem anywhere from your
X server or video driver, to a toolkit bug, or even just bugs
in the individual applications.
Have you directly contacted Red Hat technical support about this
Thanks in advance.
I have a Sparc Ultra 10. I don't have any other Solaris systems, I am
a RedHat house these days! I HAVE reported this to Sun, in the UK, who
seem to be escalating it.
If I remotely run xterm -fg red - I get red characters, so it seems to
be something above the basic X levels and is possibly in the Gtk layer
that Mozilla and Evolution use. How do I run 'remote Gnome, GTK' etc?
I have not reported this to Redhat Tech Support. Is this covered by my
I have reported this to technical support - code 430794.
>If I remotely run xterm -fg red - I get red characters, so it seems to
>be something above the basic X levels and is possibly in the Gtk layer
>that Mozilla and Evolution use.
If xterm works fine, but Mozilla and Evolution do not, that helps
narrow things down a bit. Can you try running various other
Xt/Xaw apps, as well as GNOME/GTK/KDE/Qt apps remotely to help
additionally narrow things down?
>How do I run 'remote Gnome, GTK' etc?
Just run GNOME, KDE apps themselves, not the whole GNOME
desktop. Just run them like you'd run xterm or anything else,
by typing their name on the commandline:
This will help determine if it is a toolkit specific issue perhaps.
>I have not reported this to Redhat Tech Support. Is this covered
>by my subscription?
Red Hat Enterprise Linux customers should generally contact
Red Hat technical support as their first line of reporting
issues for RHEL or Red Hat Network (RHN). Red Hat Global Support
Services can then advise the customer of the particulars of
their support contract, and advise how to proceed with the given
issue, etc. This tends to be the best way to report issues
for the RHEL/RHN products, in particular if an issue turns out
to be a misconfiguration or some other issue that is not a
software defect, as support can usually directly help the customer
with an issue without having to go through engineering. Support
then escalates issues to engineering that do turn out to be real
software defects, etc. It's often faster this way.
Hope this helps.
Let me know the test results you get for other apps, and we'll
try to narrow things down further.
Thanks in advance.
Heh, we had a mid-air collision in bugzilla there. ;o)
Thanks for the update.
If I go to preferences - and unselect 'Use default theme colours', and
select RED letters - I get Blue - this looks like the characters that
come from Mozilla and Evolution.. so is presumably the same engine
underneath behaving in the same way.
xcalc - is a basic X app - and uses low level character display,
xcalc -fg red works like Xterm.
I think that this is working OK. This is what I use these days insead
of Xterm. It's a little complicated by the lscolors stuff. I did spend
some time messing with text colors way back, but my .dircolors is the
same on both machines. Again doesn't this use low level X character
The Sun is deeply unhappy with running this and doesn't display
anything very useful. Icon images are thrown on the screen 'randomly'
- text is blanked out when typing. Probably there is some KDE stuff
that the Sun doesn't support.
Thanks for your assistance by the way.
Ok, if you use "xterm -fa Vera" can you reproduce it with different
colours? This causes xterm to use antialiased freetype fonts via
>The Sun is deeply unhappy with running this and doesn't display
>anything very useful. Icon images are thrown on the screen 'randomly'
>- text is blanked out when typing. Probably there is some KDE stuff
>that the Sun doesn't support.
If you're using the X server on the Sun, then all it needs is itself,
it doesn't need to know anything about KDE.
If you can run a large number of random apps from the Red Hat box,
so we can get say 5-10 apps in each of the above categories, that
would be a big help. Just type "k<TAB>" and you'll get a list
of apps that start with k. Lots of them are KDE apps, try running
5-10 of them. Same for "g" and GNOME/GTK. I'd just like to see
if this is toolkit specific, Xft specific, perhaps pango, or
Right now, it appears it might possibly be Xft or pango or GTK,
but there's not enough conclusive info quite yet to be sure, and I
don't have access to a machine running a sun X server to test
gnome-terminal uses the vte widget, which uses Xft/fontconfig
for font display.
Thanks for the quick testing and status updates! Hopefully
we can figure this out over the next day or so.
Well a quick result.
xterm -fa Vera -fg red
gives me blue.
I'll look at the others.
and gnome-terminal is reversed. Sorry, I forgot that I usually run
ssh in a gnome-terminal on the Sun.
Ok, that narrows things down significantly. I'd say the problem is
in the Xft path now. xterm doesn't use pango, and if it's happening
in mozilla and evolution too, then the only common thing seems to
be Xft2, however it doesn't necessarily mean there is a bug in Xft2
though. Since Xft2 works fine to other remote X servers, I'm now
suspecting if your X server supports the RENDER extension, and if
so, wether it's rendering is correct, or wether it has an endian
Please run "xdpyinfo" also, and save the output to a file, and
attach it. I'd like to see what X server extensions your
X server supports, among other data.
Thanks in advance.
Created attachment 108028 [details]
Yep it has RENDER.
Ok. Can you find out if there's a way to disable the RENDER
extension in XSun, then disable RENDER, restart the X server and try
again. This will cause Xft to use software fallbacks, instead of
using the RENDER extension.
Then try running "xterm -fg red" and "xterm -fa Vera -fg red" again,
and report back the results of each.
Testing from a PPC arch X server seem to work both with and
without RENDER enabled in the server with both font scenarios.
This seems to be looking like an X server side problem, but it's
not yet conclusive. We'll keep exploring.
Well your diagnosis was correct. I found the file that controls
extension loading which for the record is:
removed the lines that load RENDER..
and it now is working correctly.
I'll pass this into Sun.
Many thanks for your diagnostic help.
Ok, since this was determined to be a Solaris bug, I'm closing
this as "NOTABUG" now. Thanks for the updates.