[SOLVED] Slackware-current artifact when running dialog

igadoter · 10-29-2018, 11:23 AM

I added picture. It looks like that only in virtual console (framebuffer). In emulators is OK. Little info about graphic card (on very old laptop)

Code:

# dmesg | grep drm
[   16.570207] [drm] Replacing VGA console driver
[   16.571118] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   16.571126] [drm] Driver supports precise vblank timestamp query.
[   16.585985] [drm] RC6 disabled, disabling runtime PM support
[   16.586051] [drm] Initialized overlay support.
[   16.586526] [drm] Initialized i915 1.6.0 20180719 for 0000:00:02.0 on minor 0
[   16.751058] fbcon: inteldrmfb (fb0) is primary device
[   17.566865] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

hm,maybe I should buy a new one?

ponce · 10-29-2018, 12:10 PM

EDIT: ooops, wrong thread, moved the post here...

igadoter · 10-29-2018, 12:22 PM

I didn't upgrade. Just run

Code:

$ cd dialog-1.3-20181022/          # build directory
$ ./dialog --msgbox hello 30 40    # this binary is being built myself and is causing segfault

I still have original version installed as usally '/usr/bin/dialog'. This original (!) version is causing artifact. Probably it is issue of intel frame buffer driver. I will test this without frame buffer, VGA-only. I suppose it will be OK.

volkerdi · 10-29-2018, 02:09 PM

I've compiled the latest dialog here and see the same artifact on the console (using a Radeon card here), so a newer dialog won't fix it. However, I noticed that if I set TERM=screen rather than the default TERM=linux that the artifact goes away. So I suspect it's a problem with the linux console terminfo entry. I'm not sure how to go about adjusting that (or if that's even the right approach here)... any help appreciated.

igadoter · 10-29-2018, 03:39 PM

Quote:

Originally Posted by volkerdi

However, I noticed that if I set TERM=screen rather than the default TERM=linux that the artifact goes away.

I run this

Code:

$ for i in linux* ; do export $TERM="$i" ; xwmconfig ; done

in terminfo directory. I found

Code:

$ export TERM="linux-m1"

fixes artifact. So what's the difference between "linux" and "linux-m1"? In VGA-only mode there is no artifact.

abga · 10-29-2018, 04:24 PM

Couldn't this be actually a ncurses issue? I remember iptraf-ng was affected by artifacts for a long period after a ncurses update on -current (can't really remember exactly when - I guess it was last year) It got fixed recently by another ncurses update.
Some other feedback on ncurses:
https://github.com/dpayne/cli-visualizer/issues/62

@igadoter

Code:

/usr/bin/toe | grep linux

linux linux console
...
linux-m1 Linux Minitel 1 "like" Couleurs

You can also check the terminals in /usr/lib/terminfo/

igadoter · 10-29-2018, 04:35 PM

I just compared these terminfo descriptions

Code:

$ infocmp linux linux-m1
comparing linux to linux-m1.
    comparing booleans.
        bce: T:F.
        eo: T:F.
        xon: T:F.
    comparing numbers.
        ncv: 18, 16.
    comparing strings.
        acsc: '++\,\,--..00__``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}c~~', 'a\261f\370g\361h\260j\274k\273l\311m\310n\316q\315t\314u\271v\312w\313x\272y\363z\362{\343|\252~\372'.
        civis: '\E[?25l\E[?1c', '\E[?25l'.
        cnorm: '\E[?25h\E[?0c', '\E[?25h'.
        cub: '\E[%p1%dD', NULL.
        cud: '\E[%p1%dB', NULL.
        cuf: '\E[%p1%dC', NULL.
        cuu: '\E[%p1%dA', NULL.
        cvvis: '\E[?25h\E[?8c', NULL.
        enacs: '\E)0', '\E)U'.
        flash: '\E[?5h$<200/>\E[?5l', '\E[?5h$<100/>\E[?5l'.
        hpa: '\E[%i%p1%dG', '\E[%i%p1%d`'.
        ich: '\E[%p1%d@', NULL.
        ich1: '\E[@', NULL.
        initc: '\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x', '\E]P%p1%{15}%&%X%p2%{255}%&%02X%p3%{255}%&%02X%p4%{255}%&%02X'.
        is2: NULL, '\E]R\E]P3FFFF80\E[?8c'.
        ka1: NULL, '\EOw'.
        ka3: NULL, '\EOy'.
        kc1: NULL, '\EOq'.
        kc3: NULL, '\EOs'.
        kcbt: '\E[Z', '\E^I'.
        kclr: NULL, '\E\r'.
        kdl1: NULL, '\E\E[A'.
        kent: NULL, '\EOM'.
        kil1: NULL, '\E\E[B'.
        kspd: '^Z', NULL.
        nel: '\r\n', '\EE'.
        oc: '\E]R', '\E]R\E]P3FFFF80'.
        rmul: '\E[24m', NULL.
        rs1: '\Ec\E]R', '\Ec'.                                                                                                                                                      
        rs3: NULL, '\E[37;40m\E[8]'.                                                                                                                                                
        sgr: '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;', NULL.                                                                 
        sgr0: '\E[m\017', '\E[m'.                                                                                                                                                   
        smul: '\E[4m', NULL.                                                                                                                                                        
        u9: '\E[c', '\EZ'.

I don't feel comfortable with this. I have no idea - these differences are minor or major. I expected a few only.

Edit: removed I was pointing in wrong direction. linux-m1 stands for 'Linux Minitel 1 "like" Couleurs'.

GazL · 10-29-2018, 08:59 PM

The problem seems to be triggered by the BCE feature. If you recompile the 'linux' terminfo definition without it then you don't see the screen corruption. Having said that, BCE is a really nice feature that one really doesn't want to throw out if it's available: without it any background has to be rendered by drawing a space with the appropriate colour attributes in each and every cell of the screen.

I knocked up a quick test case to try and see if ncurses was doing the right thing, and it seems to render correctly in both BCE and non-BCE environments. My initial suspicions lean towards dialog itself being at fault, but it could still be something weird going on in ncurses. Without digging into the source code and debugging there's no way to know for sure.

Code:

/* testing.c
 *  Investigate ncurses and background colour erase (BCE)
 *  Fills the screen with a blue background and then 
 *  renders a black window with white text.
 *
 *  compile:
 *    cc -lncursesw testing.c
 */

#define _XOPEN_SOURCE 700

#include <curses.h>

#include <locale.h>

int main( int argc, char **argv)
{
  cchar_t bg_cchar;
  wchar_t bg_wch = L' ';
  wint_t k;
  WINDOW *my_win ;
  
  setlocale( LC_ALL, "");
  initscr();
  my_win = newwin( 10,40,5,20);

  start_color();
  init_pair(1, COLOR_WHITE, COLOR_BLUE);
  setcchar( &bg_cchar, &bg_wch, (attr_t) 0, 1, NULL);
  bkgrnd(&bg_cchar);
  clear();
  refresh();

  mvwprintw(my_win, 0, 1, "Hello");   
  wrefresh(my_win);  
  
  get_wch(&k);
  endwin();
  return 0;
}

Pixxt · 10-29-2018, 11:58 PM

Slackware 14.2 Kernel 4.19 did this for me, going back 4.18.x did not have the issue. Try downgrading your kernel in current and see if it still does it.

GazL · 10-30-2018, 07:25 AM

Yes, apologies to dialog and ncurses. It appears that the \033[nK "erase line" sequences in the linux terminal emulator are buggy! Specifically, they don't seem to honor the BCE colour when erasing, yet if you switch away from the virtual console with ctrl-alt-fn and then back again, the missing background colour magically reappears. If it worked previously then it smells like a kernel regression.

This sequence demonstrates the issue:

echo -e "\033[44m\033[20G\033[1K<-- Missing background"

The \033[2K (Erase whole line) variant also shows the same issue when the cursor is not positioned on the start of a line.

The default \033[K (erase from cursor to end of line) variant appears to work correctly regardless of cursor position.

abga · 10-30-2018, 01:07 PM

I'm only running Slack -current on ARM (Raspberry Pi) and using the official kernel from Raspberry. Due to the kernel USB bug, later on - broken firmware (still) and messed up kernel sources sync (need them to patch a driver) I'm stuck with the kernel 4.4.50-v7+ from March/April 2017.
My report from #6 about the iptraf-ng artifacts (totally messed up table borders) after the ncurses updates (late 2017 or beginning of 2018), and the subsequent fix, again by updating ncurses, was about these ARM systems always running the kernel 4.4.50-v7+.
ncurses changed (several updates) and maybe some other components that are related to the terminals, however, the kernel was the same all the time.

igadoter · 10-31-2018, 05:03 AM

Removed. My mistake. It is still unsolved. Even with recent update terminfo database. But at it was pointed by @Pixxt downgrade of the kernel removes appearance of artifact.

volkerdi · 10-31-2018, 01:52 PM

I expect a newer 4.19.x kernel will end up resolving this issue.

volkerdi · 11-04-2018, 02:15 PM

Still not working. Easy reproducer within the kernel itself - on a text console, run "make menuconfig" and then hit "/".

igadoter · 11-04-2018, 07:23 PM

I noticed that artifact disappears for large in width windows. On my console '150' in width is critical. With this width artifact is just small black strip on the left.