# PS/2 keyboard problem after upgrade to 12.2p3 / xorg 7.7.3



## jsika (Feb 22, 2021)

Hello,
please could you help me to resolve my issue with PS/2 keyboard? After upgrade from source, recompiling everything, xterm u/twm shows wrong characters - it seems problem with UTF-8, if so, where to set it up? I include display.conf - the last section I added recently, but no effect.

Or should I disable EVDEV from the kernel and recompile? The strange fact is, that after binary upgrade to 12.1, everything continued working well under KDE. I have Intel deskboard, Core 2 Duo.


----------



## SirDice (Feb 22, 2021)

Start with removing that xorg.conf, you don't need it. Make sure you have x11-drivers/xf86-input-libinput installed. Then look in /var/log/Xorg.0.log.


----------



## jsika (Feb 26, 2021)

Thanks, it worked. I am in TWM, now going to KDE...


----------



## Mjölnir (Feb 26, 2021)

Please write a short follow-up if you succeeded with KDE or not.


----------



## jsika (Mar 7, 2021)

Mjölnir said:


> Please write a short follow-up if you succeeded with KDE or not.


So I'm back - let me share my experience on Intel board w/Core 2 Duo @2.6 GHz.

World: 9 hours, compiles well.
Kernel: 20 minutes, OK.

XORG: various hours.
CDS: compiles fast, still doesn't work, but it wants - maybe some cfg problem.
GNOME: various hours. Works much better than before, however it's heavyweight and not so practical for me. Hangs almost always when I log out back to the console. But now it's usable.
CHROMIUM: more than 1 day I think, finally seems like broken port and did not work yet, will try again later.
FIREFOX: various hours, did not finish, however I tried it again after KDE and it compiles without error. Great, it works!
KDE (5.20.12.2): 2 days! Compiles without problems.

As indicated by SirDice, I had to delete cfg file with display settings to make work the XORG, BTW my desktop had KDE widgets, that seem not to work anymore, so I had to delete all of my local config files. It looks like only ~/.config directory was the problem. When I reinsert "Memory Usage", for example, it hangs, letting you a black screen with mouse cursor only and does not start until you delete or recover previous copy of ~/.config directory. Especially, "Network Usage" widget is missing much.

When run for the first time, "KDE crash handler crashed" welcome message makes you fear, but after restart it does not appear anymore. The good thing is that now, KDE is lightweight, stable and faster, with less error messages when logging out back to the console, but sometimes it hang similarly like Gnome. Sleep mode seems to fail, too.

It now seems to use only one core when compiling ports, but in 12.0 I think it was using both. FreeBSD is detecting correctly the two cores I have. Should I use make -j 2? I read somewhere that I should not.


----------



## Mjölnir (Mar 7, 2021)

If the parallel build fails but a non-parallel succeeds, it's clear that there's either an error in the Makefile rules, or in rare cases the hardware is too weak (too less RAM + swap).

Thus yes, use parallel build with make(1) option `-j $(( N * `sysctl -n hw.ncpu` + 1 ))`, one more than you have CPU cores (incl. virtual; i.e. N=1 for SMT=2, w/o SMT you can give a factor N=2 to the #core).  This will keep your cores busy.  Other formulas are reasonable as well, it depends & varies for the hardware & workload.  In general, there will always be at least one driving thread, therefore the "+ 1".


----------



## jsika (Mar 7, 2021)

Mjölnir said:


> If the parallel build fails but a non-parallel succeeds, it's clear that there's either an error in the Makefile rules, or in rare cases the hardware is too weak (too less RAM + swap).
> 
> Thus yes, use parallel build with make(1) option `-j $(( N * `sysctl -n hw.ncpu` + 1 ))`, one more than you have CPU cores (incl. virtual; i.e. N=1 for SMT=2, w/o SMT you can give a factor N=2 to the #core).  This will keep your cores busy.  Other formulas are reasonable as well, it depends & varies for the hardware & workload.  In general, there will always be at least one driving thread, therefore the "+ 1".


Yes, now I understand. Higher number of cores requires more work for the controlling thread, but it has no sense in case of my double core. So the formula prints correctly -j 3.

With my 2 GiB only and 7.2 GiB swap, it spends no more than a half, when doing nothing else.


----------



## Mjölnir (Mar 7, 2021)

The point is to find a balance between keeping the cores busy and avoiding cache misses that go up with too many threads running in parallel.  Personally, I don't care much if a _buildword_ + a bunch of ports(7) takes 50h or 70h, since I let it run `\nohup nice make ... &` in the background, and I have `sysrc powerd_flags+=" -N"`, thus the build's load doesn't affect my desktop activity too much, and the fan stays quite.  You can additionally allow your user to set idle priority (`sysctl -d security.bsd.unprivileged_idprio`) and let the build run via idprio(1).  Then the system will keep beeing 100% responsive.


----------

