Re: Switching g-i from DirectFB to X11 -- console-setup
On Saturday 27 February 2010, Anton Zinoviev wrote:
> On Fri, Feb 26, 2010 at 10:22:54AM +0100, Frans Pop wrote:
> > Besides that it offers choices for keymaps that are not even available
This does happen. At least, with only console-setup-pc-ekmap loaded I see
"Sun dead keys" listed for Dutch (hmmm, but no Sun keymaps for USA) and I
also see Macintosh a lot (which is probably necessary).
> > and AFAIK it does not detect headless systems that don't need any
> > console setup.
> AFAIK this doesn't happen.
You're right (tested). It does check if a keyboard is connected, so
headless is covered.
But AFAICT it does not check for a serial console install (not tested ).
kbd-chooser also checks for that and for UML installs. And IIRC the Xen
people also asked at some point to skip keyboard configuration, but I'm
not sure what the status of that is. Call it "unused head installs".
By default kbd-chooser will skip keyboard configuration for serial console
installs, but (at medium/low priority) it will still offer the option to
configure a keyboard.
This can be useful for systems that are installed remotely but should still
have a keyboard/console configured for local maintenance.
For that same reason D-I also has an option to enable VTs even though a
serial console is being used for an install.
> > The extremely long selection lists make console-setup-udeb completely
> > unusable with the text frontend.
> Inconvenient as always with the long selection lists, but not unusable,
I know it's technically usable, but IMO it's effectively unusable.
> see #531646. However, I am not sure which extremely long selection
> lists are you refering to. AFAIK there is only one long selection list
> in c-s-udeb, in the typical situation this question won't be asked and
I like to consider all use cases, not just default installs.
> it is longer than the corresponding selection list of kbd-chooser only
> because some layouts are not supported by kbd-chooser.
IMO it lists quite a few keymaps that can be expected to have such a
incredibly tiny user base that it would be better not to list them at all,
at least not in the udeb.
> > The basic error in the design is the assumption that the same
> > functionality is suitable for both installed systems (where users may
> > want to tune there keyboard for their personal preferences and, most
> > importantly, have the opportunity to try out different options and see
> > their effect) and for the installer (where users only need a basic
> > selection of the correct keymap with solid defaults based on country,
> > language and keymap for everything else).
> There is no such assumption. If the d-i team has enough man-power the
> the udeb can be redesigned to ask entirely different questions.
I never meant to imply that you should do it all. I will probably have a go
at it myself at some point, but it's not high on my ToDo list.
> I think a lot of things changed in console-setup since that thread.
Yes, it does look better than it did. But the choices for "Netherlands" are
still unusable (both "Netherlands" and "Netherlands - Standard" seem to
give the same very uncommon Dutch layout and there seems to be no option
for the most common US layout).
The description for the keyboard origin question still needs improvement.
Here's a proposal (assuming that the goal is that each country _will_ list
all layouts common in that country; if not, the use of "origin" is simply
The layout of keyboards varies per country, with some countries having
multiple common layouts. Please select the country of origin for the
keyboard of this computer.
Country of origin:
We should also consider adding a progress bar while c-s loads all its data.
On my sparc there was a too long delay with nothing but a blue screen
 I tried to but serial console failed with .33 on my sparc with keyboard
connected (i.e. with "head); without keyboard (which makes the firmware
operate in headless mode) strangely enough does work.