[arch-general] [Bad fix?] was Re: No user sound - only root has access alsamixer on virtualbox?
David C. Rankin
drankinatty at suddenlinkmail.com
Mon Feb 3 10:05:31 EST 2014
On 02/02/2014 04:22 PM, Armin K. wrote:
>> According to
>> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote
>>  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"
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:
Description=TDE Display Manager
On installation trinity also creates and installs a pam file in pam.d
containing the following:
#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:
All of this looks exactly correct for what is described in
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
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
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?
David C. Rankin, J.D.,P.E.
More information about the arch-general