X wrecks my keyboard

[nuB]

When I first installed FreeBSD, 12.1-RELEASE-p3 and X, I set it for Alt-Ctl-BS to zap X, but that didn't work, nor did Alt-Ctl-Fn get me back my other ttyvs with other users logged in or able to, just black screens; but the correct Fn would get me back to my X screen, where I could exit xterm, which would kill X and give me back my consoles, so it was only slightly inconvenient; I lived with it. The I upgraded to p10. Once I left the X screen with Alt-Ctl-Fn (hoping the problem might have been fixed) I couldn't even get it back, and had to reboot without an orderly shutdown; nasty, so I never tried that again, but xterm and other clients still worked and could be exited, so still not a huge problem. But I got a warning that the supported life of 12.1 was nearing its end and I should upgrade soon. So I did, to 12.2-RELEASE. Not knowing about the delayed build policy, I imagined that upgrading everything else to current couldn't hurt and might help, so I did, including X. All still from packages. And the roof caved in.

Once I start X (via startx or xinit), my keyboard goes crazy. The clients don't matter: The first time was the default twm and xterm, but I've tried it with only xterm (one window, upper left), and without xterm (just Firefox), and it's always the same. So I assume the problem must be in the server, the default xorg (via xorg.wrap). All of the other servers in Ports' x-servers look like just elaborations of xorg with extra features, rather than truly independent basic servers, and the one I tried to install failed with the polkit problem discussed below, so I haven't been able to escape xorg.

The mouse works fine, so I can exit via a close button (after doing nothing of value). But keypresses yield gibberish. It's not just that typing A produces B; many unshifted keys produce weird characters that have to be shown as \nnn, the sort that no sane keymap would assign to basic keys. I've run xmodmap and stty (via .xinitrc) and the results look perfectly normal. And typing the same key twice yields different results. It looks as if xorg is trying to manage the keyboard at a very low level and doing it so badly as to get frame or parity errors or something.

I suspect the problem might be that the evdev driver won't install, either as part of X or separately; it shows a message from pw and quits. Because it depends on polkit, which is trying to install a user named polkit, and pw reports that this user is mysteriously disappearing. The same thing happens when I run pw myself and try to create polkit as user #562, which polkit wants. Neither pw nor id can see this user at all. Yet when I look at passwd and master.passwd, the lines are there, looking normal.

I have no idea what is going on or what to do. Help!

 

[SirDice]

When I first installed FreeBSD, 12.1-RELEASE-p3 and X, I set it for Alt-Ctl-BS to zap X, but that didn't work, nor did Alt-Ctl-Fn get me back my other ttyvs with other users logged in or able to, just black screens; but the correct Fn would get me back to my X screen, where I could exit xterm, which would kill X and give me back my consoles, so it was only slightly inconvenient; I lived with it. The I upgraded to p10. Once I left the X screen with Alt-Ctl-Fn (hoping the problem might have been fixed) I couldn't even get it back, and had to reboot without an orderly shutdown; nasty, so I never tried that again, but xterm and other clients still worked and could be exited, so still not a huge problem.

This problem has nothing to do with the FreeBSD version. Ctrl-Alt-Backspace (the zap) has been disabled by default in Xorg for quite some time (at least 10 years ago). The issue with not being able to switch back to the console has to do with KMS and the fact that a lot of graphics drivers are using this nowadays. It works in most cases but certain videocards still appear to be somewhat problematic.

Not knowing about the delayed build policy, I imagined that upgrading everything else to current couldn't hurt and might help

Are you referring to FreeBSD-CURRENT here? -CURRENT is an unsupported development version.

so I did, including X. All still from packages. And the roof caved in.

