> > (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.)