Audio issue - was Re: Starting Wayland-KDE on FC39

[Duncan]

Richard Troy posted on Sun, 3 Dec 2023 17:20:52 -0800 (PST) as excerpted:

> Hi Dave, René, Duncan, et al,
> 
> Thank you for your posts as your discussion from just before
> Thanksgiving (in the USA) seems VERY pertinent regarding a problem I'm
> experiencing.

I may or may not be much help, but this is sure interesting!  ...

> Firstly, I find what Dave's initial email describes is VERY close to my
> experience, and secondly, I think the video-card likely had or has
> something to do with it, though it's working fine now. ...I think
> Duncan's permissions dialogue is most exciting if only I knew what to do
> there about his suggestions!

> Regarding my problem: I think a permissions issue is surely the cause
> because "everything works" in KDE EXCEPT the sound, and some weird
> aspects of USB (for example, mouse / kbd are fine, but a phone can only
> be accessed via root), (oh, and the screen saver transitions from
> working to not working at weird times and I have no idea why - but then,
> I don't care about that, either).
>  
> The big deal is that KDE thinks there's no sound card, yet I discovered
> quite by accident that when I open one of the "console windows" (via
> ctl-alt-f3, for example) and log in, ANY and ALL audio I was trying to
> play in KDE is suddenly heard on the speakers, as if it was playing all
> along! I think this is a seriously good clue, and to my mind the issue
> is how I'm starting X / KDE. Unfortunately, though I've used X-11 for
> around 35 years or so, I'm far from an expert as up until now "it just
> works."

Slight detour, but knowing the name of those "console windows" you mention 
could come in handy when reading documentation.  They're called "virtual 
consoles" or VCs.  They're a kernel-level (with low-level userspace 
elements as well) system service that normally (not in single-user-mode) 
gets enabled to allow VC-switching via the ctrl-alt-fX key sequences you 
mention and date from before a GUI (X/wayland) was common, allowing a user 
to have multiple workspaces open in command-line mode -- handy for 
switching between the workspace you're trying to type an unfamiliar 
command into and another displaying the manpage for that command...

Another potentially useful thing to know about them (you may well know 
this already but for those that don't) is that as most distros configure 
them, there's the six or so logins available on the first few, then 
usually #7 is what the GUI session runs on, then there's a few more unused 
"blank" ones, *THEN* on the last easily accessible (on conventional 
keyboards with 12 function keys) #12 or so, there's a "console log".  
Switching to that to see what's listed, then back to a working VC to try 
something that's giving trouble, then back to #12 to see if there's 
anything new in the console log to hint at the problem, can sometimes be 
easier than displaying the system log via normal command (especially when 
you're debugging system log problems themselves).

And yes, that sound starts working then *is* a serious clue...

> How I got here? I'm not sure it's worthy of a lot of time, but one
> detail might help Dave. So ... I run a mostly Fedora shop (for
> historical reasons) and recently (mid September, I think) I replaced my
> venerable desktop box (not Fedora) with a fresh installation of Fedora
> Server 38 with KDE added. I had a LOT of work to do to get it configured
> for my use-case. At first audio under Wayland worked. But when I did an
> update (NOT AN UPGRADE - I kept it at 38), I strongly suspect some video
> driver got replaced (I have an unusual 6-head Radeon, single-card video)
> because afterward not only did audio not work but I then entered The
> Twilight-Zone that Dave describes (pertinent excerpts left below for
> reference) with booting issues and Wayland not starting, DM behaviors
> and so forth. It wasn't the same experience Dave reports but was an
> eerily close parallel.

BTW, you're not doing audio via HDMI off the video card, right?  I'm not 
sure that's an exactly common configuration (but then again I'm more 
familiar with desktops than laptops, it wouldn't surprise me of some of 
them were doing sound via the HDMI, tho I'm not sure how that would work), 
and I don't know much about it or if/how to usefully configure it, but I 
do know my system has a second (unused and appearing to be a stub, but 
that might be because I don't have it configured) "sound card" via the 
HDMI.  It could be useful to know if your system's configured to use that.

> I struggled mightily to get KDE up again at all. And once I did, the
> audio and weird USB problem showed up.
> 
> I never got Wayland working at all since then,

For troubleshooting at least, you might want to investigate weston as a 
low-deps basic/backup wayland compositor.

As I may have already mentioned on-thread, I don't have xorg installed 
here at all -- the only X I have is X via xwayland on wayland.  I had 
switched over to (kwin_wayland based) wayland as my daily driver and at 
first was using X as a backup if wayland refused to start, on my after-all 
live-git (so bugs can be expected and a backup is wise!), but then X 
(xorg) bitrotted and I found it easier to install the low-deps and easily 
configured via text-file weston than to troubleshoot xorg any further, 
knowing how complex it is and that since I wasn't regularly using it, even 
if I did fix it, I might well find the config bitrotted again the next 
time I really needed it.

Since then I've found that not only is weston simple and low-deps enough 
to be reasonably confident it'll come up as a backup wayland provider if I 
need one (especially since I don't have xorg at all now), but that it's 
also very handy to have around as a second-authority, using it to 
troubleshoot whether a problem is in kwin or my kde config, or appears 
also if I try it in weston, which is after all the _reference_ wayland 
compositor, so if something's not running in it OR in kwin_wayland, it's 
probably broken on wayland, period.

Since you're using kwin_x11 not kwin_wayland the scenario is of course 
somewhat different there, but knowing that the reference wayland 
compositor runs (or not) could be a very useful troubleshooting step to 
getting kwin_wayland running as well.  And of course for the more generic 
case, it's useful for testing whether normal wayland/X apps run in generic 
wayland, or are broken there too, on your system.

YMMV as they say, but I've found it both very helpful for troubleshooting 
and very comforting as a reliable if simplistic backup GUI, here.  (And 
FWIW, I just run it from the CLI login, tho I did spend a bit of time on 
its text config to get the multiple monitor setup correct -- which reminds 
me, I just upgraded to triple-4Ks from double, and haven't updated my 
weston config for that yet.  I guess I should...)

> or any graphical login
> (not that I'm a fan of that either, like Dave) and I don't care to solve
> it unless it helps solve the audio issue. ...Instead I get x-11 up by
> logging in via the "console" as a non-root user and then running a
> script similar to what Dave does.
> 
> Where Dave runs:
> 
> /usr/bin/dbus-run-session /usr/bin/startplasma-wayland
> 
> I run:
> 
> xinit /etc/X11/startplasma-x11
> 
> If I try the X11 version of the startplasma script Dave uses, it
> complains about DISPLAY and not being able to connect to the server,
> likely because the server's not up yet! I haven't tried all permutations
> yet, however.

Yes.  xinit does a bunch of scripted setup first.  Most of it is dealing 
with corner-cases that won't apply -- some years ago I actually traced the 
startup through like three different scripts and their multiple (user vs 
system) configs, but making sure the server's running before trying to 
start the window manager and rest of the session is one of the things it 
does.

Notably, however, it doesn't do much if anything with permissions, I think 
because back when most of that script was written, X-server ran as root, 
so mostly it "just worked".  Simpler times when security wasn't the 
concern it is these days...

> ...I think Duncan's on to something when he talks about users belonging
> in certain groups to solve this sort of thing. Any suggestions for WHAT
> groups I try adding the my user to? (Excerpt of Duncan's pertinent bits
> below, too).
> 
> Any and all suggestions welcome. Not having sound is a really serious
> issue

Agreed!

> On Mon, 20 Nov 2023, Duncan wrote:
> 
> Anyway, sans policykit/consolekit/etc, the solution to device
> permissions issues is normally to add the appropriate users to the
> appropriate group (see what the device group is set as and try that, if
> your user isn't already in that group), or possibly to change the udev
> config to loosen the permissions a bit (does the device need to be
> writable by users in that group?).

OK, two things to try, or one to try and one question to ask and maybe 
try...

First the question.  When you run xinit from your CLI login, does X start 
in that VC or on a different one (can you switch back and forth between 
the launching CLI session and X or does it start in the same VC so you 
can't switch back to the launching CLI session, tho you can switch to 
others), and is the existing login left running so when you quit/logout of 
X, the CLI session remains running so you can run other commands or start 
X again without logging back in, or are you left back at the CLI login 
prompt -- that CLI login session terminates when X starts?

I had a similar issue back in the HAL era (before policykit, etc), that 
was because the existing CLI session ended, and the automation removed the 
permissions when the logged-in user session ended, as it didn't consider 
the X session a login session.  IIRC, I fixed it then by tweaking things 
so it left the existing CLI login running, so the automation didn't kill 
the permissions because the logged-in user didn't logout.  (Later I killed 
all that automation and have my user in the relevant groups with 
appropriate group permissions, instead.  But that was later.  The 
immediate fix was just keeping the CLI user logged-in while I was in the 
GUI.)

If the launching CLI login continues I'm not sure why logging in in 
another CLI VC allows sound to work, since the existing login should take 
care of it.  OTOH, unless something is programatically killing that login, 
it should remain unless you're sourcing xinit instead of just running it 
(source xinit or . xinit, instead of just running it, xinit).  But perhaps 
something is programatically killing the launching CLI login?

Second thing, attack the permissions angle by trying to figure out what 
permissions are changing and from-what to-what.  I'd do that like this:

With sound NOT working, preferably after a clean reboot just so we know 
where we're starting, do a(n) ls -lR (long, recursive) of /dev and dump 
the results into a "broken" file.

(Do this from a directory you can write the files to and are comfortable 
doing so.  Some folks might use their home dir, others won't want to 
"contaminate" it with scratch files like this so will use somewhere else 
they can write to... or just provide a path to dev.broken or whatever you 
call it.)

ls -lR /dev > dev.broken

Then do the VC switch and login that makes things work, but try not to do 
anything else (like plugging new devices) that will affect the below 
listing and unnecessarily complicate the diff.

Then do a second listing, this one to dev.working:

ls -lR /dev > dev.working

After you've gotten that listing you can go back to normal, plugging 
anything you need, etc.

Now for the interesting bit, diff the two to see what changed:

diff -u dev.broken dev.working

Or use your favorite diffing program, side-by-side mode or whatever, as 
appropriate. (I'm an mc guy so like mcdiff, or try the kde kdiff3 program, 
or whatever.)

Pay particular attention to user/group/perms changes.  With any luck...

You may be able to take it from there and won't need to post the diff.  
Else copy the diff or redirect it to dev.diff and post it (of course check 
it for info you wouldn't want to post first, but if there's anything 
particularly personal in just the diff you probably did something extra 
between dev.broken and dev.working that increased the diff).

As to what to do to affect the necessary changes based on the diff, I'm 
not sure I'll be able to answer that, but the diff is a start, and we can 
go from there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman