# .xinitrc commands don't last



## free-and-bsd (Jan 29, 2021)

Hello,
I'm seeing a strange behaviour on my 12.2-RELEASE-p1 (last updated today).
I'm using .xinitrc with startx to start my X session. It includes several xset commands, among them this one:

```
setxkbmap -layout 'us,fr(oss),ru' -variant -option \
grp:alt_shift_toggle,terminate:ctrl_alt_bksp,compose:ralt,lv3:menu_switch keypad:pointerkeys &
```
This adds a good layout switch method to my FVWM session, which lasts session long. I mean, normally, in all my installations (I have several). But in this particular installation it only lasts some short time! In some 20 minutes I can't switch keyboard layout anymore, neither can I end session with Ctrl+Alt+Backspace (terminate:ctrl_alt_bksp setting from the setxkbmap command).

Any idea what could be the cause of it?


----------



## chrbr (Jan 29, 2021)

There is something as a time out. I have stumbled over that some weeks ago. Otherwise I would not have been aware about that strange thing. Please see below what I have in my .xinitrc for the setting of the mouse keys not to expire.

```
xkbset m
xkbset exp '='m
```
This is not in xkbset(1) but in the help output you get by `xkbset h`.


----------



## free-and-bsd (Jan 29, 2021)

Thank you! I'll try this.
But my main question here is not only how to prevent it, but also WHY this is happening in one installation, but not in any other .
One difference of this installation against my other ones is that it uses precompiled packages from site. Normally I build my own ones with Synth. I'll give it a try.


----------



## chrbr (Jan 29, 2021)

free-and-bsd said:


> But my main question here is not only how to prevent it, but also WHY this is happening in one installation, but not in any other .


I have no idea. Initially I did not have that entry. There must have been a change somewhere last year. BTW: I am using packages running the RELEASE version of FreeBSD, currently FreeBSD-12.2 RELEASE. May be there are configurations or dependencies in the involved ports which trigger or disable the time out.


----------



## free-and-bsd (Jan 29, 2021)

I don't have this in 13-ALPHA2. Only on 12.2-p1 with pre-built packages.


----------



## olli@ (Jan 29, 2021)

Is this a USB or Bluetooth keyboard? Maybe, for some reason, the connection is interrupted for a very short time (short enough that you don’t notice), causing the device driver to detach and attach it again, causing it to lose its settings. This should be logged in /var/log/messages, so you might want to check that.


----------



## free-and-bsd (Jan 30, 2021)

olli@ said:


> Is this a USB or Bluetooth keyboard? Maybe, for some reason, the connection is interrupted for a very short time (short enough that you don’t notice), causing the device driver to detach and attach it again, causing it to lose its settings. This should be logged in /var/log/messages, so you might want to check that.


A USB keyboard. I'll check the log, thank you, good idea. For comparison, I have another 12.2 installation on the same machine, the only difference is that one was continually upgraded (freebsd-update) from 12.1, I think. So I'll see if this is happening there.


----------



## free-and-bsd (Feb 5, 2021)

Well, it seems related to the new keyboard, after all. Who would think? Because I upgraded now to 13.0-alpha3, but the thing doesn't go away.


----------



## hruodr (Feb 6, 2021)

free-and-bsd said:


> but also WHY this is happening in one installation, but not in any other .


FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.


----------



## hruodr (Feb 6, 2021)

free-and-bsd said:


> A USB keyboard. I'll check the log, thank you, good idea.


And? Did detach?


----------



## free-and-bsd (Feb 6, 2021)

hruodr said:


> And? Did detach?


Yes, kind of. You see the message in dmesg output (I don't monitor it specifically on my desktop) like USB keyboard detached / attached etc. What surprises me is I have seen such messages before. But it never caused the problem described in this discussion.

I upgraded that installation to 13-alpha3 and still have that same thing. But I can swear to it, I NEVER had it on my other 12* installation on the same machine but which was incrementally updated by freebsd-update. Though I can't duplicate this on my main workstation because it uses PS2 type keyboard.


----------



## free-and-bsd (Feb 6, 2021)

hruodr said:


> FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.


Well there must be a cause of it anyway. I suspect a particular USB keyboard model (bought recently, here's the point).


----------



## hruodr (Feb 6, 2021)

free-and-bsd said:


> I NEVER had it on my other 12* installation on the same machine





free-and-bsd said:


> I suspect a particular USB keyboard model (bought recently, here's the point).


Same machine or not same machine?!


----------



## free-and-bsd (Feb 6, 2021)

hruodr said:


> Same machine or not same machine?!





free-and-bsd said:


> I upgraded that installation to 13-alpha3 and still have that same thing. But I can swear to it, I NEVER had it on my other 12* installation on the same machine but which was incrementally updated by freebsd-update. ...


What else can I do to convince you that I'm talking about the SAME machine?


----------



## Snurg (Feb 6, 2021)

hruodr said:


> FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.


Actually I believe this trend isn't that new.

I realized that, to be able to use FreeBSD in office, I will have to maintain a custom kernel with some locked modules for my personal use, as it seems that an old bug in the suspend/resume routines (usage of uninitialized data structures) I reported more than three years ago including fix, apparently still has not been corrected.
Everybody knows that using uninitialized data structures with random content usually does not result in reliably deterministic behaviours.

As this bug is an annoying, but trivial-to-fix showstopper preventing reliable wake-up after sleep on computers with Nvidia cards, I just do not understand that there seems so little interest in fixing it.
Even if FreeBSD focus is on servers, I honestly think that the suspend/resume stuff might deserve a bit more attention, so people do not get an impression of total neglect.

Considering that the implementation of a suspend/resume framework has been paid by a sponsors' generous financial donation, *I honestly do not know what I should think about the continuous inaction regarding fixing a showstopper bug *affecting Nvidia users. *Usage of uninitialized data structures in a kernel module seems no longer to be an issue requiring action.*

(This is not intended as criticism! It is just saying what I do not understand.)


----------



## shkhln (Feb 6, 2021)

Snurg said:


> I realized that, to be able to use FreeBSD in office, I will have to maintain a custom kernel with some locked modules for my personal use, as it seems that an old bug in the suspend/resume routines (usage of uninitialized data structures) I reported more than three years ago including fix, apparently still has not been corrected.
> Everybody knows that using uninitialized data structures with random content usually does not result in reliably deterministic behaviours.
> 
> As this bug is an annoying, but trivial-to-fix showstopper preventing reliable wake-up after sleep on computers with Nvidia cards, I just do not understand that there seems so little interest in fixing it.
> ...


This whole thread reads as a series of mutual misunderstandings, especially on _your_ part.


----------



## Snurg (Feb 6, 2021)

shkhln said:


> This whole thread reads as a series of mutual misunderstandings, especially on _your_ part.


Thank you for the information.
Your information would be more helpful/constructive if you could assist me regarding the question important to me "how can I get suspend/resume work with the standard kernel, without either removing or fixing vesa.ko?".

What do you think I misunderstand, what do I need to do to so that this issue gets solved in the standard kernel, so I no longer need to build a custom kernel, just to make things work as intended? I would thoroughly appreciate any hints.


----------



## shkhln (Feb 6, 2021)

What exactly is not actionable in this message?


----------



## Snurg (Feb 6, 2021)

The PR you linked to is very interesting, it reveals yet another issue of vt 
You need to know, I have tried vt a few years ago for a short time, and went back to sc a few days later due to vt's bugs and its lack of functionality (history buffer size is very small, hard coded, thus not configurable without editing sources). So I am _not_ a vt user.

However I think it is a different issue, as the issue I reported is _not_ in vt, but in vesa.ko (which vt depends on).
On resuming there is a call into VGA BIOS that should not be done on Nvidia cards, because using a non-implemented BIOS function can yield unpredictable results that may depend on things like random memory or register contents, which result in a failed resume process.

A simple check (is nvidia? then skip that unsupported BIOS call) would be sufficient to fix the issue.

My (hopefully temporary) solution is to build kernel without vesa and vt, which I also add to the kernel module blacklist.


----------



## shkhln (Feb 6, 2021)

Snurg said:


> The PR you linked to is very interesting, it reveals yet another issue of vt
> You need to know, I have tried vt a few years ago for a short time, and went back to sc a few days later due to vt's bugs and its lack of functionality (history buffer size is very small, hard coded, thus not configurable without editing sources). So I am _not_ a vt user.


You state in the bug entry "Switching between X and text console fails, screen is garbled or no video at all", which is a well known vt issue. The sleep mode problem might not be, but that's not clear from your description.



Snurg said:


> However I think it is a different issue, as the issue I reported is _not_ in vt, but in vesa.ko (which vt depends on).
> On resuming there is a call into VGA BIOS that should not be done on Nvidia cards, because using a non-implemented BIOS function can yield unpredictable results that may depend on things like random memory or register contents, which result in a failed resume process.


It should be obvious I don't think there is anything wrong with Nvidia's BIOS or vesa.ko for that matter.



Snurg said:


> A simple check (is nvidia? then skip that unsupported BIOS call) would be sufficient to fix the issue.


If it were that simple, you probably would have a patch already. Do you?



Snurg said:


> My (hopefully temporary) solution is to build kernel without vesa and vt, which I also add to the kernel module blacklist.


…apparently not.


----------



## Snurg (Feb 6, 2021)

shkhln said:


> You state in the bug entry "Switching between X and text console fails, screen is garbled or no video at all", which is a well known vt issue. The sleep mode problem might not be, but that's not clear from your description.
> 
> 
> It should be obvious I don't think there is anything wrong with Nvidia's BIOS or vesa.ko for that matter.
> ...


If one uses sc instead of vt, then it just hangs in the text mode instead of switching to graphics mode, _if, and only if_ vesa.ko with the bugged BIOS call is loaded.
This is clear proof that this particular issue roots in vesa.ko and _no_t in vt.

The easiest temporary fix is, as I said, removing the vesa module. Easy if you do not care for vt anyway.

As I am not interested in vt as long as I am easily able to source mobos without UEFI or with non-UEFI option I have no incentive to use vt or vesa, both of which I do not see a need for.
I verified that this BIOS call is the problem by commenting it out.

For this reason I only have provided the fix - check the card type variable for "nvidia", and only call that BIOS function if it is not "nvidia".
*Honestly, I do not see the necessity to submit a patch for such an extremely simple change.*
So I just switched to using Linux for desktop things for three years until I got finally fed up from systemd and went back to FreeBSD.

*The annoying thing when one is forced to use a custom kernel due to a bug not getting fixed for years is just that one has to rebuild and reinstall kernel every time one does freebsd-update.*
So I maybe will provide a patch file when I am in the mood to work on some pending PRs, as Nvidia's great drivers shouldn't be impeded by a stupid kernel bug.

Anyway, there are always two sides of the medal 
So this issue leads to a web based custom kernel configurator in my postinstaller, and this is a good thing


----------



## free-and-bsd (Feb 6, 2021)

Snurg said:


> ...
> *Honestly, I do not see the necessity to submit a patch for such an extremely simple change.*
> ...


But why WON'T you submit a patch, then? You have already invested your time & energies into submitting a PR and finding a way out, why not make it public? That would be a logical conclusion and the responsibility henceforth with be laid on other shoulders...

Human factor interferes at times. So is it not possible, for that matter, that by not submitting your patch you only follow the trend?

I mean, some isolated incidents don't mean FreeBSD team is just THAT BAD... I remember, some 8 years ago (well, as far back as they don't keep the messages on the forum) I DID have a very unpleasant problem with the (re) driver: NIC would appear to be working while actually not usable. And that was a Realtek chip widely used in m/b's at that time.
And I had a rather unfortunate experience trying to report that bug, which ended up in nobody paying any more attention to it after my report. I was lucky enough to google-find some rather old proprietary Realtek driver for FreeBSD (version 4.8 or something). I"m not a programmer, but the code looked similar to (re), so I made up a dirty hybrid of that one and (re), and it built and worked... I still have that motherboard, but (re) was fixed a while ago.


----------



## Snurg (Feb 6, 2021)

I want to apologize in case people get the impression I consider the FreeBSD team bad.
No, not at all. It is just a matter of resources and priorities.

The issue is a bit more complicated from the normal users' (i.e. non-kernel-programmers') viewpoint.
Modifying the /usr/src/sys/dev/fb/vesa.c alone and then build/install the kernel is easy.
This was the way I found out that disabling/commenting out the BIOS call in line 520 fixes the hang issue on nvidia cards and produces reliable resume after suspend.

*So, as said, the (pseudocode) fix is:*

```
(+)if (! nvidia_card_is_installed) {
    x86bios_intr(&regs, 0x10);
(+)}
```
In the module and some other related modules there are video-related information similar those from `pciconf` in complex data structures.
It would take me hours, maybe days of looking through countless source files to find out how to write the expression (nvidia_card_is_installed) in real code.
After mastering this challenge, I still would need to learn how to make proper patchfiles for FreeBSD.

*So I would have to spend days to provide a patchfile that does just what I described in the pseudocode above.
For people familiar with kernel programming all this would only take minutes.*

So I beg for understanding that in this situation, as a normal dumb user and no kernel guru, I feel unable to comply by providing a patch file.
This is a challenge too big for my motivation, as the easy way to have suspend/resume work is building a custom kernel without vesa.ko.

P.S.: The Realtek drivers are another story... they have drivers on their site, and in my experience sometimes the one in FreeBSD, and sometimes a driver from the Realtek site works (or not). I soon preferred to generally use Intel PCI network cards instead of the poor-performance Realtek chips.


----------



## shkhln (Feb 6, 2021)

The fact remains you aren't using the patch you are advertising. How do you expect to convince anyone that it is working is beyond me.



Snurg said:


> As I am not interested in vt as long as I am easily able to source mobos without UEFI or with non-UEFI option I have no incentive to use vt or vesa, both of which I do not see a need for.
> I verified that this BIOS call is the problem by commenting it out.


You did? This is the first time in years you are actually claiming that.



Snurg said:


> This was the way I found out that disabling/commenting out the BIOS call in line 520 fixes the hang issue on nvidia cards and produces reliable resume after suspend.
> 
> *So, as said, the (pseudocode) fix is:*
> 
> ...


This isn't mentioned in PR 224069 at all (it's "uncomment /* regs.R_DL = STATE_SIZE; */" instead), no wonder everyone there is completely confused what do you want them to fix.


----------



## Snurg (Feb 6, 2021)

shkhln Later in the PR talk with jkim, the supposed author of vesa.ko, it seems to me that it is obvious that the mentioned BIOS call does no good, and that it needs to be skipped if nvidia card is found installed.

You seem to be correct stating that I failed to make that clear.
I will possibly try another attempt updating the PR in the next autumn, if nobody with better communications skills jumps in before and finds the right wording that causes the addition of such an if check around /usr/src/sys/dev/fb/vesa.c line 520.


----------



## free-and-bsd (Feb 8, 2021)

free-and-bsd said:


> ... What surprises me is I have seen such messages before. But it never caused the problem described in this discussion.
> 
> ... I NEVER had it on my other 12* installation on the same machine but which was incrementally updated by freebsd-update.


And now I"ve booted up this original installation mentioned in the quote above and can confirm now: this setxkbmap command "forgetfulness" does not happen here. Even though the USB keyboard detachment/reattachment does happen time to time:

```
ugen1.3: <SIGMACHIP USB Keyboard> at usbus1 (disconnected)
ukbd0: at uhub3, port 1, addr 3 (disconnected)
ukbd0: detached
uhid0: at uhub3, port 1, addr 3 (disconnected)
uhid0: detached
ugen1.3: <SIGMACHIP USB Keyboard> at usbus1
ukbd0 on uhub3
ukbd0: <SIGMACHIP USB Keyboard, class 0/0, rev 1.10/3.30, addr 3> on usbus1
kbd2 at ukbd0
uhid0 on uhub3
uhid0: <SIGMACHIP USB Keyboard, class 0/0, rev 1.10/3.30, addr 3> on usbus1
```
Though it happens, the X session retains my ability to switch between keyboard layouts.
Now `uname -r` output for this installation is  12.2-RELEASE-p1. Same as for the other one where the original problem happens.


----------



## free-and-bsd (Feb 8, 2021)

And also, I use the same homedir across the installations. That helps to keep things the same.


----------



## olli@ (Feb 8, 2021)

hruodr said:


> FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.


Well, it begins with the PC hardware and firmware (BIOS) which is not deterministic. You cannot build a deterministic OS on top of undeterministic HW.


----------



## free-and-bsd (Feb 8, 2021)

Well well well, I'm talking here about one and the same MACHINE 
So one would naturally expect it to be 'non-deterministic' in a more or less the same fashion across the installations of THE SAME software, no?


----------



## Snurg (Feb 8, 2021)

Sorry for chiming in again, but one more thing comes into my mind:
*Could the problem be related to the inclusion of Waylands' libinput in 12.2?*
libinput breaks some things in xorg.
Most frequently problems with mouse wheel and partial loss of functionality of xinput are being reported, but other things seem affected as well.

As chrbr revealed in post #2,  Wayland developers are definitely aware that adding libinput causes massive problems.
The workaround has been so amazingly well hidden, so that only highly-computer-competent people with great dedication and perseverance like chrbr even have a chance find out that problems have been introduced.

Hiding such crucial information so well makes me think of the difficult-to-absurd puzzles in games like Larry Laffer etc.
For my part, I do not want to waste more time with such "puzzle quest games" I didn't order. I already decided that, as soon I have set up poudriere, I will have this new option "NO_WAYLAND" (or the like) which was introduced in 12.2 in my make.conf.


----------



## olli@ (Feb 8, 2021)

Snurg said:


> Sorry for chiming in again, but one more thing comes into my mind:
> *Could the problem be related to the inclusion of Waylands' libinput in 12.2?*
> libinput breaks some things in xorg.


That’s interesting. Since the introduction of libinput to X.org I’ve finally been able to use the additional buttons and the “3D” wheel (for horizontal scrolling) on my trackball. That didn’t work before. I haven’t updated to 12.2, though; I’m still running stable/12 as of half a year ago.


----------



## olli@ (Feb 8, 2021)

By the way, even if you unset the WAYLAND option when building ports, you will still get libinput because it is the default input driver for X.org on FreeBSD >= 12. Only on FreeBSD <= 11 the old legacy drivers are used (xf86-input-keyboard and xf86-input-mouse).


----------



## shkhln (Feb 8, 2021)

libinput only works properly with the correct kern.evdev.rcpt_mask settings, which, admittedly, wasn't communicated clearly. It's also a good idea to give iichid a try.



Snurg said:


> As chrbr revealed in post #2,  Wayland developers are definitely aware that adding libinput causes massive problems.


Vivid imagination much?



Snurg said:


> I will have this new option "NO_WAYLAND" (or the like) which was introduced in 12.2


What option?


----------



## Snurg (Feb 8, 2021)

olli@ said:


> By the way, even if you unset the WAYLAND option when building ports, you will still get libinput because it is the default input driver for X.org on FreeBSD >= 12. Only on FreeBSD <= 11 the old legacy drivers are used (xf86-input-keyboard and xf86-input-mouse).


Does this mean that the legacy drivers have been removed, so users are not left an easy way to avoid libinput?


shkhln said:


> libinput only works properly with the correct kern.evdev.rcpt_mask settings, which, admittedly, wasn't communicated clearly. It's also a good idea to give iichid a try.
> Vivid imagination much?


My impression from wayland's freedesktop bugzilla I got back then when I tried to find and isolate the problems that I got when Linux integrated libinput a few years before FreeBSD was, there is an attitude to not even acknowledge that breakages of various input-related stuffs in xorg are a problem the users consider as bug.
NOTABUG, WONTFIX etc are the usual ways they "handle" bug reports.
Users are left to either finding workarounds, replacing hardware like keyboards and mice with other, "wayland-compatible" ones, which do not need correction settings, or to use a system without libinput.

