Version: 2.1 (using KDE 4.1.3) Compiler: gcc-4.3.2-7.i386 OS: Linux Installed from: Fedora RPMs When a new 80x40 konsole window is launched and a text file with more than 24 lines (for example /etc/passwd) is opened using vim, everything appears to work fine. When a new tab is created in the same konsole window and the file is opened using vim, the vim content appears to be limited to 80x24 even though the window itself is still 80x40. I was able to reproduce this issue using different user accounts and does not appear to be related to any environment settings. Interestingly, when a new tab is created that displays this type of behaviour (where the vim content is truncated to 24 lines) is detached, the new window behaves normally (vim output is the full length of the window). Also, this behaviour isn't limited to just the first tab, but to all subsequent tabs created after the initial window is launched.
As an update, when the entire window is resized say from 80x40 to 80x30 then back to 80x40, opening a text file in vim appears to work normally again.
i reported this to fedora bugzilla, with more detail and steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=477359 resizing the window sends SIGWINCH to the shells which causes them to resize. It only happens when the window is initially 80x40, which seems weird to me.
The title of this bug should be changed as it has nothing to do with vim, any app that uses the terminal's alternate screen buffer will use LINES=24. e.g. man, less, info etc.
Jon, thanks for looking into this. I agree based on your feedback the title of this bug should be changed, except it's not clear how to do this. Is this something I can do or does an admin have to make the change?
I'm not sure either, looks like this bugzilla is configured so it can't be changed. Maybe someone else with suitable privileges can do it. In any case there's enough ino here to reproduce it, so hopefully someone will find the problem.
Can anyone confirm this, and change the title? Still present with latest Fedora packages: Konsole Version 2.2 Using KDE 4.2.00 (KDE 4.2.0)
Surely someone is capable of following the steps to reproduce and at least confirming this bug? Here are my steps to reproduce, taken from https://bugzilla.redhat.com/show_bug.cgi?id=477359 1. Close all konsole windows 2. Open new konsole window, resize to 80x40, close window. 3. Open konsole window then open a new tab 4. In the new tab run 'echo $LINES ; resize ; echo $LINES' Actual results: $ echo $LINES ; resize ; echo $LINES 24 COLUMNS=80; LINES=40; export COLUMNS LINES; 40 Expected results: $ echo $LINES ; resize ; echo $LINES 40 COLUMNS=80; LINES=40; export COLUMNS LINES; 40 As shown by the actual results, the problem is that creating a new tab in an 80x40 konsole window results in LINES=24 initially, confusing apps using ncurses. Resizing the window or running 'resize' corrects the value of $LINES, but should nto be necessary.
Confirmed with trunk r972351
Thanks for confirming it Robert. Now, if anyone has a clue where to start looking to fix this, I'll happily fix it myself, as I find it very annoying. I grabbed the konsole code and couldn't find anything obvious that caused it, but I don't know the code and didn't spend long familiarising myself with it. It seems that the konsole process has some value of LINES that differs from the environment of the process in the first tab, because although the first tab has the correct values, opening a new tab does not. Also, this aspect of the behaviour seems relevant: 1. Close all konsole windows 2. Open new konsole window, resize to 80x40, close window. 3a. Open konsole window. 3b. Maximise the konsole window. 3c. Restore the konsole window to 80x40. 3d. Open new tab. 4. In the new tab run 'echo $LINES ; resize ; echo $LINES' Even after resizing (causing a SIGWINCH to be delivered to the process in the first tab) the second and subsequent tabs do not have the right value. That implies to me that the values are being stored somewhere else, separate from the first tab. I don't understand why the first tab's shell gets the right values if konsole doesn't have them, and I don't understand why this *only* happens with an 80x40 window, not any other size. As I said, if anyone can give me a pointer to the relevant bit of Konsole, the KDE libs, or Qt, I'll try to fix it, but I need a clue as most of my code runs in headless servers and libraries, not GUIs.
In kdebase/apps/konsole/src: The size of the the window as seen by the terminal application in lines/columns is set in Pty::setWindowSize(). The sequence of calls leading from the display widget (TerminalDisplay) when it is created or resized by the user to actually changing the size of the terminal window is: TerminalDisplay::resizeEvent() -> TerminalDisplay::changedContentSizeSignal() -> Session::onViewSizeChange() -> Session::updateTerminalSize() -> Emulation::setImageSize() -> Session::imageSizeChanged() -> Session::updateWindowSize() -> Pty::setWindowSize()
In Emulation.cpp, 40,80 is the default size of the screen. There is a 'if' check in the setImageSize method that is not triggered with the actual setting of the window is 40,80 and therefore 'imageSizeChanged' is not emitted. This emit-ting is what sets the shell's lines/columns.
thanks guys! So one solution would be to add a flag to the Emulation class, initially false and set to true when imageSizeChanged is emitted. The condition in setImageSize() would check the flag as well as comparing the current sizes to the new size. That would mean checking the flag every time, when it's only needed on the first setImageSize call for a given object, so I'll look into a better fix.
(In reply to comment #11) > In Emulation.cpp, 40,80 is the default size of the screen. > > There is a 'if' check in the setImageSize method that is not triggered with the > actual setting of the window is 40,80 and therefore 'imageSizeChanged' is not > emitted. This emit-ting is what sets the shell's lines/columns. I'm running kde SC 4.4 in Fedora 12 kdebase-4.4.0-3.fc12.i686 and this bug happens again but previous KDE SC 4.4 RCs ( 4.3.98 4.3.95) hasn't this bug Gabriel
Confirming this too. I'm running KDE 4.4.2 on Debian unstable (packages from Debian experimental). For me this bug manifests like this: when I start KDE, my session restores an 80x40 Konsole window with multiple tabs. On the tab that's active when Konsole is launched, in-terminal applications are correctly being told that the terminal is 80x40. On any other tab, however, they think that the terminal is 80x24. If I resize Konsole the size information becomes correct for the active tab only; so I have to repeat a resizing ritual for every tab I want to "fix".
It seems that konsole swaps informations of COLUMNS and LINES in Ubuntu 9.10 Karmic: ii konsole 4:4.3.2-0ubuntu3 $ resize COLUMNS=121; LINES=45; export COLUMNS LINES; $ vim /tmp/a then i tell vim that the console is 122 columns (:set co=122) then i quit and the konsole is totally screwed $ echo $COLUMNS $LINES 45 122 until i resize it with mouse (just enlarge it by one column) $ echo $COLUMNS $LINES 122 45 I have no trouble if i do the same in xterm.
In gnome-terminal (from ubuntu karmic) resizing the above (broken?) example works flawlessly, and a resize inside vi induces a resize of the terminal. ii gnome-terminal 2.28.1-0ubuntu1
Issue still exists with Konsole 2.5.2 in KDE 4.5.2 (backports PPA from Kubuntu 10.10).
(The following is from bug 203185, and I suspect the issue is related.) I've written some example C code to trigger the bug. It's getting the terminal size using the TIOCGWINSZ ioctl to get the terminal size. The TIOCGWINSZ ioctl call reports the correct size only when not using Konsole's -e option. With the -e option, the size is always reported as 0x0: #include <stdio.h> #include <sys/ioctl.h> #include <termios.h> int main( void ) { struct winsize size; size.ws_col = size.ws_row = 0; if (ioctl(0, TIOCGWINSZ, &size) < 0) { printf("Error: ioctl failed.\n"); return 1; } printf("Terminal size: %dx%d\n", size.ws_col, size.ws_row); printf("[ENTER to quit.]"); scanf("%*[^\n]"); return 0; } Build the program (gcc filename.c) and run it first with: ./a.out and then with: konsole -e ./a.out If in the second case the result is 0x0, then you confirmed the bug.
Created attachment 58619 [details] Flag to emit imageSizeChanged once (In reply to comment #12) > So one solution would be to add a flag to the Emulation class, initially > false and set to true when imageSizeChanged is emitted. The condition in > setImageSize() would check the flag as well as comparing the current sizes > to the new size. Implemented this, patch attached. Works as expected. Thanks for pointing out the relevant piece of code! > That would mean checking the flag every time, when it's only needed on the > first setImageSize call for a given object, so I'll look into a better fix. Added a gdb breakpoint and found that there are two calls to Emulation::setImageSize during creation of a new window. But boths parts go through the resize codepath for a long while, so adding a simple "emit size setting now" call to either one seemed too much of a burden. After all, resizes are slow as hell already, that bit of added code will hardly make a difference. An alternative would be to change the default screen sizes in the constructor. One could either choose 24x80 as the default screen size, as this is what most apps seem to expect, or 1x1, as this is almost certainly different from any screen size actually used. The first approach relies on defaults which need not be fixed, and should therefore be avoided. Both approaches force a resize of the screens created in the constructor, which is some overhead I'd like to avoid.
(In reply to comment #15) > It seems that konsole swaps informations of COLUMNS and LINES in Ubuntu 9.10 That's bug 245746 I'd say. I doubt my patch will fix that, but give it a try. (In reply to comment #18) > (The following is from bug 203185, and I suspect the issue is related.) Only remotely related, I'd say: this here is about wrong size while the window shows, while that one is about wrong size at app startup, while the window is still invisible.
Created attachment 62013 [details] make sure pty device have proper size info This bug and #203185 are caused by the same reason: when the terminal process(shell,vi,mc,etc) starts and queries the pty device about size , the pty device has not been told of the proper size by konsole. So the initial size , 0x0, is returned to the terminal process. The details are not the same : a). in this bug, SIGNAL(imageSizeChanged()) is not emitted, because the initial size and default size happens to be the same, 80x40. b). in #203185, SIGNAL(imageSizeChanged()) is emitted, but terminal process start too quickly so it still gets 0x0. That is a race condition. The attached patch tries to guarantee that when terminal process starts and queries the pty device about size, it always get the proper size. It's similar to martin's patch, but also considers #203185. This patch uses a hard-coded delay, which is not elegant but works well in practice. Feel free to make any modification to it.
*** Bug 229058 has been marked as a duplicate of this bug. ***
*** Bug 244183 has been marked as a duplicate of this bug. ***
*** Bug 236405 has been marked as a duplicate of this bug. ***
Hi, In which KDE release will this bug be patched?
*** Bug 199714 has been marked as a duplicate of this bug. ***
*** Bug 173999 has been marked as a duplicate of this bug. ***
Git commit 7e00edd5166096feb59ffa694b6a6ff858fe1924 by Kurt Hindenburg. Committed on 05/08/2011 at 16:40. Pushed by hindenburg into branch 'master'. Make sure pty device has right size before terminal process queries it. Whenever TeminalDisplay is resized, konsole tells the underlying pty device its new size by calling Pty::setWindowSize(). However, current code can't guarantee when the terminal process starts and queries the pty device about its size, the pty device already has the right info. This has caused some long known bugs, such as #176902. This patch tries to guarantee that important assumption. It currently uses a hard-coded small delay, which works pretty well in practice although not that elegant. Patch by Jekyll Wu <adaptee@gmail.com> I think this is better than leaving the situation as it is. This may be backported if no issues are found. BUG: 173999 BUG: 176902 BUG: 203185 BUG: 229058 REVIEW: 102061 FIXED-IN: 4.8 M +7 -0 src/Emulation.h M +0 -1 src/Application.cpp M +1 -0 src/Session.cpp M +30 -6 src/Emulation.cpp http://commits.kde.org/konsole/7e00edd5166096feb59ffa694b6a6ff858fe1924
Many thanks for getting this fixed!
*** Bug 284523 has been marked as a duplicate of this bug. ***
80 columns by 40 lines still malfunctioning as of konsole 2.3.3 on kde 4.3.4 At first I thought it was specifically related to the show new/close tab buttons, but the results are the same with or without the option checked. Resizing window to anything but 80x40 seems to clear up the situation. stty -a reports line=0 regardless of the position of the prompt within the window.
(In reply to comment #31) > 80 columns by 40 lines still malfunctioning as of konsole 2.3.3 on kde 4.3.4 That version is quite old, comment 17 already confirms the bug was still present in kde 4.5 so of course it's in 4.3