console-data-1.02-2

[Eloi Primaux]

With Apple Macbook (pro&non-pro) this package provide the needed console keymap, it could be a good idea to include it on the 6.3 release.

​http://packages.debian.org/unstable/utils/console-data

[Matthew Burgess]

In my opinion, it's far too late in the release process to be adding another package, especially for a fairly uncommon (in LFS-land at least, I would think) platform. I'd prefer this to go in a hint, or even better, get the console-data authors to submit the console keymap to the upstream kernel and/or kbd packages, where we get our current keymaps from. kbd maintenance may still be in limbo - if so, creating a patch to the current kbd package that has the keymap in it along with necessary Makefile changes would be best for LFS, I'd think, rather than a whole new package.

[Eloi Primaux]

i sould read myself twice sometimes... bref That's true, i'ts too late for the 6.3 release also i forget this: it requires the unicode-data package (​http://packages.debian.org/unstable/misc/unicode-data). This package (c-d-1.02-2) provides (with an 's') some essential things such as keymaps and fonts for a quite wide range of platforms not just for the macbook platform.

About the 'uncommon platform', is lfs common ?? ;)

[ken@…]

If we use console-data, we have to throw out kbd. For me, kbd works a lot better than console-data . Specifically, on my own keymap I can add the necessary inclusions to let me key characters by their unicode value (e.g. 161 for 's' with caron), and I can use dead keys (e.g. AltGr+';' for dead_acute) to create the latin1 diacriticals at the console.

Somebody asked me about the files I was including, because they weren't in ubuntu, so I tried to make my version work on debian etch which I currently have on a ppc box. No dice, the extras got garbled to invalid unicode, although entry-by-number worked for straight ascii. That was after I removed the unicode for low-99 quotes because console-data translated it to a sensible symbol name, and then claimed not to recognise it. So, for me kbd is the better package.

But, I assume the keymaps are either public domain, BSD, or GPL (if it isn't obvious, contact the author of the map) - find the corresponding include files (or create them), rename the .kmap to .map, test it, and when it works, give us a patch please. Or just create your own set of overrides to pull in the standard keyboard for your country, and then fix up what is different on the intel mac. That is probably a simpler approach. Consult 'man showkey'.

I don't know what is used to boot linux on intel macs, but I'm fairly sure that it isn't grub. If I'm right, you could write a hint to explain how to boot LFS on intel macs.

[alexander@…]

Please read the copyright file at ​http://packages.debian.org/changelogs/pool/main/c/console-data/console-data_1.02-2/console-data.copyright

After that, decide if we should use Debian or the real upstream + patches.

[alexander@…]

Please ignore the comment above. Debian took over the maintainership.

[Eloi Primaux]

There is an update of kbd which is 1.12.1 but it still in git: ​http://git.altlinux.org/people/legion/packages/kbd.git

[ken@…]

Since kbd is being maintained, and there is a distinct lack of enthusiasm for this fork, I'm closing this. As far as the keyboard layout for mac-books goes, a hint for all the issues (elilo, keyboard, anything else) would definitely be the way to start.