I suspect you are using graphics/drm-kmod, build graphics/drm-fbsd12.0-kmod from ports. Packages are still being built for 12.1 (because it's still supported) and kernel modules are always somewhat of a problem, this module in particular has to be built specifically for 12.2. Quickest solution is to simply build this one from ports.

 

[nuB]

Thanks for the tips.

The Handbook said the zap was not default but could be set with an Option. So I did that, and I have seen it referred to and apparently ready for use in a number of other relevant-looking files, and nothing anywhere suggesting that it's impossible or rejected or inoperable. Is it in fact completely disabled without regard to what any file says?

The base system is still 12.2-RELEASE. By "current" (referring to other stuff, like X) I meant whatever pkg uses when I don't specify a version.

I'll try building drm-fbsd12.0-kmod from ports, for 12.2. I'm not used to doing that, so it'll take some reading up and puttering. I didn't expect that a graphics component would control the keyboard, an input device (but no effect on the mouse, which seems more graphical).

Unfortunately, with my own machine kaput for graphical use, including most Web stuff (I briefly tried lynx but it didn't seem any more usable), I have to carry on this conversation from a public terminal at the library, which allows only very limited time once a weekday. So this may take a while.

 

[SirDice]

Is it in fact completely disabled without regard to what any file says?

You should still be able to enable it. But it probably fails to switch back to the console for the same reason ctrl-alt-F2 etc. fail, KMS.

The base system is still 12.2-RELEASE. By "current" (referring to other stuff, like X) I meant whatever pkg uses when I don't specify a version.

Good. Just wanted to make sure we're on the same page, "current" has a somewhat different meaning around here

I'll try building drm-fbsd12.0-kmod from ports, for 12.2. I'm not used to doing that, so it'll take some reading up and puttering.

Building ports is surprisingly easy. That's what got me into FreeBSD in the first place.

I didn't expect that a graphics component would control the keyboard, an input device (but no effect on the mouse, which seems more graphical).

Recent changes may be the cause of the keyboard issues. Is x11-drivers/xf86-input-evdev installed?

I suspect the problem might be that the evdev driver won't install, either as part of X or separately; it shows a message from pw and quits.

Would that be something like "User 'somename' disappeared during update"? Run /usr/sbin/pwd_mkdb -p /etc/master.passwd to fix that. Sometimes the password databases get out of sync and you run into the aforementioned error.

 

[nuB]

Yes, it was xf86-input-evdev that wouldn't install, and the message was indeed that the user disappeared. (A number of other packages have had the same problem for the same polkit reason.) I'll try the pwd_mkdb fix.

I looked at the drm branches of the Ports tree. The one you mentioned sounds like it's for fairly modern video hardware. My machine is from the aughts, based on Intel Xeon CPUs, and as I'm not into graphics I wouldn't have splurged on fancy video. I don't remember exactly what I bought but offhand I'm not sure it even includes a separate GPU or separate video memory. It's been a while since I looked through dmesg, but I can't recall ever noticing anything that looked like that (and I do recall seeing lines about the Xeons) -- though I suppose if it's on a card the relevant line might not be so obvious. I'll look more carefully. But my assumption is that my graphics are old and barely adequate, e.g. almost surely no 3D acceleration. And there's no /dev/dri. So I wonder if maybe I really need to go the other way and build the legacy version instead? (Or is that available as a package?)

If so there would be another issue. When the keyboard problem developed I noticed a complaint in X's log that it couldn't install ati because it didn't exist, so (just in case) I installed that, the regular flavor. Now I see in the drm-legacy doc that it should go with ati-legacy. If I install that, do I need to uninstall the other flavor, or is it OK to have both?

Assuming I do need to build something specifically for 12.2, how do I go about telling it that? I looked through the Makefile for drm-fbsd12 and (apart from the opening comments) I see nothing specifying the OS version, beyond that it has to be at least 12.0. Is there some other file I need to edit, to include the right things? Or does it simply know that if I build it _on_ 12.2 it should build _for_ 12.2?

Fwiw, the keyboard itself is an Alesso "compact" kb, with 105 physical regular keys (not counting the additional buttons), but from what I've seen of ordinary (non-X) keymaps I suspect there are pairs of keys, like main Delete and numpad Delete, that produce the same scancode, so logically it may be fewer. Might this be confusing something? Also, it's an old-fashioned keyboard plug, not the USB kind that seems to be what everyone sells nowadays. It works fine without X, so the base OS does understand it.

 

[nuB]

The users-database fix worked, as far as that goes: polkit installed properly, and therefore evdev as a package. But when I try to kldload evdev it fails with the complaints that evdev.1 (which I've never heard of otherwise) is already there and (astonishingly) that evdev.ko is not a supported file type. I also noticed that the regular flavor of drm-kmod wasn't there (maybe it too wanted polkit?) so I installed it and drm.ko did load.

Briefly this did seem to help, though not enough. When I ran startx, the keyboard was still mostly messed up, e.g. I couldn't type exit or anything intelligible. But somehow the ALt-Ctl-BS zap did work, a bit touchy, because the Ctl key by itself was wild, but usually if I hit all three keys together fast enough it would work. I think even Alt-Fn was working. So maybe xorg makes some effort to trap the zap and such specials before passing on other keystrokes to whatever routine is screwing them up? Anyway, when I get back to a console-style ttyv it works, but with the font much smaller than the startup (VGA?) size, presumably because the mode switching didn't switch back. But this at least suggests that a lack of proper mode switching is not what prevents Alt-Fn from working. And that virtual-terminals business is flaky in other ways: When X is zapped and terminates, it switches me to another ttyv, the one numbered next below (which was just running getty); and when I got to a console as root and SIGTERMed all the X processes, I was somehow, silently, switched to the ttyv on which they'd been run.

With easy access to all the messages, I noticed that my video is Radeon, with 128M of video memory; there was even some brief allusion to doing something about a GPU, though no details about it. And I noticed that radeon.kms was loaded. But the messages about Radeon were too numerous for me to check out the particular model.

Thinking maybe it needed the built-for-12.2 kmod after all (I had seen somewhere that the legacy flavor is never needed separately, as it's included in the regular catchall), I tried to make install drm-fbsd12.0-kmod . It reported that compilation failed unexpectedly, and urged me to set something about less-safe efforts and try again. I did, same thing. The summary at the end says there were two errors, but actually there were many particular error messages, all more or less the same (but too numerous and complicated for me to compare carefully); the gravamen was that something was too local, not as widely visible as it should be. Which sounds like a programming mistake, and I don't see how it would tie in with 12.2 especially.

And now the keyboard improvement is gone, and I'm back to nothing works, have to reboot.

X's log shows only one Error and one Warning. The Error concerns AIGLX, some driver problem, but the next two lines are about IGLX and GLX; I know nothing about this, but offhand that looks to me as if it merely had to fall back on some less-advanced version and really it's OK. The Warning is that multiple cards are not supported, again hardly critical sounding. Basically X seems satisfied with itself, reporting a long series of pretty normal stuff and finally that it terminated successfully; no sign that it realizes it's unusable, no sign that it's focused on the keyboard.