When resizing the xterm window the event does not get propagate to the applications running in the xterm (i.e. mutt or vim). I am not exactly sure if this is an xterm bug or not.
Any Idea on how to debug this?
Steps to Reproduce:
1. start xterm
2. open a file in vim
3. maximize xterm
display does not resize to window size.
display should resize to window size
mail-client/mutt-1.5.16 USE="crypt gdbm gpgme imap mbox nls pop sasl sidebar smtp ssl -berkdb -debug -gnutls -idn -nntp -qdbm -smime -vanilla" 3,502 kB
x11-terms/xterm-236 USE="truetype unicode -Xaw3d -paste64 -toolbar" 0 kB R ] app-editors/vim-7.1.319 USE="acl bash-completion cscope nls python vim-pager vim-with-x -gpm -minimal -perl -ruby" 9,051 kB
x11-wm/fluxbox-1.0.0-r2 USE="imlib kde nls slit toolbar truetype vim-syntax xinerama -gnome" 750 kB
$ emerge --info
Portage 2.2_rc5 (default-linux/x86/2007.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.26-gentoo i686)
System uname: Linux-2.6.26-gentoo-i686-mobile_AMD_Athlon-tm-_XP-M_2500+-with-glibc2.0
Timestamp of tree: Sun, 03 Aug 2008 18:45:02 +0000
dev-java/java-config: 1.3.7, 2.1.6-r1
sys-devel/autoconf: 2.13, 2.62-r1
sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
CFLAGS="-march=athlon-xp -O2 -pipe -ggdb"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/qmail/alias /var/qmail/control /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe -ggdb"
FEATURES="distlocks parallel-fetch preserve-libs sandbox sfperms splitdebug strict unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="3dnow 3dnowext X a52 aac aalib ac3 acl alsa amr apache2 audiofile bash-completion bluetooth bzip2 cdio cli cracklib crypt dbus dri dvd dvdnav dvdread encode exif fam fbcon ffmpeg fftw flac font-server fontconfig fortran gdbm gif hal iconv imagemagick isdnlog jack jpeg jpeg2k ladspa lame laptop libsamplerate mad midi mmx mmxext mng mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly nsplugin offensive ogg openmp pam pcre pdf png pnm pppd readline reflection session sndfile speex spell spl sse ssl svg tcpd tetex theora tiff truetype unicode usb vidx vim-pager vim-syntax vorbis win32codecs wmf x264 x86 xinerama xorg xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="sis"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
My mutt resizes fine in gnome-terminal, so I'm guessing it is xterm-related.
Same on PPC, do you see anything like going wrong with unicode too?
Any hints how to debug this?
Is this new with #236? (The last resize-fix I made was in #234).
it definitely happens with 236 and I think this is also where it started happening.
Rereading my notes, in #236, this _could_ be related:
* correct computation for toolbar height; layout manager already
takes into account borderWidth resource.
The quick way to check would be to test #235; I can provide a diff with
just this change reverted, if that helps.
I compiled #235 and it also shows the same problem. Since I have -toolbar in the USE-flags I don't see how the toolbar hight, could have anything to do with this, but I might be wrong.
I can reproduce a problem like this using the OpenBox window manager.
It seems that an optimization that I made a while back, and improved
in #236 is either causing the problem, or exposing it. Removing the
optimization makes the problem go away (for me...). I'll have that
change in #237.
(In reply to comment #8)
> I can reproduce a problem like this using the OpenBox window manager.
> It seems that an optimization that I made a while back, and improved
> in #236 is either causing the problem, or exposing it. Removing the
> optimization makes the problem go away (for me...). I'll have that
> change in #237.
Can you explain why it only happens on specific platforms and not on all? For example on my PPC I hit it, while my AMD64 is without it. Would it be possible it is related to another library?
I suspect it's related to timing (and/or window manager).
The optimization was discarding events that occurred "close" together.
It looks like OpenBox makes its adjustments in steps (and issues more
than one change) rather than doing one step. So some of that may apply
to your configuration.
(In reply to comment #10)
> I suspect it's related to timing (and/or window manager).
Both XFCE4, and the event that gets b0rked on PPC is maximize.
I'd expect amd64 to be faster than ppc
(but don't know - just guessing),
while I'd expect the change in behavior to happen where the
events could stack up a little, as xterm responds to the
I just added xterm 237 to the tree, so it should hit rsync mirrors within an hour.
It still does not work for me.
I've noticed this bug after massive world upgrade yesterday after two and half months off-line.
However almost nothing related to xterm has change. Version of xterm (232), ncurses, basic X11 libraries does not changed. The only related changes are:
x11-apps/xinit-1.0.5-r2 => 1.0.5-r1
x11-proto/xf86driproto-2.0.3 => 2.0.4
x11-drivers/nvidia-drivers-96.43.05 => 96.43.07
sys-kernel/gentoo-sources-2.6.25-r6 => 2.6.26-r1
I'm pretty sure resize worked very well before. I got also the same problem runnig less or vim on remote machine with local xterm. I suspect kernel pty handling.
I tested xterm-237 without success.
My window manager is blackbox-0.70.1.
Very spectacular problem demonstrates x11-misc/xscreensaver-5.05: Runnig screen, echo $LINES $COLUMS shows 24 80. After window maximizating the variables are not updated. I.e. still 24 80. Then after restoring original size the variables changes to values proper for maximazed xterm (in my case it's 56 166). Succesive maximization reverts the value back to 24 80 and size restore reverts back to again bad 56 166. The screen seems to be shifted one step back from xterm idea about terminal size.
"Linux-2.6.26", if I recall properly is a version that broke resizing,
and is fixed in .27
(In reply to comment #16)
> "Linux-2.6.26", if I recall properly is a version that broke resizing,
> and is fixed in .27
You are right. After booting older kernel 2.6.25-gentoo-r6 resizing works good as before.
Sounds good - I saw the discussion of this bug a few weeks ago,
and happened to notice the kernel version on revisiting this bug.
i can config that this bug does not accour with 2.6.17. Still wonder why the kernel has to do anything with this.. But anyway, I am closing this bug.
I can confirm, that 2.6.26-gentoo-r4 causes the bug, I reproduced it using xterm & rxvt-unicode with screen & mc and under xfce4 & awesome on x86.
I also confirm that 2.6.25-gentoo-r8 works fine, I've not tested 2.6.27*.