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. OK... > > > > 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 xserver-xorg-video-savage/1:2.3.0-1). 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 way. > > 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 console? -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgp65lwGlTwGW.pgp
Description: PGP signature