| Summary: | x11-terms/xterm-236 window resizing does not get propagated to shell applications | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Niko Efthymiou <nefthy-gentoo-bugzilla> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dickey, leon+gentoo, petr.pisar, stefan |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Niko Efthymiou
2008-08-03 19:33:10 UTC
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 configure-notify events. 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*. |
