[newb] Will xorg still allow non-hal config?

[Nicolas Mailhot]

Le Lun 1 décembre 2008 13:59, Alan Cox a écrit :
>
>> The result is that since there is no single shared layout X and the
>> kernel use, no layout info is exposed by the kernel infrastructure.
>> (and from a functional point of view there is no reason a key should
>> have a different behaviour in X and the console).
>
> So load the correct keyboard tables. The kernel is not and never has
> been
> a keyboard layout manager. That is a policy item, and the fact you may
> want differing behaviour and policy for different systems means it
> needs to stay so.

I didn't write the kernel needed to be a layout manager, just that as
long as the different bits of userspace (console and xorg) couldn't
agree on a common layouting system there would be no chance of the
system exposing a setting xorg could just pick at startup.

(and exposing a setting is very different from having this setting
managed kernel-side)

>> BTW now that almost all the X userspace has been converted to use
>> fontconfig and modern TrueType/OpenType fonts, I expect the level of
>> attention fonts in legacy bitmap format receive to drop sharply,
>> which
>> will ultimately lead to problems kernel console-side.
>
> The bitmap fonts don't change so this sounds like complete garbage.

Just check the console on any random selection of non-us or uk systems
and you'll see the current garbage is the console output. Sure it is
not a blocker because all the different encodings agree on the ASCII
part, but anything outside the 127 first codepoints has a high
probability of being mis-rendered.

> Even
> if you want a new bitmap font from a monospace truetype one the
> complexity of rendering a bitmap font data set is mindnumbing low,
> trivial and automatable.

The problem is not rendering the font data, it's to get the right font
data in the first place. You have not-so-trivial problems like the
limited number of glyphs allowed in console fonts, the fact 4:3 15"
VGA screens are not manufactured anymore, etc

-- 
Nicolas Mailhot