[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X

On Tue, 15 Dec 2009 20:45:35 +0200 Anton Zinoviev wrote:

> On Mon, Dec 14, 2009 at 11:01:38PM +0100, Francesco Poli wrote:
> > I had tried with 'showcfont', but I thought it didn't do what you
> > wanted.  Instead of telling me the name of the used font (as I
> > expected), it wrote a complete table with all the gliphs and codes.
> > 
> > Well, I am not able to be sure the font has not changed, just by
> > looking at this table!
> Yes, if the font is the same you can not be sure that it has not
> changed but sometimes if it has changed you can be sure that it has
> changed. :)
> In your case the font has not changed, so there is no need of more
> tests.


> > > I suppose that only the horizontal lines are broken (the vertical
> > > are OK)?
> > 
> > Bingo!
> > You guessed!
> Then it seems this bug must be reassigned to some of the x server
> video drivers. What is the type of your videocard?

I took a look at the different boxes I administer: I experience this
problem on two machines with Intel integrated graphics (driver
xserver-xorg-video-intel/2:2.9.1-1), but *not* on an old laptop with an
S3 ProSavage KN133 integrated graphics chip (driver

It seems that this issue is intel-graphics-specific.

> Can you attach
> the contents of /var/log/Xorg.0.log

Do you need a log file that was updated during the [Ctrl+Alt+F1] switch?
Or just a simple log file, as it is as soon I open an X session?

> What happens if you don't use Ctrl+Alt+F1 but rather exit X the
> normal way?

I experience the same bug, after closing my Fluxbox session the usual

> In order to work with 9x16 and 9x14 fonts the video card does a
> magic: for some of the symbols (the pseudographic symbols) it uses
> the 8-th bit in each line as 9-th bit.  This magic is due to the fact
> that even the most modern cards are emulating the old VGA hardware
> that was developed 20 years ago when only the 8-bit technologies were
> cheap.  Somehow X leaves the videocard in a mode when it doesn't use
> the 8-th bit as 9-th and leaves the 9-th bit empty.

Hence, it seems that this bug should be fixed in
xserver-xorg-video-intel. If this is the case, I think the bug report
should be reassigned to package xserver-xorg-video-intel, version
2:2.9.1-1 .

> > As far as lat1u-16 is concerned, please note that it has always had
> > this problem (broken horizontal lines): that's why I labeled it as a
> > "compromise solution".
> I suppose this was because of the way this font was loaded.  I think
> if you put FONT='lat1u-08.psf.gz' in /etc/default/console-setup the
> lines will not be broken.

I've just tried with FONT='lat1u-08.psf.gz'
in /etc/default/console-setup, and then with FONT='lat1u-16.psf.gz' .
I see horizontally broken pseudo-graphic symbols with both of them.

> If you start using framebuffer all lines will display correctly but
> the console will use 8x16 and 8x14 fonts instead of 9x16 and 9x14. I
> don't know how the problem you are experiencing can be fixed in the
> regular text mode.

I am quite ignorant about framebuffer consoles (and about framebuffer
in general, for that matter...).
What are the pros and cons of a framebuffer console?
Is it difficult to configure the system so that it uses a framebuffer

 New location for my website! Update your bookmarks!
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

Attachment: pgpbHxohm9q8Y.pgp
Description: PGP signature

Reply to: