bugGNU Screen - Bugs: bug #46273, screen 4.3.1 broken nmon's display...

 
 

bug #46273: screen 4.3.1 broken nmon's display and alsamixer

Submitter:  Joe Chen <scsichen>
Submitted:  Thu 22 Oct 2015 11:42:34 AM UTC
   
 
Category:  User Interface Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  4.3.1
Fixed Release:  None Planned Release:  4.3.1
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Oct 2015 02:24:29 PM UTC, comment #20: 

Thanks to Amadeusz and Micah. When I add this option to screenrc and problem is solved.

Thanks again... ^^y

Joe Chen <scsichen>
Tue 27 Oct 2015 09:54:54 PM UTC, comment #19: 

for Joe Chen: all these comments add a bunch more to read that you don't really need to sift through; Amadeusz identified your fix a couple posts back:

> try adding "cjkwidth off" to your ~/.screenrc and it will probably work again.

Micah Cowan <micahcowan>
Tue 27 Oct 2015 09:28:05 PM UTC, comment #18: 


> > I don't understand the reasoning behind the conditional setting of cjkwidth.


> Um... didn't you apply of this patch? ;)


LOL, well now, apparently I did! Guess I missed that pertinent fact while I was perusing the git log. :D

Well then. I guess I wish I had avoided the locale-specific defaulting behavior. :) ...You certainly have my blessing to change the default for consistency (not that you need it anyway). Historic practice should trump "improvement" here, anyway - obviously I broke things for Joe that had been working for eons.

> because from what I've read so far, there is no standard for how wide characters are in terminal.


So, I'm not quite sure I'd say that: Unicode definitely represents a number of codepoints as unambiguously full-width, and it's pretty much impossible to represent most CJK characters in a standard terminal column. Identifying a character like 機 is difficult enough without trying to squeze it into half the real estate!

But, obviously, there are gaps in the standards that exist, and the "ambiguous" set of characters identified in Unicode are probably intended to represent characters that have varied between different implementations. I suspect the interpretation of some of those characters (such as the latin1 ones) as full width, even in East Asian software, is not as common practice these days as it might have been in the past... but there may still be exceptions, and I don't know whether some characters in that same "ambiguous" set might be more likely than others to be displayed in full-width versions.

Your plan to allow per-character override is probably a sensible one. You'd probably be safe to restrict overrides to ambiguous characters only... but as long as you're adding the feature, I don't really see the point in doing so.

I think there's maybe also a zero-width control character in Unicode that controls whether to display following characters as full-width, even if they otherwise wouldn't have been (like for ascii). I have no idea if that's supported in screen (but a look at utf8_is_double suggests it's not, unless that's handled elsewhere). But it must not see wide use, as I've never encountered a complaint about it.

Micah Cowan <micahcowan>
Tue 27 Oct 2015 09:02:06 PM UTC, comment #17: 


> I don't understand the reasoning behind the conditional setting of cjkwidth.

Um... didn't you apply of this patch? ;)

Original bug seems to be https://savannah.gnu.org/bugs/?16666 which has a bit more description.

Frankly for v5 I plan to allow users setting per character width (overriding results of screens wcwidth - ut8_isdouble), because from what I've read so far, there is no standard for how wide characters are in terminal. But if you know one, I'll gladly read it.
But going back on topic I probably can change default, to be same on all locales.

Amadeusz Sławiński <amade>
Group administrator
Tue 27 Oct 2015 08:40:35 PM UTC, comment #16: 

I think Amadeusz nailed it.

Joe, thanks for the updated files, they seem to be much better.

$ reseq --replay screen.tsq

seems to demonstrate that screen is issuing sequences that aren't interpreted properly by my xterm-compatible term (iTerm2 on the Mac at the moment).

I was able to reproduce inside screen with

$ reseq --replay nmon.tsq

after typing C-a : cjkwidth on <RET>

If I then typed C-a : cjkwidth off <RET>

and ran the reseq command again, it displays much better.

(note to others reproducing: the screen size needs to be 141x43 (or thereabouts?) in order to contain the window being drawn by nmon in "reseq --replay nmon.tsq").

(for Amadeusz:) I don't understand the reasoning behind the conditional setting of cjkwidth. I see in the commit mentioned in https://savannah.gnu.org/bugs/?42198 that cjkwidth is set to "on" automatically if the locale matches a prefix of wide-character languages like "zh_", "ko_" or "ja_", but I don't quite comprehend why that is. The locale itself doesn't normally really dictate whether the outer terminal is going to interpret ambiguous chars as half- or full-width I think - isn't that more of a terminal property? (too bad you can't find it from terminfo/termcap...)

I see that the list of "ambiguous characters" includes a number from latin1, such as the spanish inverted exclamation and question marks. I suspect that few terms actually render these as fullwidth, though I'm assuming you or someone else came across at least one such case in order to add the "cjkwidth" feature (if not for latin1 punctuation, then for other characters in that list).

I'm thinking it might have been better to leave it as unconditional "off" by default unless explicitly asked-for, since making its default value conditional on locale has obviously led to confusion here and in https://savannah.gnu.org/bugs/?42198... just my 2¢.

Micah Cowan <micahcowan>
Tue 27 Oct 2015 04:18:40 PM UTC, comment #15: 

Now that I think about it, you may have hit
https://savannah.gnu.org/bugs/?42198
try adding "cjkwidth off" to your ~/.screenrc and it will probably work again.

Amadeusz Sławiński <amade>
Group administrator
Tue 27 Oct 2015 02:45:51 AM UTC, comment #14: 

Micah,

I am sorry mabe I did something wrong with step.
I just do it again and I am sure I don't run it in a screen.
Pls check the output again.

I use yakuake and I think this is Xterm with color.

# env|grep TERM
TERM=xterm

thank you

(file #35313, file #35314)

Joe Chen <scsichen>
Tue 27 Oct 2015 02:42:22 AM UTC, comment #13: 

Of course, the markup in Savannah broke that line. It's all there, but it's not all displayed. Here it is again without verbatim-mode, just make sure it matches on your terminal before running, and that it's a single line:

script -tscreen.timings -c 'infocmp; screen script -tnmon.timings -c "infocmp; nmon" nmon.scr' screen.scr

Micah Cowan <micahcowan>
Tue 27 Oct 2015 02:38:42 AM UTC, comment #12: 

Actually, something's wrong with the files you uploaded, so the diagnosis may be incorrect.

It doesn't appear you ran the command I recommended, as if you had, screen.tsq would have been full of all the sequences screen sent when it was trying to communicate with the host terminal. As it is, screen.tsq seems to contain only the output from "infocmp", and the outer typescript session exits in under a second. So it doesn't correspond to the command running nmon under it.

Please copy/paste the line exactly as shown:


script -tscreen.timings -c 'infocmp; screen script -tnmon.timings -c "infocmp; nmon" nmon.scr' screen.scr


In case the email is changing something, please be sure to copy/paste it from the web view of your bug, not from the email. It should be a single line.

Then run the two other commands to produce nmon.tsq and screen.tsq and upload them (please delete your original nmon.tsq and screen.tsq before running, so we can be sure we're looking at matching files). Thanks!

Micah Cowan <micahcowan>
Tue 27 Oct 2015 02:34:25 AM UTC, comment #11: 

Amadeusz,

my env infomation is below:

outside screen:
   TERM=xterm

inside screen:
TERM=screen
TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\


USE="-libproxy -sdl -doc -oss -fam -qt3 -hal -libav gles2 ffmpeg bidi gbm uxa gudev xattr xmp sqlite python3 rpc opus gcj objc++ objc-gc multiuser g3dvl acpi hwdb dbus qt3support gtk3 64bit fontconfig script esd asf mp4 lcms kde immqt-bc kde4 glitz xcb composite xcomposite htmlhandbook real flac aac vidix mp3tunes mp4 qt4 accessibility X gtk alsa opengl xv ogg encode xmms mp3 quicktime mpeg nptl nptlonly apache2 f77 objc chroot java tcltk cjk acl threads dvd aalib tiff cscope alsa live ggi directfb fbcon zh_TW divx4linux imap mbox nntp disablekernelsupport network nvidia extensions Xaw3d unicode lufsusermount jikes mozdevelop mozcalendar jpeg2k dri glx truetype-fonts type1-fonts xvid real dvdr xprint bootsplash xttmgr cwttf-baseline vchroot overthespot lm_sensors logitech-mouse rdesktop firefox psyco win32codecs mplayer css musepack musicbrainz sndfile vcd nsplugin xinerama bash-completion cdr samba bzip2 imagemagick chewing gtk-im divx gmedia realmedia wmp xml jpeg lcms mng png smp svg wmf gif truetype xine gstreamer visualization cairo a52 dv dvdread extrafilters amrnb amrwb fame lzo mjpeg theora v4l2 vorbis pdf cleartype emovix sound mysql curl webkit sqlite srt glib ieee1394 x264 openexr plasma vdpau sql rss fts3 opencore-amr secure-delete extras gdu device-mapper policykit charconv icu video gd xulrunner icc python perl cups vnc lxde upcall winbind ads dconf btrfs semantic-desktop networkmanager xvmc fictx vim-syntax

Joe Chen <scsichen>
Tue 27 Oct 2015 02:31:03 AM UTC, comment #10: 

Amadeusz,

You seems like findout the key point. When I use Linux console(ctrl + alt + [number]). nmon work fine in screen 4.3.1. But I used to use yakuake in kde 4 and It has the display problem. When I use PuTTY-0.62 in windows to connect my linux and It has display problem too. When use screen 4.0.3, yakuake and putty all work find.

thnak you.

Joe Chen <scsichen>
Tue 27 Oct 2015 02:15:05 AM UTC, comment #9: 

For the record, I ran:

  reseq nmon.tsq -

inside of screen, and it displayed correctly for me, which definitely proves no problem with nmon's environment - it is sending the correct sequences for running inside of screen. The problem lies in the communication between screen and its environment (in this case, apparently because it's being lied to about what term it's running in).

Micah Cowan <micahcowan>
Tue 27 Oct 2015 02:09:24 AM UTC, comment #8: 

Hi Joe,

According to the files you attached, it looks like you have TERM=screen set outside of screen. Are you running a screen within screen? If so, please provide more details about the exact setup you're running, and also try running the inner screen directly instead of inside screen.

If you're not running screen within screen, then it is inappropriate to set TERM=screen, and that completely explains why it's not drawing correctly for you. Please set TERM to a value appropriate for your outside terminal before running screen (what is your outside terminal, by the way?). "xterm" or "xterm-color" are common (but unless you're actually running XTerm, there are probably much better, more specific/accurate choices).

Micah Cowan <micahcowan>
Tue 27 Oct 2015 01:50:54 AM UTC, comment #7: 

Micah,

I use screen from many year ago. Last version of screen is 4.0.3 and it work fine.

It is strange that is only happen to some applaction who use ascii to draw screen.

I just try iftop and it has the same problem.

Joe Chen <scsichen>
Tue 27 Oct 2015 01:41:27 AM UTC, comment #6: 

Micah,

Sorry for lazy reply. Gmail send this maillist to spam box and I just find out it.

attach the file you want.

thank you.

(file #35311, file #35312)

Joe Chen <scsichen>
Mon 26 Oct 2015 09:01:33 AM UTC, comment #5: 

Hello,
It looks like a Gentoo problem.
I use openSUSE 13.1 x86_64 and I can't reproduce it (alsamixer works fine).

Can you try to install git version manually and reproduce this bug again?

Cheers,
Alex

Alexander Naumov <anaumov>
Group administrator
Thu 22 Oct 2015 04:24:00 PM UTC, comment #4: 

Yeah, I suspect failed upgrade or some unstable packages, I use gentoo and it works fine here.

But still to be sure, can you also provide:
Output of 'env | grep TERM' command, outside and inside of screen.
What USE/CFLAGS do you have (make.conf)?
What terminal emulator do you use?
Have you tried with empty config?
Have you tried downgrading/rebuilding?


Amadeusz Sławiński <amade>
Group administrator
Thu 22 Oct 2015 04:19:13 PM UTC, comment #3: 

Note: tried to reproduce on a Ubuntu VM with both bleeding-edge screen and v4.3.1 from git, but failed. Outside TERM was xterm-256color, inside TERM was screen (and also tried with screen-256color).

Micah Cowan <micahcowan>
Thu 22 Oct 2015 03:57:19 PM UTC, comment #2: 

Oh yeah, also: you say this happened when you updated screen. What version were you using before, and does it work with that? If you can also run those same series of commands for the previous version of screen, that might also help.

Micah Cowan <micahcowan>
Thu 22 Oct 2015 03:54:32 PM UTC, comment #1: 

(I'm not currently a developer, but am trying to gather more information about the problem so if one comes along they have what they need.)

Can you install the "teseq" package, and then run the following commands:

$ script -tscreen.timings -c 'infocmp; screen script -tnmon.timings -c "infocmp; nmon" nmon.scr' screen.scr
$ teseq -D -t nmon.timings nmon.scr nmon.tsq
$ teseq -D -t screen.timings screen.scr screen.tsq

And then attach the nmon.tsq and screen.tsq files to this report?

(When nmon runs, put it into whatever mode demonstrates the graphical problems, let it run for a few seconds, and then quit.)

Developers: if you have the "teseq" package installed for your system (available for most), you can translate the .tsq files back into the original typescript/timing files with the "reseq" command; I mostly recommended the translation with teseq because (a) it avoids missing control characters that sometimes happen when people try to attach raw tyepscripts, (b) it's easier than a typescript to read/evaluate for problems, (c) I wrote teseq when I was a screen maintainer, to help me debug problems with screen, so I use it when I have the chance :)

Thanks!

Micah Cowan <micahcowan>
Thu 22 Oct 2015 11:42:34 AM UTC, original submission:  

I use gentoo linux, when I update screen 4.3.1 broken nmon's display and alsamixer.

Joe Chen <scsichen>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #35313:  nmon.tsq added by scsichen (159KiB - application/octet-stream - teseq output file again)
file #35314:  screen.tsq added by scsichen (178KiB - application/octet-stream - teseq output file again)
file #35311:  nmon.tsq added by scsichen (110KiB - application/octet-stream - teseq output file)
file #35312:  screen.tsq added by scsichen (3KiB - application/octet-stream - teseq output file)
file #35259:  nmon_without_screen.png added by scsichen (126KiB - image/png - screenshot for nmon and alsamixer display problem in screen )
file #35260:  nmon_with_screen.png added by scsichen (84KiB - image/png - screenshot for nmon and alsamixer display problem in screen )
file #35261:  alsamixer_without_screen.png added by scsichen (98KiB - image/png - screenshot for nmon and alsamixer display problem in screen )
file #35262:  alsamixer_with_screen.png added by scsichen (54KiB - image/png - screenshot for nmon and alsamixer display problem in screen )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by anaumov (Posted a comment)
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by micahcowan (Posted a comment)
  • -email is unavailable- added by micahcowan
  • -email is unavailable- added by scsichen (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-16 anaumov Open/ClosedOpen Closed
    2015-10-27 scsichen Attached File- Added nmon.tsq, #35313
        Attached File- Added screen.tsq, #35314
    2015-10-27 scsichen Attached File- Added nmon.tsq, #35311
        Attached File- Added screen.tsq, #35312
    2015-10-22 micahcowan Carbon-Copy- Added -email is unavailable-
    2015-10-22 scsichen Attached File- Added nmon_without_screen.png, #35259
        Attached File- Added nmon_with_screen.png, #35260
        Attached File- Added alsamixer_without_screen.png, #35261
        Attached File- Added alsamixer_with_screen.png, #35262

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code