[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode console font
Andries.Brouwer@cwi.nl writes:
> So, I extended the psf format so that for a single glyph
> there may be one or more Unicode sequences describing it.
> You will see the result in kbd-1.0 to be released very soon
Well, that may be a nice feature, but I think the current drivers
cannot make use of them ?
> the events which occurred during the last 2 years
> do not seem to tend towards a unified package...
>
> Hmm. You said something else in your last letter.
> And I wouldnt know why not. But never mind.
Hm... did we have any real mail exchange since I sent you the autoconf
patch ?
> AFAIK kbd still checks for file-types by extension only,
> and not by magic-number, which I consider to be a bug.
>
> Hmm. Let me see..
> mapscrn loads a screen map - no magic is defined
> loadkeys loads a keymap - no magic is defined
> setfont loads a font - it tests the psf magic to see whether it is psf
> Maybe I forget something. Where would you test for magic?
Ah yes, PSF is tested. But it seems CP files are only checked by data
length, which is not a bullet-proof heuristic.
> o Converted all distributed raw fonts to PSF, with SFM when I was sure
> enough I should be right.
>
> Yes, I did the same - with Unicode map everywhere, if I recall correctly,
> will check tonight or tomorrow night. (I just learned this week that
> my Unicode map is your SFM. Somewhat confusing: people tell me that
> it stands for Screen Font Map, which sounds more like screenmap, the
> user-defined mapping table.)
I had problems with those "unicode maps" and "screen maps"
denominations, as explained in lct.sgml, and tried to find better
names. Please note I try to write "screen-font map" with a hyphen
(but maybe I forgot the hyphen sometimes), which may (or may not ?) be
a bit more self-explaining.
> o Fixed unimap-misc.c::kernel_get_unimap() to handle the case where the
> unimap is considered invalid by the kernel.
> Sounds like a console_tools bug only.
> There is no such file, and no such routine in kbd.
This function is directly derived from getunimap.c
> o Fixed `showfont' to restore original UTF/byte mode on exit.
> Sounds like a console_tools bug only.
> Showfont never touches UTF/byte mode.
Ah yes, this is still the old version - you may want to have a look at
showcfont in consoletools, which uses a more simple method.
Also note that "showfont" causes a name conflict: Xfree86 also has
such a command, hence the name change in console-tools (the kbd
showfont program had been installed for some time as shfont in Debian,
when one of my predecessors discovered the conflict).
> o Fixed bug in lib/miscutils::open_a_console(), for when it'll be exported by
> the lib (fd wasn't closed).
> Sounds like a console_tools bug only. Kbd uses
> fd = open_a_console("/dev/console");
> and open_a_console() should certainly not close fd.
The changelog entry may not be clear, but it refers to the following
exception, where error is returned and the fd is kept open with no
reference to it [fd leak, probably not appearing in the kbd utilities,
but still an error]:
if (fd < 0 || ! is_a_console(fd))
return -1;
> o Fixed validity check on "--charset" option in ksyms.c::set_charset(),
> though still don't know what "unicode" is for here.
> Hmm. What was wrong? Current code looks OK to me.
The strcmp() test for "unicode" is reversed, which is always likely to
happen when using "!strcmp()" instead of using "0 == strcmp()", which
would have unveiled the error sooner.
> o setfont.c::saveoldfont() is now robust, and doesn't produce invalid files
> when all data isn't available.
> Hmm. If getfont fails it may produce an empty file, I suppose.
> Sounds harmless. Just like doing "foo >file" which will give
> an empty file if something is wrong with foo.
...except that when I launch a command which should create a file,
usually when there is an error preventing correct operation, I expect
the file not to be here, possibly overwriting a valid previous
version.
IIRC the problem was with failing to get the Unicode map/SFM after
writing the font data, which can cause creating a PSF mode 1 or 3
without the SFM - much worse that just empty file, but don't know if
this is relevant to kbd.
> o Added message in screendump telling when trying ioctl; previously existing
> messages alone were too confusing IMHO.
> Hmm. It is really long ago (1.1.91) that TIOCLINUX was willing to
> dump a console. Instead of printing messages it is no doubt better
> to delete this part entirely.
Well, screendumps perfectly works for me (as root only, though) using
2.2.12. Did I misunderstand your statement ?
> o Made screendump without arguments look at /dev/vcs[a] instead of
> /dev/vcs[a]0, which are not created by MAKEDEV.
> ----------------------------------------------------------------
> Hmm. Depends on your version of MAKEDEV.
Well, this probably refered to the current MAKEDEV at that time. With
current MAKEDEV shipped in Debian, I just did the following:
# cd /dev
# rm vcs*
# ./MAKEDEV console
and get all possible combinations except "vcs" and "vcsa0" (that is
"vcs0" and "vcsa" are here, as well as all numbers 1-63 for both vcs
and vcsa). Seems quite unhomogeneous, isn't it ?
In /etc/devinfo, I see a compatibility "vcs0 -> vcs", but nothing seem
to explain that vcs is not here, although the missing vcsa0 seems
quite normal after reading the file.
Guess there is a bug somewhere. Don't other dists use an
/etc/devinfo-based MAKEDEV too ?
> As you can see, I regard replacing /dev/vcs0 by /dev/vcs a bad
> idea (easier to change a single symbol in devices.txt).
> But now that this confusion has been created, it may be
> reasonable to try opening the other if the first doesnt exist.
> Done.
Anyway, I think having /dev/whatever0 meaning "current whatever", when
all whatever's are already designated as /dev/whatever<n>, is not very
far from brain-damage. I'd say using just /dev/whatever is far less
confusing (doesn't 0 mean "first of the array" in C convention ?)
Regards,
--
Yann Dirson | Why make M$-Bill richer & richer ?
<ydirson@multimania.com> | Support Debian GNU/Linux:
debian-email: <dirson@debian.org> | Cheaper, more Powerful, more Stable !
http://www.multimania.com/ydirson/ | Check <http://www.debian.org/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/