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

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 [1]).
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 
incorrect):
=========
   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 
showing...

Cheers,
FJP

[1] 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.


Reply to: