.xinitrc commands don't last

[free-and-bsd]

... 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:

Code:

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]

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

 

[olli@]

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]

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]

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 [USER=41201]chrbr[/USER] 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 [USER=41201]chrbr[/USER] 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@]

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@]

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]

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.

As [USER=41201]chrbr[/USER] revealed in post #2, Wayland developers are definitely aware that adding libinput causes massive problems.

Vivid imagination much?

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

What option?

 

[Snurg]

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?

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]

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]

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. [USER=50369]Snurg[/USER] 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]

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 [USER=41201]chrbr[/USER] )

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

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@]

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.