What's with the blue overlining in text consoles? [SOLVED]
On Sun, 14 Jul 2013 11:10:18 -0400 (EDT), commandline@telenet.be wrote:
>
> On 13/07/13 21:55, Stephen Powell wrote:
>>
>> Something strange has started happening recently. For a long time I have
>> used ISO-8859-1 as my character mapping in text consoles.
>>
>> dpkg-reconfigure console-setup
>>
>> and I have had no difficulty, except when using the ssh client to connect
>> to a remote system which uses UTF-8. The box-drawing characters sent by
>> the remote system did not look right under these conditions. To solve this
>> problem, I switched my local system to use UTF-8. Now the box-drawing
>> characters sent by the remote system look right when displayed by my
>> local ssh client. However, I recently began noticing that all blue fields
>> are now overlined. For example, the lynx web browser, when used in a
>> text console (vt1-vt6), displays emphasized fields (the <em>...</em> html
>> tag) as blue overlined, when it used to display them simply as blue.
>>
>> I can live with that, I suppose. But what really bothers me is when I
>> use the c3270 text-mode 3270 terminal emulator to logon to a mainframe.
>> All blue fields are now overlined! This is driving me batty! I tried
>> searching the world wide web using search words of
>>
>> blue overlining "UTF-8"
>>
>> but did not obtain any useful results. Does anyone know the cause of this?
>> Does anyone know the cure? Is this a bug? If so, in what package is the
>> bug? The problem does not seem to occur in a Gnome Terminal window, only
>> on a text console. My system locale is en_US.UTF-8. I am running an
>> up-to-date Jessie system on i386 architecture.
>
> Never heard of something similar to start with. Few guesses.
>
> * Terminal Emulation?
> Check what happens if you switch from say xterm to linux to vt100 to ...
>
> * Character map error?
> Might be for some reason the charmap is damaged? Did you edit them at
> one point? Of would someone else have access to them?
>
> I'd suggest you make a backup of the current files, then proceed with
> tests. If it still fails proceed to reinstall the packages. Then check
> again...
>
> Do you mix the repo with Wheezy or unstable? This might at times cause
> quite unique weirdness.
Thank you for your reply, but please don't top post. I took the liberty of
reformatting this post in the bottom posting / interleaving style.
Well, after a lot of trial-and-error experimentation, I have found the culprit.
It's the video BIOS. This video BIOS supports eleven hardware text modes,
as documented below:
hex mode id screen size character cell
(vga=ask) (text columns x size (horiz pixels
text rows) x vert pixels)
----------------------------------------------------
F00 80x25 9x16
F01 80x50 9x8
F02 80x43 8x8
F03 80x28 9x14
F05 80x30 9x16
F06 80x34 9x14
F07 80x60 9x8
121 100x25 9x16
122 100x30 9x16
123 132x25 8x16
133 132x44 8x8
Of these eleven hardware text video modes, ten of them work fine. That is, blue
fields appear without overlining. One of them is defective. Mode id 0x122,
for 100 text columns by 30 text rows, displays blue fields with overlining.
And that's the one I was using. Coincidentally, I switched from 80x34 to
100x30 shortly after I switched from ISO-8859-1 character mapping to UTF-8
character mapping. The overlining of blue fields had nothing to do with the
switch to UTF-8. It just appeared to be related because the video mode switch
occurred at about the same time. The video BIOS apparently does not set up
the VGA registers correctly for video mode id 0x122. But it does for all the
other text video modes. The solution (actually a circumvention) is to choose
a different video mode. Problem solved. For those of you who are interested,
here is the information I have been able to obtain about my video chipset
and BIOS:
The video chipset is listed by "lspci -nn" as follows:
05:03.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rage XL PCI [1002:4752] (rev 27)
The video chip is built-in to the motherboard; so it's video BIOS is built-in to the
motherboard too.
/var/log/Xorg.0.log shows the following information about the video BIOS:
MACH64(0): Primary V_BIOS segment is: 0xc000
...
MACH64(0): VESA BIOS detected
MACH64(0): VESA VBE Version 2.0
MACH64(0): VESA VBE Total Mem: 8128 kB
MACH64(0): VESA VBE OEM: ATI MACH64
MACH64(0): VESA VBE OEM Software Rev: 1.0
MACH64(0): VESA VBE OEM Vendor: ATI Technologies Inc.
MACH64(0): VESA VBE OEM Product: MACH64GM
MACH64(0): VESA VBE OEM Product Rev: 01.00
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: