Bug #137510 “better console setup” : Bugs : console-tools package : Ubuntu

Revision history for this message

Colin Watson (cjwatson) wrote on 2007-09-06: Re: [Bug 137510] better console setup

#1

Download full text (5.8 KiB)

On Wed, Sep 05, 2007 at 01:19:31PM -0000, Bogdan Butnaru wrote:
> Hello! I'm using Ubuntu Gutsy, and for some times I've been hacking
> around parts of the boot process, and in particular the set-up of the
> text console.
>
> There are a few improvements I've been able to make, and some of them I
> think should be included as default in the Ubuntu packages. I'd like
> however the input of others familiar with the packages (console-tools
> and console-setup) about the changes, and for committing the patches. So
> here are a few ideas:

Thanks for your comments. I'll address them point-by-point.

> (1) redundancy setting console font: as far as I can tell, the
> /etc/init.d/console-setup is setting up the console font quite late in
> the boot process. However, /usr/share/initramfs-tools/scripts/init-
> top/console_setup does (or can do) the same thing much earlier. I think
> only the later part should be used, since it provides the "good" font
> longer during the boot process.

This is done intentionally in order that those people not using an
initramfs still get the console font set up for them; but the font isn't
set by /etc/init.d/console-setup if usplash is running, so in practice a
normal Ubuntu system will only set up the font once.

> (2) redundancy setting keyboard layout: as far as I can tell, at least
> three of the scripts in /etc/init.d handle the keyboard layout. Ideally
> this should be set-up only once, very early in the boot process (ideally
> starting with grub, but init-top is OK too). I administrate my own
> system, and I'm used with dvorak; it's very annoying when something
> breaks and I have to use the layout on the keyboard, which isn't even
> normal qwerty since this is a French laptop. (This is an issue for
> anyone using a non-standard keyboard, like the localized variants, not
> only for dvorak.)

In much the same way as the font, this is only set by
/etc/init.d/keyboard-setup if usplash isn't running, and is normally set
in the initramfs just about as early as possible. What's the third
script you're referring to? If /etc/init.d/console-screen.sh, note that
that does nothing if console-setup is installed.

It is true that there is a certain amount of cruft in the console
initialisation code, though. I'd be interested in patches to simplify
it, though note that some of the complexity *is* there for a good reason
so I might not take all of them. :-)

> (3) a better default font: I'm using the Uni3 console fonts because they
> enable lots of diacritics. (I also happen to think it looks nicer.) I
> know many people don't usually need diacritics (ie, English natives),
> but with Unicode being almost everywhere these days, it's not uncommon
> to encounter filenames with such characters, even if one doesn't use
> them all the time. (Ubuntu does use UTF8 as the default encoding after
> all, right?)
>
> Localized versions would certainly benefit from having a Unicode console
> font enabled by default. AFAIK, no-one would be hurt by defaulting to
> the Uni3 fonts, and people who need more (for Arabic or whatever isn't
> supported by Uni3) can just set-up their systems as before.

We always use Unicode, but the fundamental pr...

On Wed, Sep 05, 2007 at 01:19:31PM -0000, Bogdan Butnaru wrote:
> Hello! I'm using Ubuntu Gutsy, and for some times I've been hacking
> around parts of the boot process, and in particular the set-up of the
> text console.
> 
> There are a few improvements I've been able to make, and some of them I
> think should be included as default in the Ubuntu packages. I'd like
> however the input of others familiar with the packages (console-tools
> and console-setup) about the changes, and for committing the patches. So
> here are a few ideas:

Thanks for your comments. I'll address them point-by-point.

> (1) redundancy setting console font: as far as I can tell, the
> /etc/init.d/console-setup is setting up the console font quite late in
> the boot process. However, /usr/share/initramfs-tools/scripts/init-
> top/console_setup does (or can do) the same thing much earlier. I think
> only the later part should be used, since it provides the "good" font
> longer during the boot process.

This is done intentionally in order that those people not using an
initramfs still get the console font set up for them; but the font isn't
set by /etc/init.d/console-setup if usplash is running, so in practice a
normal Ubuntu system will only set up the font once.

> (2) redundancy setting keyboard layout: as far as I can tell, at least
> three of the scripts in /etc/init.d handle the keyboard layout. Ideally
> this should be set-up only once, very early in the boot process (ideally
> starting with grub, but init-top is OK too). I administrate my own
> system, and I'm used with dvorak; it's very annoying when something
> breaks and I have to use the layout on the keyboard, which isn't even
> normal qwerty since this is a French laptop. (This is an issue for
> anyone using a non-standard keyboard, like the localized variants, not
> only for dvorak.)

In much the same way as the font, this is only set by
/etc/init.d/keyboard-setup if usplash isn't running, and is normally set
in the initramfs just about as early as possible. What's the third
script you're referring to? If /etc/init.d/console-screen.sh, note that
that does nothing if console-setup is installed.

It is true that there is a certain amount of cruft in the console
initialisation code, though. I'd be interested in patches to simplify
it, though note that some of the complexity *is* there for a good reason
so I might not take all of them. :-)

> (3) a better default font: I'm using the Uni3 console fonts because they
> enable lots of diacritics. (I also happen to think it looks nicer.) I
> know many people don't usually need diacritics (ie, English natives),
> but with Unicode being almost everywhere these days, it's not uncommon
> to encounter filenames with such characters, even if one doesn't use
> them all the time. (Ubuntu does use UTF8 as the default encoding after
> all, right?)
> 
> Localized versions would certainly benefit from having a Unicode console
> font enabled by default. AFAIK, no-one would be hurt by defaulting to
> the Uni3 fonts, and people who need more (for Arabic or whatever isn't
> supported by Uni3) can just set-up their systems as before.

We always use Unicode, but the fundamental problem with console fonts is
that any given font only supports 256 or 512 glyphs (depending on the
type of font); this is a kernel limitation. Thus there is no default
that can cover all of Unicode or that makes sense for all languages. For
English and for most Western European languages, we default to Lat15,
which has a reasonable set of diacritics even though they certainly
aren't complete:

À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß à á â
  ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ø ù ú û ü ý þ ÿ Ğ ğ İ ı Œ œ Ş
  ş Š š Ÿ Ž ž

It's worth noting that many languages do have different defaults that
are more appropriate for them.

I take your point that Uni3 is a strict superset of Lat15, though, so it
may be worth changing it. My worry is that the VGA fonts in
console-setup don't entirely cover Uni3, so depending on your font
selection you might get garbage on the screen if you actually tried to
use this.

> (4) a better default layout: related to the previous item, since Unicode
> is more common I've often felt the need to generate accented characters.
> I'm not talking only about my native-language files; sometimes I've had
> to transfer, eg, music files through a ssh connection, and this always
> leads to issues with songs from international artists.
> 
> Even though it won't cover everything (like Japanese), we could set-up
> by default the internationalized version of the US keyboard; it uses
> AltGr to generate some dead-keys; this doesn't annoy anyone who doesn't
> use them (altgr+tilde,a is not a common key combination), and it would
> help a lot some users.

This one I'm afraid I can't do. Occasionally we've set up us(intl) by
accident and it consistently generates lots of complaints from confused
users. The thing that really confuses people about us(intl) is that the
apostrophe becomes a dead key, which US users really aren't used to. At
the moment, X doesn't have a us variant which has the third-level
(AltGr) bindings but not the dead keys.

> I think the console-setup package is intended to use the same keymaps
> with X. It might be worthwhile to get rid of the other kind(s) in the
> default install, to minimize redundancy.

This was indeed the purpose of switching to console-setup, and I believe
we already have got rid of the other kind; console-data hasn't been
installed by default since Edgy. You may still have it on upgraded
systems, though.

> I'd like to also add the possibility to modify or create custom
> layouts, at least by providing a nice man page explaining how things
> work.

Better support for customisation would definitely be a good thing.
There's another bug noting that it's too difficult to do the equivalent
of 'loadkeys us' nowadays, too.

Revision history for this message

Bogdan Butnaru (bogdanb) wrote on 2007-09-06:

#2

Download full text (7.9 KiB)

> > (1) redundancy setting console font: as far as I can tell, the
> > /etc/init.d/console-setup is setting up the console font quite late in
> > the boot process. However, /usr/share/initramfs-tools/scripts/init-
> > top/console_setup does (or can do) the same thing much earlier. [...]
> This is done intentionally in order that those people not using an
> initramfs still get the console font set up for them; but the font isn't
> set by /etc/init.d/console-setup if usplash is running, so in practice a
> normal Ubuntu system will only set up the font once.

I'll have to run a bit more testing (not having a boot log is nasty),
but I think you're right. The trouble is that I don't use usplash (ie,
it's installed but not enabled), and I _think_ the font is set-up
twice, i.e. I see both messages.

I'll check some more, and find some way to "mark" when the font has
already been setup (eg the same trick used with usplash).

> > (2) redundancy setting keyboard layout: as far as I can tell, at least
> > three of the scripts in /etc/init.d handle the keyboard layout. Ideally
> > this should be set-up only once, very early in the boot process (ideally
> > starting with grub, but init-top is OK too).
>
> In much the same way as the font, this is only set by
> /etc/init.d/keyboard-setup if usplash isn't running, and is normally set
> in the initramfs just about as early as possible. What's the third
> script you're referring to? If /etc/init.d/console-screen.sh, note that
> that does nothing if console-setup is installed.

The same issue here, when usplash is disabled I think it's setup
twice. I'll check again tonight, I hope. I saw it's not executed, I'm
not sure if it actually _can_ be executed: the console-setup is a
dependency of ubuntu-minimal.

> It is true that there is a certain amount of cruft in the console
> initialisation code, though. I'd be interested in patches to simplify
> it, though note that some of the complexity *is* there for a good reason
> so I might not take all of them. :-)

OK, we'll take them one at a time :)

> > (3) a better default font: I'm using the Uni3 console fonts because they
> > enable lots of diacritics. (I also happen to think it looks nicer.) I
> > know many people don't usually need diacritics (ie, English natives),
> > but with Unicode being almost everywhere these days, it's not uncommon
> > to encounter filenames with such characters, even if one doesn't use
> > them all the time. (Ubuntu does use UTF8 as the default encoding after
> > all, right?)
> It's worth noting that many languages do have different defaults that
> are more appropriate for them.

Sure, we probably shouldn't mess with individual languages' settings
(except Romanian---it needs Uni3 for some characters that are hard to
find in fonts; but we'll get to that later).

> I take your point that Uni3 is a strict superset of Lat15, though, so it
> may be worth changing it. My worry is that the VGA fonts in
> console-setup don't entirely cover Uni3, so depending on your font
> selection you might get garbage on the screen if you actually tried to
> use this.

Yes, insofar as it's a superset of Lat15 I think it's worth it to use
Uni3. I'm not sure I ...

> > (1) redundancy setting console font: as far as I can tell, the
> > /etc/init.d/console-setup is setting up the console font quite late in
> > the boot process. However, /usr/share/initramfs-tools/scripts/init-
> > top/console_setup does (or can do) the same thing much earlier. [...]
> This is done intentionally in order that those people not using an
> initramfs still get the console font set up for them; but the font isn't
> set by /etc/init.d/console-setup if usplash is running, so in practice a
> normal Ubuntu system will only set up the font once.

I'll have to run a bit more testing (not having a boot log is nasty),
but I think you're right. The trouble is that I don't use usplash (ie,
it's installed but not enabled), and I _think_ the font is set-up
twice, i.e. I see both messages.

I'll check some more, and find some way to "mark" when the font has
already been setup (eg the same trick used with usplash).

> > (2) redundancy setting keyboard layout: as far as I can tell, at least
> > three of the scripts in /etc/init.d handle the keyboard layout. Ideally
> > this should be set-up only once, very early in the boot process (ideally
> > starting with grub, but init-top is OK too).
>
> In much the same way as the font, this is only set by
> /etc/init.d/keyboard-setup if usplash isn't running, and is normally set
> in the initramfs just about as early as possible. What's the third
> script you're referring to? If /etc/init.d/console-screen.sh, note that
> that does nothing if console-setup is installed.

The same issue here, when usplash is disabled I think it's setup
twice. I'll check again tonight, I hope. I saw it's not executed, I'm
not sure if it actually _can_ be executed: the console-setup is a
dependency of ubuntu-minimal.

> It is true that there is a certain amount of cruft in the console
> initialisation code, though. I'd be interested in patches to simplify
> it, though note that some of the complexity *is* there for a good reason
> so I might not take all of them. :-)

OK, we'll take them one at a time :)

> > (3) a better default font: I'm using the Uni3 console fonts because they
> > enable lots of diacritics. (I also happen to think it looks nicer.) I
> > know many people don't usually need diacritics (ie, English natives),
> > but with Unicode being almost everywhere these days, it's not uncommon
> > to encounter filenames with such characters, even if one doesn't use
> > them all the time. (Ubuntu does use UTF8 as the default encoding after
> > all, right?)
> It's worth noting that many languages do have different defaults that
> are more appropriate for them.

Sure, we probably shouldn't mess with individual languages' settings
(except Romanian---it needs Uni3 for some characters that are hard to
find in fonts; but we'll get to that later).

> I take your point that Uni3 is a strict superset of Lat15, though, so it
> may be worth changing it. My worry is that the VGA fonts in
> console-setup don't entirely cover Uni3, so depending on your font
> selection you might get garbage on the screen if you actually tried to
> use this.

Yes, insofar as it's a superset of Lat15 I think it's worth it to use
Uni3. I'm not sure I understand your worry: dpkg-query claims the
package "owns" /usr/share/consolefonts/Uni3*.psf.gz, which I take it
means the entire font. We can check if that contains the entire
repertoire. I'm still not sure why you expect garbage on the screen,
maybe you can expound a bit on that.

> > (4) a better default layout: related to the previous item, since Unicode
> > is more common I've often felt the need to generate accented characters.
> > I'm not talking only about my native-language files; sometimes I've had
> > to transfer, eg, music files through a ssh connection, and this always
> > leads to issues with songs from international artists.
> >
> > Even though it won't cover everything (like Japanese), we could set-up
> > by default the internationalized version of the US keyboard; it uses
> > AltGr to generate some dead-keys; this doesn't annoy anyone who doesn't
> > use them (altgr+tilde,a is not a common key combination), and it would
> > help a lot some users.
>
> This one I'm afraid I can't do. Occasionally we've set up us(intl) by
> accident and it consistently generates lots of complaints from confused
> users. The thing that really confuses people about us(intl) is that the
> apostrophe becomes a dead key, which US users really aren't used to. At
> the moment, X doesn't have a us variant which has the third-level
> (AltGr) bindings but not the dead keys.

I can understand that unexpected dead keys would be annoying. I know
it annoys me.

But I have recently needed to type something in French and I
discovered the Dvorak layout I had been using for the last few months
had all dead-keys on AltGr. Since I didn't even notice them (and they
were easy to use once I learned they existed) I guess we could do the
same for the Qwerty layout without annoying anyone.

I'm ready to create the layout myself if you think we could convince
the X guys to include it, or if we can setup the console-setup package
to add it to X's list. It won't cover every diacritic in the world,
but I think we can support pretty much every Latin-alphabet language
west of Vietnam, ie pretty much everything Uni3 can display.

> > I think the console-setup package is intended to use the same keymaps
> > with X. It might be worthwhile to get rid of the other kind(s) in the
> > default install, to minimize redundancy.
>
> This was indeed the purpose of switching to console-setup, and I believe
> we already have got rid of the other kind; console-data hasn't been
> installed by default since Edgy. You may still have it on upgraded
> systems, though.

Yes, I see I already got rid of console-data. However I still see two
sets of keymaps, one in /usr/share/keymaps (directory owned by
console-tools, not sure who put the files there) and one on
/usr/share/X11/xkb/keymap owned by xkb-data. I'm not sure if they're
independent or not, and I'd still like to either get them in one
place, if it makes sense, or at least update the package's
descriptions to make it obvious what each of them does.

(There are also some keymaps used by vim, vmware, rdesktop and hal on
my computer that I don't care to mess with, and also something from
libsvga1 in /etc/vga that I'm not sure what's needed for. I think most
of these are not relevant for our subject.)

> > I'd like to also add the possibility to modify or create custom
> > layouts, at least by providing a nice man page explaining how things
> > work.
>
> Better support for customisation would definitely be a good thing.
> There's another bug noting that it's too difficult to do the equivalent
> of 'loadkeys us' nowadays, too.

This is also a function of the redundancies above. Even if only one of
them acted at any single time, I'm still not sure why we need three
different packages that _might_ affect the setting-up of the font or
the layout. I was very confused for a while precisely because simple
instructions like "loadkeys dvorak" found on the net behaved
surprisingly and inconsistently depending on the packages installed.

If we can decide on a certain list of packages that handle (1)
console/vtt setup, (2) console fonts and (3) keyboard for both X and
console, ideally at most a single package for each task, I'd be more
than willing to hack on it until it does everything it needs to do.
(eg, something like "loadkeys us", typed in the console or an X
terminal should change the layout used by the console _and_ X, _and_
remember that over reboots. Or at least it should be able to do it if
asked. And it would play nice with the Gnome/KDE settings. I was also
thinking of some kind of "rescue" script or shell function, named
something like "aaaaaaaaaa"---ie something relatively easy to find and
type on an unknown layout---that allows you to temporarily switch to a
known layout if things get messy; there was a program used in an
installer, not sure which distro's, that guessed your layout based on
the keys you pressed, I'll have to look that up.)

Revision history for this message

Dana Goyette (danagoyette) wrote on 2008-03-18:

#3

One thing I've noticed (and appreciated) recently: now both Xorg and console-setup offer a "US International (AltGr Deadkeys)" layout. This allows me to _not_ have dead keys under normal usage, and then merely press right-alt to use deadkeys and ordinary altgr-alphanumeric keys. This might be reasonable as a default.
The only oddity is that the console-setup version doesn't work properly for combinations like altgr-shift-apostrophe, shift-O, for Ö;
The xorg equivalent works fine.

Revision history for this message

Dana Goyette (danagoyette) wrote on 2008-03-18:

#4

(dang, where's the edit function?)
I also forgot to mention: this AltGr Deadkeys layout may be new to Hardy.

Revision history for this message

Bogdan Butnaru (bogdanb) wrote on 2008-03-18:

#5

I think it's been there at least since Gutsy, called intl2 or something like that. I agree it should be the default.

About the console-setup one, what do you mean it doesn't work for some characters? It doesn't do anything, or does it generate weird output? Are you sure your console font/encoding supports those characters?

Revision history for this message

xteejx (xteejx) wrote on 2009-05-30:

#6

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in console-setup (Ubuntu):
status:	New → Incomplete
Changed in console-tools (Ubuntu):
status:	New → Incomplete

Revision history for this message

Bogdan Butnaru (bogdanb) wrote on 2009-05-31:

#7

Hi Teej,

I'm not sure how to proceed. Most of what is discussed above still applies for an up-to-date Jaunty, AFAIK. So, inasmuch as they're considered bugs, this report should be kept open.

But I'm not much affected by them, because I've added all sorts of manual hacks and workarounds to my system quite a while ago. Other than apt insisting to trash part of my config occasionally, I've got things working as I like them. It might be worth to address some of the points above for the benefit of users who don't know how to do it. (Defaulting to a font like Uni3 and a non-annoying international keyboard layout would be the main points.)

Revision history for this message

xteejx (xteejx) wrote on 2009-05-31:

#8

Thanks for reporting back on this. As this is a feature request, I shall Confirm this bug for both packages and mark it as Wishlist. It might be helpful to have a look at maybe creating patches for the fixes you have already done for yourself. There is a wealth of information on how to do this on the wiki at https://wiki.ubuntu.com/UbuntuDevelopment and https://wiki.ubuntu.com/MOTU/GettingStarted - also there is plenty of help on irc.freenode.net in #ubuntu-motu - I think that's the right channel. Good luck! :)

Changed in console-tools (Ubuntu):
importance:	Undecided → Wishlist
status:	Incomplete → Confirmed
Changed in console-setup (Ubuntu):
importance:	Undecided → Wishlist
status:	Incomplete → Confirmed

Affects		Status	Importance	Assigned to	Milestone
	console-setup (Ubuntu)	Confirmed	Wishlist	Unassigned
	console-tools (Ubuntu)	Confirmed	Wishlist	Unassigned

Ubuntu
console-tools package

better console setup

Bug Description

Other bug subscribers

Remote bug watches

Ubuntuconsole-tools package

better console setup

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
console-tools package