*For my part, I am not against wayland, but I feel no need to participate in this kind of field testing of software whose developers show such an attitude.
I would prefer to activate wayland not before when it has matured, and this will definitely still take years.*

So I hope it will not turn out that the people who pushed through the inclusion of libinput have done it in a way that maximizes the difficulties for people who want to build FreeBSD without anything from wayland.


----------



## shkhln (Feb 8, 2021)

Do you even read other people's posts? Nobody mentioned libinput or Wayland in this thread even once (before you, that is) and yet you are writing that a person there confirmed your observations regarding the Wayland developer's attitude. Do you read your own posts before submitting them for that matter? How the fuck any of this is not off-topic?

If you want an intelligent conversation you'll have to respect reality somewhat and stop reading your own thoughts in completely unrelated messages. That's just insane.


----------



## free-and-bsd (Feb 9, 2021)

shkhln said:


> Do you even read other people's posts? Nobody mentioned libinput or Wayland in this thread even once (before you, that is) and yet you are writing that a person there confirmed your observations regarding the Wayland developer's attitude. Do you read your own posts before submitting them for that matter? How the fuck any of this is not off-topic?
> 
> If you want an intelligent conversation you'll have to respect reality somewhat and stop reading your own thoughts in completely unrelated messages. That's just insane.


It was though. Snurg mentioned it himself as a suggested reason for the bug this thread is about.
But I think the installation where this does NOT happen (on this same machine) already has libinput and related packages. I update frequently. But I will check.


----------



## Snurg (Feb 9, 2021)

I accept that I have unacceptably "vivid imagination" and better should stay quiet and just watch, smile and bookmark useful information like post #2 from chrbr.
I apologize again for having disturbed and won't post in this thread again.
So just skip the following tl;dr if you like.

I moved to using Linux as desktop for three years because it even offers a S4 suspend (hibernate to disk).
Now, moving back to FreeBSD desktop on 12.2, I felt frustrated because the bug I reported back in 2017, which prevents standard GENERIC kernels from resuming from S3 sleep on nvidia/sc systems was still not fixed, so I still have to use custom kernels
.
And now seeing all these problems cropping up in FreeBSD, which back then appeared on Linux when libinput was made default on Debian didn't delight me either.

On the mailing list there was a discussion about introducing libinput in FreeBSD.
I do not remember exactly for which version that was planned, I think 12.2, but I am sure only that it was a 12.x version.

From my intensive evdev and libinput source code reviewing and my conversation years ago with a libinput developer on bugzilla.freedesktop.org I know for sure that quite some of the functionality in classic xorg related to mice wheel is not supported (respective not emulated) in libinput.
For some of the issues, like "forgetting" of device settings or some, but not all of the mouse wheel issues, workarounds are known. (thx again chrbr )

As @shkhin pointed out that there are even more real and potential issues:



shkhln said:


> libinput only works properly with the correct kern.evdev.rcpt_mask settings, which, admittedly, wasn't communicated clearly. It's also a good idea to give iichid a try.


*In case libinput was introduced already in 12.0 and not in 12.2, then it might be a good idea to review some settings that might have been (possibly incorrectly) changed and possibly improve some documentation.*

I hope it is at least comprehensible when people, who have looked into the matter so deeply like me, suspect a possible connection to libinput, especially when suddenly a plethora of input devices problems appear out of the blue, exactly parallel to the introduction of libinput.


----------



## olli@ (Feb 9, 2021)

The Wayland bashing is completely inappropriate here. The problem described by the OP in this thread has _nothing at all_ to do with Wayland.
It _might_ have to do with libinput (although that’s not sure), but libinput is used by both Wayland and X.org in the same way. Libinput (or something very similar) would exist if Wayland didn’t exist. And libinput can even be used independently, without Wayland or X.org, for example to add touchscreen-support to an svgalib application or to a curses application.


----------

