In src/bsd_KbdMap.c, the function KbdGetMapping is called to setup an appropriate keyboard map. At line 1260 the function calls ioctl(pInfo->fd, GIO_KEYMAP, &keymap) to get the current OS keyboard mapping, then loops accessing the table eascii_to_x|] to map keyboard delivered chars to X KeySyms. 1. this table is built from the cp437 definition, which is only a special case, not taking into account the many character codes being in real use. 2. the code assumes that the character values delivered by the FreeBSD keyboard driver are only 1 byte wide, which may not be the case using syscons with option TEKEN_UTF8 or using newcons/vt(4). A consequence is that out of bounds accesses are done to the eascii_to_x[] table returning at best meaningless results, or at worst (every time on my amd64 systems) leadind to segmentation faults. As this mapping operation seems to be rather useless, I use a workaround which is to #ifdef this part of the code, using the attached patch. I hope that someone more knowledgeable than me can validate/refine this hack.
*** Bug 191458 has been marked as a duplicate of this bug. ***
Created attachment 144431 [details] Adding the proposed patch Add the patch proposed by the original submitter.
The attached patch partially fixes Bug 191632. (See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191632> ) With this patch, X is launched, but other errors occur: - messages about "sysmouse: unknown ioctl" are still there; - the keyboard is unusable (random strings are sent); - the following messages are displayed on the console: failed to set mtrr: Invalid argument The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Compat map for group 2 redefined > Using new definition > Warning: Compat map for group 3 redefined > Using new definition > Warning: Compat map for group 4 redefined > Using new definition Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server - security/openssh-askpass is unusable: kwin(23929)/kwin (client errors) KWin::Client::verifyTransientFor: Client 'ID: 50331657 ;WMCLASS: "sshaskpass" : "ssh-askpass" ;Caption: "OpenSSH Authentication Passphrase Request" ' has WM_TRANSIENT_FOR poiting to itself. - hald reports in /var/log/Xorg.0.log: [1121593.779] (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD, id 7) [1121593.853] (II) config/hal: Adding input device USB Optical Mouse [1121593.853] (II) AutoAddDevices is off - not adding device. [1121593.853] (EE) config/hal: NewInputDeviceRequest failed (8) [1121593.856] (II) config/hal: Adding input device AT Keyboard [1121593.856] (II) AutoAddDevices is off - not adding device. [1121593.856] (EE) config/hal: NewInputDeviceRequest failed (8)
Since Xorg doing own key processing, I think we have to add switch to keyboard RAW mode into Xorg's keyboard driver. P.S. Looks like I have to revise keyboard mode save/restore for vt(4) :)
> Since Xorg doing own key processing, I think we have to add switch to keyboard RAW mode into Xorg's keyboard driver. I've already done that while fixing hotplug issues with devd patch.
A commit references this bug: Author: kwm Date: Tue Sep 9 08:20:38 UTC 2014 New revision: 367714 URL: http://svnweb.freebsd.org/changeset/ports/367714 Log: Don't query console keymap This seems to be useless and doesn't work anymore with vt(4), due to the use of Unicode codepoints in vt(4). The new patch remove the related code. This fixes a segmentation fault during X.Org server startup. PR: 191459 Submitted by: Claude Buisson <clbuisson@orange.fr> (earlier version) Obtained from: xorg-dev Changes: head/x11-drivers/xf86-input-keyboard/Makefile head/x11-drivers/xf86-input-keyboard/files/patch-src__bsd_KbdMap.c
A modified patch was committed in r367714 in the ports tree. Thank you!
*** Bug 193192 has been marked as a duplicate of this bug. ***