Bug 199256

Created attachment 96017 [details]
screenshot1

Created attachment 96018 [details]
screenshot2

Does this happen right away or after resizing the terminal.
Please try if this also appears when using an xterm.

No, I haven't touched the size of the screen - it's a konsole running maximized. 
I'll try it with an xterm.

It looks better on an xterm - but when e.g. the window regarding the BETA-status is popped up, I still have lots of black space.  It looks like the xterm reports a size of 80x24, even if the window is maximized.

Reassigning to the new maintainer of yast2-ncurses.

Update - looks the same in Alpha5.

*** Bug 210525 has been marked as a duplicate of this bug. ***

Does this happen with ncurses interface in the installed system, or during installation only?

Hi Katarina! I think I encountered the problem during the installation only.

I have only seen it during installation.

If I try to display licence dialog on the installed system, I cannot reproduce the problem. However, I can see black areas here and there all over the first stage of installation, already in the language selection dialog. The lowest line (Back-Abort-Next buttons) remains black all the time. It happens neither in the second stage, nor in ncurses interface on the installed system. 

Steffen, Marcus, any idea what might have changed (in inst-sys, yast start-up scripts, especially those display-related or wherever) since SLES10 release, because in SLES10 the problem doesn't seem to exists. 
Adding also Lukas to Cc: since this is installation-specific

I've located the culprit - it's the very first installation dialog (language selection). I've tried 1) running installation without this dialog (i.e. skip to installation mode selection immediately) 2) running this dialog on the installed system. It breaks ncurses UI in both cases.
Without this dialog, installation continues normally, without any black spaces or broken frames

Removing Steffen and Marcus (since this has probably nothing to do with inst-sys or X, framebuffer, whatever), adding Jiri to Cc:

I'll try if I can reproduce on SL10.1/SLES10

Errata: installation with language selection dialog breaks ncurses UI, without it works fine 
Cannot reproduce on SLES10 (yast2-country 2.13.24)

During my test, the problem occured after the call of
UI::SetConsoleFont ("K","lat2-16.psfu", "trivial", "" ,"sk_SK")

The problem might be in the function itself or in wrong parameters (?)

Ok, this is purely yast2-ncurses problem. NCurses::Refresh(), more specifically stdpan->refresh() fails for unknown reason... *cobe*

There's quite recent patch in ncurses library that somehow changes updating the screen on the consoles using magic cookies (which is exactly what we do when we're setting the console font). As I can't revert this patch because it might be needed somewhere else, I did my best to minimize its impact. 

Yet the issue can't be fully fixed. On the second installation screen ("Analyzing your computer"...) the top and the bottom line still remains black. But that's it and all other screens look fine (as far as I can tell). 

Fixed in yast2-ncurses 2.14.0 Please reopen if the problem persists ...

Strange, but the fix does not appear to work in Beta2, yast2-ncurses-2.14.2, on my laptop.

Werner, I have a problem here. See the screenshots in comment #2 and comment#3. The display during the installation became broken after the last bunch of patches (ncurses-5.5-20060513-patch.tar.bz2) has been added to ncurses library. 
I've tracked down the problem down to doupdate() ncurses function . It has been changed in ncurses-5.5-20060422.patch and what I understand from the description, it somehow influences the rendering on the display which uses magic cookies (which is exactly what YaST ncurses frontend does when it sets console font)
When I revert this patch and build ncurses library, all works well, the display looks perfect, exactly as it did before. I'll attach the patch shortly.

My question is: can we revert this patch or do we need it somewhere else? If we can't, do you have any idea how to work this around i.e. how to update screen so that it doesn't break ?  

Created attachment 104389 [details]
Offending patch

AFAIK we do not need this patch for our normal terminals or terminal emulators.
I'll do a look into the newest patch set of ncurses, maybe one of the next
patches will do this only for hpterm.

Btw: what does happen if you're using --diable-xmc-glitch at configure time?
Maybe the konsole does not support this feature but uses xterm terminfo
entry and the xterm _does_ support this feature.

I've built ncurses using --disable-xmc-glitch and it has exactly the same effect as reverting the patch (it does probably nothing else than undef's USE_XMC_SUPPORT or does it?). In other words, it works fine and the display is not broken during the installation

If there's no upstream patch for this issue, maybe it would be sufficient to build ncurses with this option, unless we need magic-cookies support somewhere else. 

I'll revert my 'fix' that tries to bypass this issue since it doesn't help anyway and leave the rest up to you

yast2-ncurses reverted
Reassigning ...

I've just disabled xmc support for ncurses now.  Maybe Thomas want to know that
the cause for the flaky ncurses or glitches was the change in curses done with
ncurses-5.5-20060422.patch as seen from comment #19 and patch in
attachment #104389 [details] of comment #20.

I thought I'd commented on this (perhaps am recalling a similar report).
You appear to be describing this bug:

20060701
        + revert a minor change for magic-cookie support from 20060513, which
          caused unexpected reset of attributes, e.g., when resizing test/view
          in color mode.

Hmmm ... the change from 20060422 (not 20060513) is already included in
the current patch level. I've searched all patches upto 20061014 and
found in 20060909 patch.sh the following in ncurses/tty/tty_update.c

  @@ -846,13 +904,18 @@
   
     cleanup:
       /*
  -     * Keep the physical screen in normal mode in case we get other
  -     * processes writing to the screen.
  +     * We would like to keep the physical screen in normal mode in case we get
  +     * other processes writing to the screen.  This goal cannot be met for
  +     * magic cookies since it interferes with attributes that may propagate
  +     * past the current position.
        */
  -    UpdateAttrs(normal);
  +#if USE_XMC_SUPPORT
  +    if (magic_cookie_glitch != 0)
  +#endif
  +       UpdateAttrs(normal);
   
       _nc_flush();
  -    curscr->_attrs = newscr->_attrs;
  +    WINDOW_ATTRS(curscr) = WINDOW_ATTRS(newscr);
   
   #if USE_TRACE_TIMES
       (void) times(&after);

which seems the cause of the described behaviour (please compare with
attachment #104389 [details] of comment #20).

yes - that's incorrect.  I thought I had fixed that.  The check should
have been for greater-than zero.

hmm - no (now that I can review it properly).  The last change I made
was to make it check for inequality.  Normally xmc is negative (inactive),
and it would be greater than zero for wyse terminals.  The reason for that
chunk was to handle hpterm.  That particular chunk will behave the same
for Linux console, xterm, etc., as in the 5.5 release.

It sounds as if there is some (other) place where the changes for xmc are
breaking things.  The comment #17 hints that there is a different terminfo
which is being used, but there's not enough information to guess why it would
have worked _without_ the xmc changes.

(In reply to comment #29)
> hmm - no (now that I can review it properly).  The last change I made
> was to make it check for inequality.  Normally xmc is negative (inactive),
> and it would be greater than zero for wyse terminals. 

The last patchlevel in SUSE ncurses is 5.5-20060513, so the check for inequality, that is, this code snippet: 
 #if USE_XMC_SUPPORT
-    if (magic_cookie_glitch != 0)
+    if (magic_cookie_glitch > 0)
 #endif
        UpdateAttrs(normal);

is there. Yet it breaks text-mode YaST during installation. Without this check (i.e. if UpdateAttrs() is called at all times), or if ncurses are compiled without xmc support, it works fine.

> It sounds as if there is some (other) place where the changes for xmc are
> breaking things.  The comment #17 hints that there is a different terminfo
> which is being used, but there's not enough information to guess why it would
> have worked _without_ the xmc changes.

Uff.. let me make comment #17 more clear, since I'm not aware of pointing to different terminfo being used there ;-) 
At one point (language selection dialog) a console font is set. At the end, setting the font comes down to doupdate() call and that breaks the display.  Once the display is broken, it remains flaky for the rest of the installation, in every consequent dialog, even though this is the only one doupdate() call being used.
What I've done to fix the issue, is that I disabled calling doupdate(), but as comment #18 suggest, it didn't help. What definitely helped, was leaving language selection dialog entirely from installation workflow, but that's definitely not a way to go for us ;-) :-)

This is 100% reproducible with 'linux' terminfo and with KDE Konsole (which uses 'xterm' terminfo).

As I noted in #29, my comment in #28 was not correct...

>The last patchlevel in SUSE ncurses is 5.5-20060513, so the check for

This is my comment on the fix:

revision 1.236
date: 2006/07/02 00:35:56;  author: tom;  state: Exp;  lines: +2 -2
that magic-cookie fix in 20060513 broke colors when I was doing
        xterm -e test/view -c Makefile
and resized the screen.

That's the last change I made to that chunk.  Reading the thread,
it's after the last change in your snapshot.

Regarding the terminfo: 'linux' terminfo doesn't use magic cookies.
Those are a flag that tells curses how many cells are reserved when
switching video attributes.  It would be possible to run ncurses
apps on something like hpterm, but without the magic cookie code
in ncurses, that would require some application workarounds - which
would have broken once ncurses fixes things.

AFAIS terminfo of xterm, konsole, and linux virtual console do not show
the numeric variable xmc. I guess that in this case the variable xmc is
then set to zero? And tere are a large number of terminfo descriptions
which include explicitly xmc#0 (e.g. hpterm) ... how does this fit
together?

Unspecified numbers are stored as -1'.  The chunk we're talking about,
was (in 5.5 release and before) simply

    UpdateAttrs(normal);

without any if-statement.  The point of the change was to preserve the
5.5 behavior for terminals which do not have xmc set, and to handle a
special case for xmc#0 which appears in hpterm.  I made several small
fixes to handle hpterm, and it's working reasonably well (not perfect,
but usable).  To make that perfect, there's some ugly code needed to
work around an attribute-reset in mvcur.c

There may be some place in the ifdef'd logic which behaves different -
that's the point of the bug report.  But I don't think it's in this
place.

Is there a standalone script that I can run to test this bug?
(I have a SuSE 10.0, but don't have time/resources at this point
to reinstall anything).

Created attachment 107433 [details]
A testcase script

You can try to run this small script (it will display language selection dialog, in which the screen corruption first occurs). Just run as root 'yast test.ycp'

But I'm afraid you will not reproduce in SUSE 10.0, since the display glitches were first introduced with some of openSUSE 10.2 alphas

I tried running the script, but it only flashes a little and exits.
Looking at the existing scripts on 10.0, it seems that none of them
declare "select_language".  I upgraded the ncurses libraries on that
box to my current version, and running the normal language selection
dialog with yast doesn't show any problem (using uxterm).

As with the report on newterm and the serial terminal - it would be
possible to get some useful information by tracing ncurses (though
somewhat complicated in this case by the use of shell scripts with
multiple processes using ncurses).