Description of problem:
Starting xterm yields a blank window. Xterm is working, though, except for the output to the display. Starting xterm with the -tb option results in:
-bash-4.2$ /bin/xterm -tb
/bin/xterm: warning, error event received:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Resource id in failed request: 0x0
Serial number of failed request: 260
Current serial number in output stream: 262
Sometimes it works until the xterm window loses focus.
Version-Release number of selected component (if applicable):
run 'xterm -tb'
Steps to Reproduce:
Perhaps this is a problem with fvwm; the display of xterm isn't blank when I'm using i3 instead of fvwm. Starting with -tb doesn't work with i3, either.
"-tb" is an option which is not configured in Fedora,
as far as I'm aware.
It is used in Gentoo and Cygwin.
See my comments in
Shouldn't it give a more reasonable error message like "please compile xterm with the toolbar option enabled" instead?
Anyway, toolbar or not, the xterm window is blank when running it with fvwm as window manager while it works fine with i3. Does anyone have the same results? Can I somehow find out if this a problem of fvwm or of xterm?
maybe/maybe not: there are several command-line options which
are conditionally compiled.
Checking now, I see that there's a hole in the rewrite of
command-line options from a few years ago. xterm is
using that "-tb" as "-t" (tek4014) rather than reporting an error.
I'll have a fix for that in #287.
But the tek4014 window is working properly - your login shell
may clear it (or something) and produce some unexpected behavior.
The shell running in the xterm window is bash, so nothing unusual. If the shell in the xterm was doing it, then why would xterm work with i3 and not with fvwm?
xterm-287-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xterm-287-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
xterm-287-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
The problem still persists with xterm-293-1.fc19.x86_64 and fvwm-2.6.5-4.fc19.x86_64 on Fedora 19.
With Fedora19 and xterm-293, I see only the expected behavior
for "-t" and "-tb" options (a Tek4014 window and a help-message
The problem is that starting xterm, without any parameters, starts xterm and it displays an empty screen (in the color specified through ~/.Xresources) with a cursor in the top left corner of the window.
I can type into the xterm window and execute commands, but there is no output to the xterm window. When I switch to another workspace or when I resize the xterm window, what I have typed and what has been output to the window is displayed. I can type some more into the window, but that is not displayed until I switch to another workspace or resize the window.
Apparently it takes an explicit redraw request sent by fvwm --- or whatever happens when switching workspaces and resizing windows --- to the xterm window for output to be displayed in the window.
When I start xterm with the '-t' option, output shows up in the xterm window, but it looks messed up. It seems that control sequences are printed as characters, and the ouput to the window is not scrolled but overwritten so that several layers of text overlay each other. When I type 'clear' to clear the screen and press enter, the screen isn't cleared. I can not mark text with the mouse pointer in the xterm window.
This happens when fvwm is used as a window manager. It does not happen, and xterm works fine, when i3 is used as a window manager.
I'll try to attach a screenshot. In the screenshot, you see an 'xterm -t' with the output of 'ls', showing the overlay effect.
Let me add that I usually never use the '-t' option with xterm, it only came up through this bug report.
Can I do something to help debug this?
Created attachment 775156 [details]
xterm window when running 'xterm -t', then running 'ls' in the xterm window
I just noticed that the output into the xterm window is displayed in the icon box while the xterm window is still empty. I'll add another screenshot showing this: starting 'xterm' without the '-t' option, running 'ls' in the xterm window.
Please note how the thumbnail image of the xterm window is displayed at the bottom left in the icon box. You can see the output of 'ls' in there while the actual xterm window is still empty.
Created attachment 775168 [details]
xterm window: started as 'xterm', running 'ls' in the xterm window
Please note the thumbnail of the xterm window in the icon box on the bottom left. It shows what is probably the output of 'ls' in the thumbnail while the actual xterm window is still empty.
Starting xterm with the "-t" option opens the Tek4014 window.
That's a feature, not a bug:
Starting without options, you may still have resources set which
have not been analyzed. An output from "appres XTerm" shows some
For testing with fvwm, I was looking at the default configuration
as installed by Redhat - it's possible that the problem lies in your
For the issue with sessions - some clue for that would be useful.
Starting xterm with "-t" - not much there. Incidentally, you can
have both vt100 and tek4014 windows visible at the same time.
Only one accepts input; output is updated on the one that accepts
input. Previous outputs are retained - however due to the attention
given vt100 window, it's possible that repainting tek4014 has been
overlooked in some scenario. So... the first thing to do in
investigating is to (for example) not assume that "-tb" means the
same thing as "-t". If you need that on some platforms, while it
is not available on others, use the "toolBar" resource setting.
For more information, see
> For testing with fvwm, I was looking at the default configuration
> as installed by Redhat - it's possible that the problem lies in your
> particular configuration...
You are right! When I do not start the FvwmIconBox module, xterm works fine.
I'm asking on the fvwm mailing list about this. Let's see what they say ...
Subject: xterm with FvwmIconBox on Fedora
From: lee <email@example.com>
Organization: my virtual residence
--text follows this line--
when starting FvwmIconBox with fvwm and then starting xterm, output to the
xterm window does not work, i. e. the window is blank until resized or
when the workspace is switched.
When (re-)starting fvwm without the FvwmIconBox module, xterm works
fine. Please see  for a more detailed reference.
The FvwmIconBox is configured as follows:
DestroyModuleConfig FvwmIconBox: *
# Note that icons are shown in the module
# ONLY if NoIcon commnand is applied.
Style "*" NoIcon
*FvwmIconBox: IconifiedTitleRelief 4
*FvwmIconBox: IconBack black
*FvwmIconBox: IconFore darkgreen
*FvwmIconBox: IconHiFore green
*FvwmIconBox: IconHiBack black
*FvwmIconBox: Back DarkSlateGray
*FvwmIconBox: Fore green
*FvwmIconBox: Geometry 4x4+5+915
*FvwmIconBox: MaxIconSize 64x38
*FvwmIconBox: Font "xft:Liberation:pixelsize=10:Medium"
*FvwmIconBox: SortIcons IconName
*FvwmIconBox: Padding 4
*FvwmIconBox: Lines 4
*FvwmIconBox: SBWidth 11
*FvwmIconBox: Placement Left Top
*FvwmIconBox: HideSC Horizontal
*FvwmIconBox: Mouse 1 Click RaiseLower
*FvwmIconBox: Mouse 1 DoubleClick Iconify
*FvwmIconBox: Mouse 2 Click Iconify -1, Focus
*FvwmIconBox: Mouse 3 Click Module FvwmIdent
Is there anything in there that breaks xterm? Can someone verify this
Debugger entered--Lisp error: (error "C-c C-c can do nothing useful at
Assuming the second problem discussed here was an fvwm bug, I'm closing this bug.
Please reopen if it turns out to be an xterm problem. Thanks.