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
