Re: my draft
Hello all of you,
I haven't followed all these keyboard-related threads very closely,
by, as maitainer of `console-tools' (soon in hamm, now in Incoming on
sunsite, and from my WWW page), which is derived from `kbd', and which
I hope to supercede the latter at some time, I'd like to raise some
point, and comment on Marco's draft, which I found to be the latest
such document (is it ?)
One thing I found while studying `kbd' and the kernel-driver, is that
many things are now inconsistent or incomplete, and would need fixing.
Among these, most of the unicode-related stuff.
As an example, we can now specify either 8-bit codes, UCS2 codes, or
symbols in a keymap:
* Symbols are linked to 8-bit codes, and thus charset dependant.
* UCS2 codes are output as UTF8 sequences whatever the mode
(XLATE/UNICODE) of the keyboard.
* Codes sent to the application by the keyboard have nothing to do
with codes expected from the application by the screen.
IMHO:
* symbols should be defined in terms of UCS2 codes (that's
loadkeys/dumpkeys problem)
* the driver should, according to the characters expected by the app
(what I call ACM for "Application Charset Map", which is refered
elsewhere as "Screen Map" or "Console Map"), and according to the
console mode (unicode/8bit), output either the UTF8 sequences as now,
or the corresponding 8-bit chars as understood by the app.
This would allow to have one only keymap for people which would use many
languages on the same keyboard, while preventing invalid (according to
current ACM) characters to be passed to the app.
[maybe we should even allow different ACM's for input and output, but
that should not be the default]
With these considerations in mind, and as long as the tools and kernel
are upgraded to allow that:
Marco d'Itri writes:
> <START>
> Debian Uniformed Keyboard Mapping Specifications
>
> - UNIFORM DEFINITION OF COMPOSE SEQUENCES
> - every charset will have his specific compose table
I'd better advise for a generic compose database, based on unicode
(needs work on kernel), of which we would extract the parts relevant
for the requested charsets to send them to the kernel.
> - the national KBD map must suggest a compose table and should suggest
> compatible fonts
Some national keyboards (eg. the french one) are designed with dead
keys. These need specific compose-defs to work; they should IMHO be
part of the keyboard def, even if the global compose-database
redefines them.
> - every compose table must begin with a "charset" entry
Would be obsoleted by UCS2 compose tables
> - CONFIGURABLE SUPPORT FOR DEAD ACCENTS
> - dead accents must be mapped to compose + accent key and/or to SUPER or
> HYPER + accent key (???)
The standard dead accents (acute,grave,diaeresis,circumflex) already
have their symbols, and the kernel handles them as compose+accent. I
think there's no need to change this *kernel* mechanism, except for
adding missing dead accents (only the latin1 accents can be dead;
there is some support in loadkeys for others by using synonyms, but I
don't like that)
> - national maps should support an "all accents are dead" option
That won't probably be meaningful (or useful) on every keyboards. For
example, the french keyboard do have a key for the ^ character, and
another is for the dead-circumflex. This option should at least not
turn the former into a synonym for the latter.
> - NO FIXED MAPPING BETWEEN MODIFIER KEYS AND BUCKY BITS
> - every bucky bit must be mappable to any key
Hmm... I'm not sure to understand "bucky". None of my dictionnaries
know it :(
...but they surely be ;)
> - hardware maps must provide configurable support for sticky modifiers
> - every hardware map must support some predefined modifier arrangements
> (eg: "no caps", "swap caps and ctrl", etc) to be defined
What do you mean by "hardware map" ? OK if you replace it with
"keymap", though.
> - M-(key or sequence) must be produced by control + (key or sequence)
^^^^^^^
Surely you meant "Alt" or "leftAlt"
> - C-(key or sequence) must be produced by control + (key or sequence)
This seems to confirm the latter comment.
> - S-M-sequence is different from M-sequence if the character exists, else
> is equal
> - if it has no special meaning S-sequence is equal to sequence
> - S-C-sequence is equal to C-sequence
Why this difference of treatment ?
> - TOP + numeric keypad keys compose a character (decimal)
> - TOP + numbers and [abcdef] keys compose a character (hexadecimal)
Good idea. However:
- (already mentionned) ALT would be more standard [see you own comment
about M$-DOG compatibility by default]
- an alternative, provided by eg. the "lt" keyboard,
uses another modifier, and the NumLock///*/-/+/ENTER chars for
A/B/C/D/E/F. Maybe not intuitive, but maybe better for people needing
to enter a lot of hex sequences (keymap designers ?)
> - left and right shifts are the same key
> - left and right controls are the same key
> - modifiers are:
> - shift (Shift) [any shift, fixed]
> - control (Control) [any control, fixed]
Why preventing people to use Left/Right modifiers ?
> - hyper (CtrlR)
> - super (CtrlL)
> - front (ShiftR)
I didn't read anything about those equivalences ?
> - optional special mappings (eg: greek letters for a non greek kbd or
> symbols) for HYPER or SUPER can be loaded by the user
The real modifier should be a parameter to these maps, shouldn't it ?
> - HAVE MOST POSSIBLE GENERAL MAPS
> - If more than one character encoding is widely used there should be
> separate maps or a config option or a way to switch encoding using the
> mode switch key
This wouldn't be necessary with UCS2-driven keyboard.
> IMPLEMENTATION
> The master file (/etc/kbd/config.m4) generated by kbdconfig(8) contains
^^^
Why should kbdconfig output a m4 file ?
> definitions for config option values and includes:
> - the macros
> - local kbd map
> - hardware map
> - (opt) compose definitions
> - (opt) special mappings
> - (opt) local definitions (/etc/kbd/local.m4)
> The /etc/kbd/default map file will be generated at config time with the macro
> processor.
See above.
--
Yann Dirson <ydirson@a2points.com> | Stop making M$-Bill richer & richer,
alt-email: <dirson@univ-mlv.fr> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 |
-----------------------------------------
A computer engineer's looking for a job !
-----------------------------------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-i18n-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: