seatd – without a run_time_dir script?

Forum Forums New users New Users and General Questions seatd – without a run_time_dir script?

  • This topic has 37 replies, 11 voices, and was last updated Feb 13-3:52 am by stevesr0.
Viewing 8 posts - 31 through 38 (of 38 total)
  • Author
    Posts
  • #131802
    Member
    anti-apXos

      @blur13, I guess you’ll be sad to learn that even wired headphones/aux don’t work on my current laptop using pure ALSA. I have to enable Pipewire just for them, though otherwise I do just use ALSA.

      The fact that they work with Pipewire means there must be some way to get them working even without, but I’ve tried quite a lot with no luck. I’ve never run into this on other systems, but it does point to one of the issues with ALSA that Pipewire and PulseAudio seem to solve, which is how extremely hardware-dependent it is.

      #131809
      Member
      techore

        alsa can be a nuisance configure. I spent hours having to do a deep dive on alsa to get it to use a gpu audio interface for my home theater. However, once it was setup, two years ago, I have had none of the nonsense with pulseaudio frequently switching audio outputs and me having to reselect over and over and..

        I do see the appeal of pipewire even if I don’t use it. Each to their own.

        @stevesr0, based on my observations in this thread, I would recommend backing out the changes to a known state and work slowly through the changes to troubleshoot. This assumes you can back them out to a known good state. Otherwise do a clean install and take another run at it until you are satisfied with the outcome and your understanding.

        Just a suggestion. These little things can drive you nuts if you let them. 😛

        #131810
        Member
        stevesr0

          Hi abc-nix,

          I tried copying the script which I run before running startx, which allows PAVUCONTROL to launch, into my /etc/xdg/openbox/autostart file.

          Didn’t work. No /run/user directory is created.

          Then I tried copying the lines in the desktop-session-user-dirs-update.sh that deal with creating the /tmp/1000 directory into the /etc/xdg/openbox/autostart but that also had no effect.

          N.B. I edited in xorg (because that gave me access to leafed for easy copying from the different sources into /etc/xdg/openbox/autostart) and exited Xorg and then ran startx each time. Don’t think I rebooted between editing efforts, tho.

          However, running the script WITHOUT REBOOTING and running startx, always worked.

          So, with the goal of “automating” the creation of a runtime directory, I am still striking out.

          I haven’t tried manually running the /etc/xdg/openbox/autostart before running startx. Even if that worked, it would not be an improvement over running the runtimedir.sh script.

          N.B. This is not a big practical problem, but an educational one I wish to understand. I just want to figure out how to get this to work automatically, as it does with the 23 full install.

          #131812
          Member
          abc-nix

            How do you start openbox? Openbox will probably not autostart anything, but openbox-session will.

            Source: http://openbox.org/wiki/Help:Autostart
            When you run the openbox command on its own, the autostart scripts will not run. They are run by openbox-session or when you log in graphically with the “Openbox” session type.

            If you start openbox with desktop-session
            startx /usr/local/bin/desktop-session openbox
            it will use desktop-session to manage all those things (like the startup script, variables, config, etc.) you may find useful.

            So all this depends on how you are starting openbox on your system.

            #131947
            Member
            stevesr0

              Hi abc-nix,

              There are two different ways to set things up in X, apparently. One is to use the desktop-session approach, which I believe is the most widely used in antiX. The other is to use the XDG approach. That is what I setup when I first installed this antiX distro.

              My Sid system uses /etc/xdg/openbox/autostart to launch PAVUCONTROL, Wireplumber and pipewire and that works (as long as I use the script from Levinsen before invoking startx).

              Note that I do NOT run startx /etc/xdg/openbox/autostart, just startx.

              After reading your suggestion, I just tried that combination and X tried to launch but closed with an error (screen truncated)

              Read error 19e context: No such file or directoryule “libpipe

              Re: Using /usr/local/bin/desktop-session to launch X.

              I did a search through the /usr/local/bin/desktop-session file. There is no mention of Openbox in that file by default.

              However, I tried launching X using your suggested

              startx /usr/local/bin/desktop-session openbox

              X launched fairly normally, but with a box that stated, “Your window manager is not one of the supported window managers.”

              I tried running PAVUCONTROL, but it started wouldn’t connect, just as it does when the Levinsen script has not been run.

              Overall, this was similar to what I see when I invoke startx by itself without having first run the script.

              At this point, I need to better understand what is setup “properly” on my Sid system and what is not <g>.

              I will look at all the (possibly) relevant config files that I can think of and outline on a piece of paper what is setup in which file. (The /etc/skel/, /etc/X11, /.desktop-session, /desktop-session, /etc/xdg, /usr/local, /home…)

              I will also look at the full installs I have – which have a default (working) desktop-session setup – in order to see what things are specified where.

              In the meantime, the script continues to enable pavucontrol and pipewire in general to work.

              Rather than asking people (who can’t see my messy, but working setup) to help at this time, I think it is more reasonable for anyone curious or benevolent to wait until I can post an update that explains how my Sid system is setup to run Xorg and applications under it.

              Thanks to all for comments to date.

              • This reply was modified 3 weeks, 4 days ago by stevesr0.
              • This reply was modified 3 weeks, 4 days ago by stevesr0.
              #132821
              Member
              stevesr0

                BELATED REPLY to Techore,

                It was post #95369 on page 5 (not 6). the url should be
                https://www.antixforum.com/forums/topic/pipewire-without-systemd/page/5/

                re: gpg-agent.

                I did see that a Debian bug report from 2018 that the GPG_AGENT_INFO listing is obsolete. So the question of why it moves around after using Levinsen’s script is not important.

                **I assume that it appears in my Sid install, but not my antiX22–>23 install reflects the fact that the Sid install is built on an earlier version of antiX, when that listing worked.

                I do not know why gpg-agent would or wouldn’t be involved with Pipewire. Perhaps, gpg-agent was invoked for the use of the temporary directories needed for Pipewire (/tmp/1000/.run or /run/user/1000) prior to 2018?

                In any event, not something that seems to be functional in regard to Pipewire.

                #132846
                Member
                techore

                  BELATED REPLY to Techore

                  Thank you and no worries. It’s a red herring so you can safely ignore it. I do understand seeing unexpected crud can be annoying.

                  #132982
                  Member
                  stevesr0

                    FINAL UPDATE ON THIS THREAD (by me).

                    I started this thread because I wanted to get Pipewire working without using a special runtime directory script. At this point, I have learned to add some necessary lines to my /home/stevesr0/.profile file that lead to a functional runtime directory that gets populated to support Pipewire when startx launches Xorg.

                    Apparently, this is needed for my “minimalistic” install from a net .iso because it lacks something setup automatically in a full install.

                    In the end, I don’t think seatd has much if anything to do with either the runtime directory or getting Pipewire working.

                    Also, the GPG_AGENT statement is not relevant. It’s appearance is a bug, as it’s use was deprecated by 2018.

                    This thread overlaps another thread (How is the /tmp/1000/.run managed in antiX23) which I started. I suggest any further comments might better be posted there.

                    My apologies for duplication.

                    • This reply was modified 2 weeks, 3 days ago by stevesr0.
                  Viewing 8 posts - 31 through 38 (of 38 total)
                  • You must be logged in to reply to this topic.