uoaerg/wavemon

History graph displayed improperly!

Closed this issue · 25 comments

History graph is not displayed correctly - https://i.imgur.com/rDnPX6O.png
In /etc/environment I have FONT=UbuntuMono-R-8x16
When I remove this line and reboot everything works fine.
Setting monospace font in XFCE has no effect -- I usually use hack nerd regular, but for this experiment i set regular monospace..

System in arch. Package is from AUR, also tried installing from git clone, same thing. All deps resolved.

Note, key legend character is displayed properly. https://i.imgur.com/X7x59tG.png

Perhaps need to make it so that there are keys in .wavemonrc for the legend?

What is the version of wavemon, and can you paste the output of locale?

wavemon -h >> wavemon 0.9.3

locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Thank you, I will look into a fix using wide-character support, similar to ui.c.

Thanks.
I was looking through code for part where it initializes the chars used in history graph, couldn't find it.
In what file is that code?
Thinking of modifying the chars used something like

char A='-'

Look for #ifdef HAVE_LIBNCURSESW in ui.c:

  • it uses cchar_t * for wide characters instead,
  • as well as "wch" type of functions (mvwadd_wch) that add wide characters to the screen,
  • in particular, it uses the WACS_xxx ACS symbols (e.g. WACS_LTEE).

The non-wide characters in lhist_screen.c are using chtype (1 byte) and are likely the cause of the problem.
The solution is to find wide-character replacements (likely all in hist_plot()) and use these instead.

I just added a potential fix in 4b775eb - could you give this a try, please?

I get no histogram on F2 screen, and wireless scanning immediately stops.

@SCCOBN - can you please check if the above (in master) fixes the problem you reported.

@rogerxxxx - please limit your contributions to what is helpful to others. Within the past week, you have created 7 issues and cross-posted on 2 existing issues, including this one. This is exceeding the limit of what I am prepared to support. I can't spend the time daily to find the section in the manpage that explains how to configure the histogram boundaries. Thank you for your understanding.

grrtrr, for your reference, I'm not trying to create a bias with bugs/issues I've posted, just bringing to light workarounds for a current issue/bug. And, I'm not posting issues/bugs, requiring you to work for free, it's against my repor. On the flip, I understand some developers get extremely sensitive with mentioning bugs within other bug filings, creating a hassle or fiascle when trying to investigate prior bugs. (Personally, I have no problems with handling extra data/information.) If this is the case, a more constructive action would have been a quick private Email stating just the last sentence. Shrugs.. If I'm wrong, then I'll peacefully quickly refrain from further submissions.

Hey, you also stated, "there's a cross-post on this bug." I do not see how my post on this bug could have been misconstrued as cross-posting. Unless this bug his bug is for the "History graph displayed" does not pertain to the "F2 histogram", however my knowledge of Latin seems to indicate a histogram is basically a diagram/graph of a history of points. (~30-45 min rx)

@rogerxxxx - thank you, please use #99 if that is still a problem.

This issue is about wide character support. I would like @SCCOBN to test this, since

  • I do not have a system with fonts in the ру́сский алфави́т and have difficulties emulating this,
  • @SCCOBN has one of the rare cards that still report the noise value (my cards don't).

So it would be really helpful to see if the updates to master fixed this problem.
Previous fixes were for the Chinese Alphabet (#85, which was a screen issue).

So help is appreciated for testing this wide-character issue.

I just added a potential fix in 4b775eb - could you give this a try, please?

Just tried it, it did not work - https://i.imgur.com/WfCDYvu.png

Thank you. The fix required libncursesw, can you please check if it is actually used by sharing the output of:

grep HAVE_LIBNCURSESW Makefile   # this is =1 if configure found the support libraries
ldd ./wavemon                    # shows which dynamic libraries it uses

On my system I have -DHAVE_LIBNCURSESW=1 and

> ldd ./wavemon
	linux-vdso.so.1 (0x00007ffd42b93000)
	libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007fa478194000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fa477f6a000)
...

If that still does not work, there is a trick for these ACS (=alternative character set) characters:

> export NCURSES_NO_UTF8_ACS=1
> ./wavemon

Here is the output of both - https://i.imgur.com/psmfYgP.png
-DHAVE_LIBNCURSESW=1
ldd is libncursesw.so.6

History graph is still messed up

Exporting NCURSES_NO_UTF8_ACS=1 and then running wavemon had no effect..

Good, thank you. The next 2 things to try are:

  1. I will add a commit to remove the SNR and noise level graphs, it may be that these mess up the display. The noise level reported by the card is often just a constant (e.g. 95 dBM), so that additional graphs are not really useful.
  2. If that still does not work, I will simplify hist_plot to only use 1 character (and ignore the fancy characters used for fractions).

Can you please give the next commit a try?

@SCCOBN - when you have time, can you please give 178cceb (right on master) a spin?

If that still does not work, I will change the characters using in creating the graph.

Sorry for delay. I'll be checking this thread daily now. No it did not work, BUT.. Did I do it right? I clone the master repo and just configured and make the wavemon and then ran it from within the folder ./wavemon

https://i.imgur.com/AefyJq2.png

Thank you for all the help and yes you did this right. It seems the special characters used for the fractions (0.2, 0.4, 0.6, 0.8) do not work. I will be removing them in the next commit.

@SCCOBN - when you have time, could you give 69bc63e a try?

Depending on how this works out, I could bring the old graphs (blue / red) back, or leave them out for simplicity.

@grrtrr it appears to be working, checking out screenshot - https://i.imgur.com/rIO66MH.png

Interestingly enough, in ./configure it shows ncurses is not used, even though I have it installed. I don't know.

https://paste.ubuntu.com/p/2Z55b65Zpv/

Here yay shows it is installed https://i.imgur.com/Bxw3M3O.png

Hi, thanks for testing - this has helped to resolve the issue.

As for ncurses - could you share the output where it says that ncurses is not used?
The end result is always visible in the Makefile:
image

Thanks, so what does it say in the configure output - is it because you don't have ncursesw/curses.h?
It likely is one of the following:?

configure:3652: checking ncursesw/curses.h usability
configure:3652: checking ncursesw/curses.h presence
configure:3652: checking for ncursesw/curses.h

'
checking for pthread.h... yes
checking ncursesw/curses.h usability... no
checking ncursesw/curses.h presence... no
checking for ncursesw/curses.h... no
checking for sys/socket.h... yes
checking for linux/if.h... yes
'

But then

'
locate curses.h
/home/alex/.cache/yay/gcc8/src/gcc-8.4.0/fixincludes/tests/base/curses.h
/usr/include/curses.h
/usr/include/ncurses.h
/usr/include/slcurses.h
/usr/include/python2.7/py_curses.h
/usr/include/python3.9/py_curses.h
'

This is what I'm talking about.

The ncurses.h header can be in multiple places, depending on your Linux distribution.
This had been added as a fix in #79, where ncurses.h was installed as ncursesw/ncurses.h.

This is how it looks on my system:

>./configure | grep ncurses
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking ncursesw/curses.h usability... yes
checking ncursesw/curses.h presence... yes
checking for ncursesw/curses.h... yes

There is a bit of redundancy here, will look into nesting the calls.

Yes, all works! Thank you for your help.. This issue can be closed.

./configure | grep ncurses
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking ncursesw/curses.h usability... no
checking ncursesw/curses.h presence... no
checking for ncursesw/curses.h... no
checking for addnwstr in -lncursesw6... no
checking for addnwstr in -lncursesw... yes