Chris's Wiki :: blog/linux/Fedora16EnvironmentBits Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/Fedora16EnvironmentBits?atomcommentsDWiki2012-03-20T04:07:21ZRecent comments in Chris's Wiki :: blog/linux/Fedora16EnvironmentBits.By Chris Siebenmann on /blog/linux/Fedora16EnvironmentBitstag:CSpace:blog/linux/Fedora16EnvironmentBits:96c61ef09a2d948f48d8227d94cb04dd217f81b3Chris Siebenmann<div class="wikitext"><p>A quick note: I tried changing my startx code to start the X server on
the same VT as my login and it did make the permissions issues with
audio (and DVD burning) go away. Unfortunately it appears to break
volume management through <code>gnome-fallback-mount-helper</code>. I have no
idea why and in the modern Linux way, it is somewhere between very
challenging and impossible for ordinary people to debug this.</p>
</div>2012-03-20T04:07:21ZFrom 188.226.51.71 on /blog/linux/Fedora16EnvironmentBitstag:CSpace:blog/linux/Fedora16EnvironmentBits:c52f7f95220845cc535ca4e76f3cd76a6b48028fFrom 188.226.51.71<div class="wikitext"><p>Several points about your setup came to mind:</p>
<p>1) Vanilla "startx" from one VT, starting X on another, is not supported by systemd.</p>
<p>I don't use fedora, and I've bumped into some problems regarding X switching VT on start.
In the past, I've got "we don't support it atm" response in #systemd, but looks like it was discussed on #fedora-devel and #systemd just about the time / the day after this post (mezcalero == Lennart):</p>
<pre>
<mezcalero> coling: we had some discussion about startx on #fedora-devel the other day
<mezcalero> coling: so we found a very simple way to bring startx back in a sane way
<mezcalero> the idea is that startx should not attempt to open a new VT
<mezcalero> but instead simply "convert" the existing session on the existing VT
<mezcalero> it should just invoke X with -noswitchvt (or how that switch is called)
<mezcalero> so that the X runs on the same VT as the invoking bash
<mezcalero> and then all the access control will work
</pre>
<p>So I thought you might still bump into that, xserverrc is the solution.</p>
<p>In fact, permissions for sound card should be set by systemd-logind (in late systemd versions, not sure which one is in F16), so your problem with permissions for pulse might be direct result of that.</p>
<p>2) Why do you need to start pulseaudio by hand at all?</p>
<p>I mean, everything that links against pulse has "connect or start" behavior, and libasound_module_*_pulse.so starts pulse for any app that tries to use alsa.</p>
<p>3) I heard fedora devs went gung-ho on disabling stuff started from anywhere but systemd, but doesn't notification-daemon has systemd-enabled dbus service file to auto-start on first message received? (and die in a while if everything's quiet)</p>
</div>2012-03-11T12:06:10ZFrom 79.216.138.138 on /blog/linux/Fedora16EnvironmentBitstag:CSpace:blog/linux/Fedora16EnvironmentBits:4d093cb24b994f4a00c45e8e9dced6e3f38b5ab0From 79.216.138.138<div class="wikitext"><p>I don't bother with half of that. I used to use halevt but when it broke I just added entries in /etc/fstab with the user mount option for my own SD cards and memory sticks. I believe you can get stuff automounted with udev rules directly and there are some solutions based on udisks.</p>
<p>I never had much success with pulseaudio and ended up just uninstalling it and leaving stuff to use alsa directly. Does it really offer any advantages? For volume control, I've simply bound the extra keys on my keyboard.</p>
</div>2012-03-09T21:54:16Z