On 02/03/2014 09:05 AM, David C. Rankin wrote:
On 02/02/2014 04:22 PM, Armin K. wrote:
According to https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote [1] under Installation) sound access was provided to users via Consolekit in the past. Consolekit is no longer part of Arch. I have kept basic build of TDE for Arch totally reliant on Arch packages, so I would like to solve the sound problem in the proper way so that this desktop is a seamless addition to Arch. What is the best approach to finding a solution to this sound issue?
You shouldn't need to have user member of any group that granted access to the any kind of hardware nowadays. That's handled by logind, which is a replacement for ConsoleKit.
But, if you start your DE via .xinitrc, you need to make xserver start on the same VT in order to preserve valid systemd session. Also, you should have a user dbus daemon started, as I already pointed out.
If you are starting your DE via some kind of Display Manager, and given that it uses PAM, its PAM file need to contain systemd pam file in session section, unless you include system files.
https://wiki.archlinux.org/index.php/Xinitrc#Getting_started - Scroll down to the note right before "Configuration"
https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss...
OK,
Now we are getting somewhere. Trinity desktop tdm.service is started by systemd on boot. tdm is an updated kde3/kdm desktop manager. tdm.service contains:
[Unit] Description=TDE Display Manager After=systemd-user-sessions.service
[Service] ExecStart=/opt/trinity/bin/tdm
[Install] Alias=display-manager.service
On installation trinity also creates and installs a pam file in pam.d containing the following:
/etc/pam.d/trinity #%PAM-1.0
#auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login
On login, dbus and pulseaudio are started from /etc/X11/xinit/xinitrc.d. The two files started are:
30-dbus pulseaudio
All of this looks exactly correct for what is described in https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss.... Except for the response from loginctl. Checking loginctl I do not get Remote=no and Active=yes as suggested on the page, instead I get:
08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID NAutoVTs=6 KillExcludeUsers=root KillUserProcesses=no IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 InhibitDelayMaxUSec=5s HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no
So, according to the Troubleshooting section -- If it does not [contain Remote=no and Active=yes], make sure that X runs on the same tty where the login occurred.
Here is where I need help. Systemd is doing the starting, so how can I make sure that X runs on the same tty where the login occurred? Where/how do I specify what vt X is running on?
Bad to reply-to-self, but I thought the following information would be helpful. Here are the process started and running including dbus: /sbin/init /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-udevd /usr/bin/VBoxService -f /usr/lib/systemd/systemd-logind /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation /sbin/agetty --noclear tty1 /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin /opt/trinity/bin/tdekbdledsync /usr/bin/gpg-agent --daemon /usr/bin/ssh-agent -s dcopserver [tdeinit] --nosid --suicide kded [tdeinit] --new-startup start_tdeinit --new-startup +kcminit_startup ksmserver [tdeinit] --windowmanager twin -- David C. Rankin, J.D.,P.E.