On Sat, Apr 28, 2012 at 05:52:55AM -0400, Justin Piszcz wrote: > On Fri, Apr 27, 2012 at 9:49 PM, Thomas Dickey <dic...@his.com> wrote: > > On Fri, Apr 27, 2012 at 09:55:01AM -0400, Justin Piszcz wrote: > >> Package: xterm > >> Version: 278-1 > >> > >> Hello, > >> > >> After a recent upgrade of xterm (278), text no longer shows up in > >> xterm with the options I normally use: > >> > >> xterm -bg black -fg white > >> > >> The screen is black in xterms now, it does not honor the foreground > >> color? ?Unless I run it without these arguments, I have downgraded to > >> xterm 261 (still in the FTP dir) and all works normally again. > > > > I don't see this behavior in an update to Debian/unstable, or > > Debian/testing. > > It's possible that there's some X resource setting on your machine which > > has foreground pre-set, making it impossible to override. ?That would be > > either a local customization, or some desktop junk (KDE's been an offender > > in this area, for instance). ?Some details about the X resources, e.g., > > as seen by appres and the window manager/desktop might show the problem. > > Hi, > > I found the root cause, when using vnc, if you use "-depth 24" when > starting vncserver, the text will be black. When "-depth 24" is not > specified, it honors the background color. > > What is interesting is vnc has not changed and the older version of > xterm (267) did not exhibit the issue w/ vnc when "-depth 24" was > specified. > > The new version works as long as "-depth 24" is not specified. > > How to reproduce: > 1. Install Debian Testing x86_64 > 2. Install vnc4server 4.1.1+X4.3.0-37 > 3. Run: vncserver -geometry 1024x768 -depth 24 > 4. Make sure xterm 278-1 is installed (debian/testing) > 5. /usr/bin/xterm -bg black -fg white > 6. Then you can kill that vnc and re-run it without the -depth 24 and > it works fine. > > Seems like an xterm/vnc/color/depth bug? When the default is used > (-depth 16) the text appears properly and the background color is > honored.
That's probably related to this change from #277:
* add a workaround for XAllocColor(), which does not actually
allocate "a read-only colormap entry corresponding to the closest
RGB value supported by the hardware", but rather a rough
approximation (Debian #650291).
...and I'll see if I can reproduce the effect you're describing. The
fix might be as simple as excluding depth 24 from the workaround.
In a quick check, I don't see any fixes for regressions relative to #276,
so you might be able to upgrade to _that_ version. (I'm near the end of
a large change for #279).
--
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
