I’m using OpenSuSE 12.1 with Gnome 3 and I have a really annoying issue where the terminals don’t seem to refresh correctly when things change in them. It only happens periodically, no idea what triggers it. But it’s particularly frequent when using Emacs and any terminal IRC client, but also happens sometimes (far less frequently) with the command line.
For instance, if I type something in an IRC client and hit enter, the room text doesn’t update on my screen and my message doesn’t leave the entry line even though it did send.
Another example is if I scroll in a file opened with Emacs, the text doesn’t actually change except on the line with the cursor.
When it happens, if I change the focus to another window, it refreshes correctly and displays what should be there.
Has anybody run into this before? Any ideas on how to fix it? It’s pretty irritating (but it’s a work computer, so I can’t afford the downtime right now to upgrade to 12.2).
I installed awhile ago, right when 12.1 came out, and haven’t done a fresh install since then.
I don’t remember when it started, but it’s been a long time (6-8 months maybe). So it’s not a “recent” issue, but I’m finally annoyed enough to ask about it because it seems to be happening more frequently. I have been keeping up to date both with the automatic updates and by running zypper dup.
It also doesn’t appear to be something like a memory leak – it will do it after a fresh reboot too.
In addition, zypper dup can be run from time to time to ensure you have the latest available packages from the various repositories that you have enabled. YOU (Yast Online Update) only addresses security updates from the official repositories
Which I took to mean “it’s a good idea to do this even when not upgrading the system to make sure things are up to date.” If that’s not the interpretation, that page should probably be changed
Regardless, the first time I ran that command on this system was this morning, and the problem predates that. So that wasn’t the cause.
> ask about it because it seems to be happening more frequently. I have
> been keeping up to date both with the automatic updates and by running
> zypper dup.
zypper dup is dangerous. Please print your list of repos. Do:
zypper lr --details
and copy all that, prompt et al, inside code tags.
I don’t want to get sidetracked by the dup thing – the first and only time I ran it was this morning and the refreshing problem has existed for many many months. So it’s definitely not due to running dup.
It’s GNOME Terminal that has the problems, not the virtual terminals.
Is it possible it’s due to some desktop effect or graphics card/driver?
On 11/28/2012 07:16 PM, tpg2114 wrote:
> that page should probably be changed
i am happy you pointed me to that page…because i do not know who
wrote to run “zypper dup” from time to time…nor do i know who approved
changing that page…but, i have changed it to “zypper up” and hope
whoever has the approval authority to release it correctly will do so,
and soon…
but, the problem is there are lots of new folks around with keys they
should not have.
On 11/28/2012 07:56 PM, tpg2114 wrote:
> I don’t want to get sidetracked by the dup thing – the first and only
> time I ran it was this morning and the refreshing problem has existed
> for many many months.
ok…don’t run dup from time to time (believe me), you can almost
safely use “zypper up” to catch all new software…personally i
normally use only “zypper patch” or YaST Online Update…but, that is
the safest way to have a constantly stable system…and, is not all
folks want…
other than that: i have not heard your symptoms before and i have no
idea why you are seeing the symptoms you are in gnome terminal…but, if
you find a way to repeatably cause the symptom to show in your system,
please log the bug to bugzilla: http://tinyurl.com/nzhq7j
maybe someone has seen your problem on their machine and will speak up,
soon…and, maybe even have a fix…so, just hang in.
> I don’t want to get sidetracked by the dup thing – the first and only
> time I ran it was this morning and the refreshing problem has existed
> for many many months. So it’s definitely not due to running dup.
Ok
Don’t do more dups, it is a powerful tool but can do nasty things. Just
do “zypper patch” (which downloads only official updates from the
updates repo above), or “zypper up” which updates things to newer
versions in the same repo (a dup doesn’t respect this).
Yes, that wiki page is incorrect, IMNSHO. Some people are very trigger
happy with dups.
> It’s GNOME Terminal that has the problems, not the virtual terminals.
>
> Is it possible it’s due to some desktop effect or graphics card/driver?
Yes, it is.
I have been away from my 12.1 machine for a month, so I’m not completely
sure, but I think I have seen redraw failures.
You can try other terminals. Me, I think that the classic xterm is the
best of all, even if idiosyncratic in its way of triggering menus.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
I have no idea how to reproduce the problem ever, but I did manage to grab a screenshot of it this morning.
I opened a file in Emacs and then closed it. You can see the buffer from Emacs is still on the terminal and it just overwrites only the current line of the window where the prompt is located. Bizarre (and annoying) stuff.
The picture is rather normal, isn’t it? You run a program (EMACS in this case) and it put lines on the terminal. Now the program finishes and the next line is the shell prompt. Isn’t that what you expect?
Probably not, because we are used to terminal emulations that have a memory and that know what was on the screen before and that will redraw this. But that can only work with more “intelligent” terminals. When you have a real TTY (ever seen one?) you can not scroll back the paper and retype. Same for a true glass TTY. My idea is that the terminal emulation thinks you have primitive TTY.
To make the story short, check
echo $TERM{/code]
It should be something like xterm.
I could be completley wrong, but it is worth a try isn't it?
If it always did it, every single time, then sure, I’d say it’s expected. But it’s not consistent and not something I can see how to reproduce. But:
> echo $TERM
xterm
Should it not be xterm? Whether it should or shouldn’t be – since sometimes it does clear the terminal and other times it doesn’t, it’s a bug in something either way because it does neither consistently
Plus, if I click on another window then it properly redraws itself, including in that screenshot case. So when I changed focus to my web browser, the Emacs part went away but the prompt and output from the few commands there stayed (as expected).
Yes, it should be “xterm” (when it is one, which is the case).
In the times that you would have different hardware terminals it should reflect the hardware, to be able for the application (shell and programs) to use the correct codes for managing the screen. Values like vt100, vt125, tty, etc. come to mind.
I just tried the real console (using Ctrl-Alt-F1) loged in and asked and got the value 'linux". Thus applicationa are able to adapt to the fact that this is not an Xterm, but the console.
And the value of ‘tty’ would op course mean that apart from NL and CR, TAB and BELL no special escape sequences are alowed.
In any case this does not help you and what you describe is far beyond this.
I am not sure if it is related, but can you show your version of the
graphics card and graphics card driver as well as the kernel version and
when it was last updated?
What you have looks completely consistent and also fits the graphics
card you have, so I can only ask for another blind shot.
If you do not login to gnome but instead choose for example icewm or twm
(at least one of those is always installed by default) on the login
dialog and run a terminal in icewm or twm does it also show the behavior
you see in gnome?
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.5 | GTX 650 Ti
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.3 | HD 3000
eCAFE 800: oS 11.4 i586 | AMD Geode LX 800@500MHz | 512MB | lamp server
