Pulseaudio determine active user. [Solved (sort of)]

[CrankyPenguin]

While this is not a Pulseaudio board the system seems to vary with OS so I ask it here as well.

I am using Pulseaudio via ConsoleKit with no system-wide access as per the Gentoo handbook (http://wiki.gentoo.org/wiki/PulseAudio#Configuration) The catch is that I need to set my acpid action scripts to toggle the mute on the pulseaudio device as discussed here: https://forums.gentoo.org/viewtopic-t-994206-highlight-.html.

While the standard acpi volume up and down commands work fine mute toggling fails to work as acpid scripts are run as root. Thus what I need to do is to have a script that determines what the "active" user is according to ConsoleKit and thus the active Pulseaudio user. I can run code to find the xorg user and I do that already for some tasks but I would like audio mute to work in the console so that trick won't work. Is there a pulseaudio process that I can check for? Or a way to ask Consolekit who the "active" user is? Thanks.

Edit: see the post at the bottom of the thread for the solution.
_________________
Linux, the OS for the obsessive-compulsive speed freak in all of us.

[deefster]

I know this isn't the question you are asking exactly, but I read the post you linked, and it looks like all you're trying to do is get your keyboard functions to work with pulse. Is that still the case? I use kde and my ms wireless keyboard audio functions work fine with built-in phonon, but if your situation is different, maybe look at the code for something like xfce-extra/xfce4-volumed-pulse where key bindings are coded to pulse.

http://bazaar.launchpad.net/~mrpouit/xfce4-volumed-pulse/master/files/head:/src/

[CrankyPenguin]

Hi Deefster, thank you for the link. I'll take a look at it.

My situation is a bit different. My volume keys generate acpi events not keycodes which is generally fine as I use them in console mode as well. I have updated acpid to trap the events and then to respond appropriately via calls to amixer which I showed in the linked post. All that worked fine until an update of other packages forced pulseuadio into my life.

The problem seems to be that acpid commands get issued as root while pulseaudio is running for the "current" user. This is not an issue for the volume up and down commands as pulseaudio dutifully notices the alsamixer chang and changes its volume accordingly. This does not work for mute, however, where pulseaudio is happy to mute when the alsamixer mutes but, for some odd reason, does not unmute. This problem also affects some other systems, particularly Ubuntu users. Some have made hacks to pulseaudio to get it to ignore the controls but those have not worked for me. Moreover a review of some of the Pulseaudio forums has suggested that the developers see this as the proper behavior, i.e. failure to unmute is a feature not a bug. The reasoning that I saw was, in effect, that other people should send the right signal to them not that not that they should listen to other people.

In any case, I have determined that manual execution of the commands as the current user will mute and unmute properly so if I can programmatically determine who ConsoleKit sees as the current user then I will do that. But I am not sure how that can be done from the commandline. I had to go through some fun tricks to determine the current user of x11 for another script and I can use that but, as I said, in my original post, I'd also like to get this working in the console if possible.
_________________
Linux, the OS for the obsessive-compulsive speed freak in all of us.

[CrankyPenguin]

Success I was able to solve my problem by scripting a tool that relies on ConsoleKit and Dbus to determine the active user and then to apply that when executing update commands.

First I followed most of the directions in this thread to setup ConsoleKit and Dbus. I did not include policykit systemd or udisks or upower updates only those dealing with ConsoleKit.

I was then able to see active sessions under ck-list-sessions on startup after startx is run. Because this is a single-head system there is only one "seat" defined.

I then followed this advice on UbuntuForums to identify the active seat and wrote the script below http://askubuntu.com/questions/194382/how-to-find-out-who-is-using-the-physical-console.