On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote: > On Thu, 3 Jul 2014 08:31:45 +0200 (CEST) > Trond Endrestøl <Trond.Endrestol_at_fagskolen.gjovik.no> wrote: > > > On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote: > > > > > On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote: > > > > > > > On 2 July 2014 17:09, Trond Endrestøl > > > > <Trond.Endrestol_at_fagskolen.gjovik.no> wrote: > > > > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote: > > > > > > > > > >> On 2 July 2014 14:51, Trond Endrestøl > > > > >> <Trond.Endrestol_at_fagskolen.gjovik.no> wrote: > > > > >> > Hi, > > > > >> > > > > > >> > Is it just me or is there something wrong with vidcontrol(1) in > > > > >> > base/head, amd64, sc console, r268165? > > > > >> > > > > >> Should be fixed in r268175. > > > > > > > > > > Looks good, thanks. > > > > > > > > Thanks for the report, and sorry for the trouble. > > > > > > No trouble at all, I follow base/head (and stable/{8,9,10}) on various > > > VMs at home only to know what's ahead. ;-) > > > > > > Since neither kbdcontrol(1) nor I mind using the old syscons keymap > > > file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in > > > vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps > > > after searching for them in /usr/share/vt/keymaps? > > > > > > E.g.: > > > > > > Index: usr.sbin/kbdcontrol/kbdcontrol.c > > > =================================================================== > > > --- usr.sbin/kbdcontrol/kbdcontrol.c (revision 268203) > > > +++ usr.sbin/kbdcontrol/kbdcontrol.c (working copy) > > > _at__at_ -804,7 +804,7 _at__at_ > > > char *postfix[] = {blank, dotkbd, NULL}; > > > > > > if (is_vt4()) > > > - prefix[2] = vt_keymap_path; > > > + prefix[1] = vt_keymap_path; > > > cp = getenv("KEYMAP_PATH"); > > > if (cp != NULL) > > > asprintf(&(prefix[0]), "%s/", cp); > > > > Or maybe this patch is even better, as it leaves one instance of blank > > in the array when KEYMAP_PATH is set in the environment, at prefix[1], > > and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not > > set in the environment. > > > > Index: usr.sbin/kbdcontrol/kbdcontrol.c > > =================================================================== > > --- usr.sbin/kbdcontrol/kbdcontrol.c (revision 268203) > > +++ usr.sbin/kbdcontrol/kbdcontrol.c (working copy) > > _at__at_ -800,7 +800,7 _at__at_ > > char *name, *cp; > > char blank[] = "", keymap_path[] = KEYMAP_PATH; > > char vt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd"; > > - char *prefix[] = {blank, blank, keymap_path, NULL}; > > + char *prefix[] = {blank, blank, blank, keymap_path, NULL}; > > char *postfix[] = {blank, dotkbd, NULL}; > > > > if (is_vt4()) > > > > For now I could just stick to using an absolute pathname for keymap= > > in /etc/rc.conf. > > Hi Trond, > > It is not so good idea to fallback to syscons keymaps, because vt(4) > works with Unicode only char codes. So fallback will make input with > non-English characters - unreadable. > > Instead of that fallback you can convert keymaps you can verify by > follow instructions in [1], then please check it and send it to list, > so me or someone else will commit it. > > Thank you for reports! > > 1. > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html I tried to follow the instructions, but I honestly don't see any difference. I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd to cwd, and ran: ./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 > norwegian.utf8.kbd Running diff -u norwegian.* shows absolutely no difference. Is it pilot error on my part? I have attached both files. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC