Gentoo Desktop

This for a Samba server. I've figured out that it's related to PAM settings, I just haven't figured out what rules I need to properly authenticate.

Ran into a weird issue with HL2, though; I could launch the game and play it, but I couldn't load a saved game.
Apparently, Steam defaults to using the Linux binary (understandable) which seems to have...issues. Forcing Steam to use the Proton layer allows it to use the Windows binary and then I can successfully load a saved game.
 
Ran into an issue with Webex and VirtualBox; well, the issue was VB, but I first noticed it in conjunction with Webex.

Apparently, VB was configured to use Alsa for sound. Not sure how that happened, but regardless it did. So, everything was working fine, near as I could tell, until I went to jump on a Webex call while running VB. I access my customer through a VM on my side (running in VB) and connect to a VM on their side using an application named "Windows App" which is essentially RDP, but don't call it that because it's totally and completely different, see, and you have to use this special Microsoft Windows application to access it.

Anyway, I was doing some training for my customer so was using audio from the remote VM into my VM, and somehow that caused VB to grab Alsa exclusively, so Webex wouldn't work (in fact NOTHING involving my local audio would work; even the sound control panel was unable to do anything).

I went into VB settings for the VM and changed it from using Alsa to PulseAudio, and now things are working much better. Not quite sure what went wrong there.
 
Games seem to be just a little jittery. Specifically, I've noticed that Portal 2 and Half-Life 2 seem to jump just a bit when turning left or right. Strafing left or right seems fine, it's rotating that seems specifically to cause the game to 'twitch'. I don't recall Mint behaving this way, but it COULD just be me.
 
Ran into an issue with Webex and VirtualBox; well, the issue was VB, but I first noticed it in conjunction with Webex.

Apparently, VB was configured to use Alsa for sound. Not sure how that happened, but regardless it did. So, everything was working fine, near as I could tell, until I went to jump on a Webex call while running VB. I access my customer through a VM on my side (running in VB) and connect to a VM on their side using an application named "Windows App" which is essentially RDP, but don't call it that because it's totally and completely different, see, and you have to use this special Microsoft Windows application to access it.

Anyway, I was doing some training for my customer so was using audio from the remote VM into my VM, and somehow that caused VB to grab Alsa exclusively, so Webex wouldn't work (in fact NOTHING involving my local audio would work; even the sound control panel was unable to do anything).

I went into VB settings for the VM and changed it from using Alsa to PulseAudio, and now things are working much better. Not quite sure what went wrong there.
ALSA was always a bit of a pain. Sound mixing from multiple applications required the dmix plugin, with applications configured to point to the pcm.dmixer device rather than to the hardware itself, or else the hardware would be locked for the application's exclusive use.

PulseAudio... was worth avoiding for several years, but once grown-ups went in and fixed its lead developer's mess, it actually solved a lot of problems by providing a more rational architecture for applications to be built against.

I'd guess that VB grabbed the raw device rather than the mixer device, and PipeWire's ALSA emulation honoured its legacy behaviour.
 
So, apparently the X shim in Wayland only kindof works?

It seems that Webex on Wayland doesn't do screen-sharing because of an issue with the WebRTC screen-sharing API.
 
Started X instead of Wayland as my Compositor and I can share the screen in Webex now. Apparently, support for Wayland is Coming Soon in Webex (via Xwayland).
 
So, apparently the X shim in Wayland only kindof works?
I think that's a fair summary. Some methods that worked in X aren't permitted with the wayland security model, so either the applications get updated, or the xwayland interface needs to capture it, or you'll simply use X11.
 
Back
Top