The starting of the duck settings

With my linux machine fully operational again , I was able to continue some VR work.

Next section to tackle is the Settings screen that appears when you start the game.

I started with a void, then added a platform to see if I was stationary and then realised that I need to ensure the player is to pointing in the right direction.

It is surprising how many VR settings screens have nothing behind the player and expect them to realise this and turnaround.

Not wanting to keep people guessing, I devised a simple mesh arrow in Blender and created a sort of neon illumination on-off animation that pointed to the left and then duplicated it and rotated it to point to the right.

Now if you start pointing in the wrong direction you see one or two arrows showing you the way you should be looking.

The animation in Godot is really easy except for one point. You create an AnimationPlayer and then add tracks to it. These tracks hold key-frames for anything in scene. Just click the little key that appears next to a property to save a new key-frame. The tricky part is making the animation run in the game, you have to have a script, which seems a little overkill and only needs to call

$AnimationPlayer.play("this-way")

where "this-way" is the name of my animation.

The only settings implemented so far is the mini-maps for each arm.

There were some screenshots but they looked awful in low resolution and I am not trying to capture them again. What with balancing the Headset to make sure the view is looking the right way, to holding a Controller pointing to an object to show the selected state, to trying to hit PrtSrn on the keyboard and then manage the capture!

There was a problem

This is a weird one. My Gentoo Linux machine appeared to hang during boot and never got to the login prompt.

I had updated the kernel almost three weeks prior, so it could not be that. I had updated the installed packages using emerge but there was nothing particularly interesting in the large number of affected packages.

Skip forward to the understanding of the problem and then the fix.

It wasn't hung. Instead the graphics hand-off from the initial boot process had failed. The meant that I could just log in using the keyboard! and then run startx and get then the full GUI would load and everything was fine.

The fix was fairly straightforward, install the latest kernel 6.18.12

Diagnosing the fake problem

The most worrying part of the whole situation was where the perceived hang was occurring!

Logical Volume Manager

But it was marked successful.

The kernel was not hung because it responded to magic key presses of ALT+SYSREQ reisub

Where REISUB is

• R switch to Raw keyboard input
• E send SIGTERM to all processes
• I send SIGKILL to anything left
• S sync drive writes (flush buffers)
• U unmount drives
• B reBoot

To get access to the system I would interrupt the Grub boot and edit the kernel line to append

pci=noacpi

This got me to the login prompt but then startx would fail due to NVidia drivers not loading.

This led me to try and "fix" the display drivers

Side quest

At this point I started to try and stabilise the system. Starting with making sure all packages were up to date ... and there was my nemesis

net-libs/webkit-gtk

Webkit-gtk used to be a PITA and take a few hours to install, then it ran out of memory after running for hours. The fix was to switch out of X to a virtual terminal and dedicate CPU cores with

MAKEOPTS="-j6 -l6" emerge -av =net-libs/webkit-gtk-2.50.5-r410

which would now take 8+ hours. This time there was a slot conflict (which I did not notice). The meant that it was constantly reinstalling different versions of itself, each taking 8+ hours!! The fix for that was to install CCache This cached any build artefacts, which stopped the 8 hour rebuilds and allowed both versions to get installed.

Another side quest

AI believed the issue was caused by my motherboard firmware being out of date, which it was, but updating it did not fix my problem. The fun being that AI kept hallucinating the location of the file to download and as I did not have a GUI for a browser it would have been really handy to just run wget with the right url. In the end I downloaded on my phone and the transferred that to my PC and then that to a USB drive. The firmware did give me extra options for "rebar" but it did not help the boot issue.

OK, then I was trying all sorts of kernel parameters in Grub

pcie_aspm=off video=efifb:reprobes vga=current console=tty1

and all variations of

Fixing the real problem with a fake fix

Finally realising that the most likely cause was due to the Nvidia drivers updating and conflicting with the kernel, I rebuilt the kernel. I was paying attention to the kernel flags around frame-buffer support, so when I saw

CONFIG_FB_NVIDIA

  This driver supports graphics boards with the nVidia chips, TNT
  and newer. For very old chipsets, such as the RIVA128, then use
  the rivafb.
  Say Y if you have such a graphics board.

I was " YES! " that is me, this is the solution to my problems. It was not and it caused the boot process to utterly fail almost instantly and the Sysreq keys did NOT work!

Finally set CONFIG_FB_NVIDIA to N and rebuilt the kernel. Now it boots correctly, I can log in and the GUI loads!

Changing the world

To avoid anyone else hitting the CONFIG_FB_NVIDIA issue I investigated why it had failed so utterly.

Turns out it is old, very very old and has not been relevant for many years. The description is dangerously wrong.

So I created a patch to the Linux kernel maintainers to get it fixed for future generations.

That is still on going, but I will have an post about that eventually.