brltty doesn't talk on the live or installed system

philm commented

2016-05-14 11:25:20 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

brltty, the open source braille display server, can also function as a console screen reader. For sonar, I've been attempting to replace speakup with this. However, even though I have it configured correctly, pulse audio is not letting brltty's speech through because brltty is running as root. The solution seems to be either configuring logind to change the permissions such that brltty can get sound through or to run pulse audio in system mode. This has security and also convenience implications. The jist of which is that if pulse audio is run in system mode, any other user can tamper with any other user's sounds, cause other sounds to play, interrupt the functioning of their desktop, etc. It also means that instead of the volume of apps and the desktop being stored per user as is the usual case, it's stored system wide, meaning it's not possible for each user to have their own settings. I'd prefer to go the logind rout but I'm open to testing pulse audio being run in system mode on a live image, just not on an installed system.

*Created by: coffeeking* brltty, the open source braille display server, can also function as a console screen reader. For sonar, I've been attempting to replace speakup with this. However, even though I have it configured correctly, pulse audio is not letting brltty's speech through because brltty is running as root. The solution seems to be either configuring logind to change the permissions such that brltty can get sound through or to run pulse audio in system mode. This has security and also convenience implications. The jist of which is that if pulse audio is run in system mode, any other user can tamper with any other user's sounds, cause other sounds to play, interrupt the functioning of their desktop, etc. It also means that instead of the volume of apps and the desktop being stored per user as is the usual case, it's stored system wide, meaning it's not possible for each user to have their own settings. I'd prefer to go the logind rout but I'm open to testing pulse audio being run in system mode on a live image, just not on an installed system.

philm commented

2016-05-14 11:31:36 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Should users be in the "audio" group?

There are three kind of distributions: 1) those who control access to the sound card by adding users to the "audio" group, 2) those who use udev (or HAL) and ConsoleKit to dynamically give access to the currently "active" user, but allow overriding that using the "audio" group and 3) those who don't use the "audio" group at all, but rely solely on HAL+ConsoleKit to grant access to the sound card.

To find out which group your distribution belongs to, run ls -l /dev/snd. If the permission field of many of the listed files contains a plus character in the end, like this:

crw-rw----+ 1 root audio 116, 7 Aug 2 08:57 pcmC0D0p

then your distribution most likely belongs to group 2 or 3. If the group of the file is "audio", as above, then the distribution belongs to group 2, otherwise it belongs to group 3.

If there was no plus character in the permission fields, like in this example:

crw-rw---- 1 root audio 116, 7 Aug 2 08:57 pcmC0D0p

then your distribution belongs to group 1.

Now that you know how your distribution does access control to the sound card, it's easy to determine whether you should put users to the "audio" group or not:

If your distribution belongs to group 1, you must put all users to the "audio" group or otherwise they can't access the sound card.
If your distribution belongs to group 2 or 3, you should make sure that no one is in the "audio" group. (If you plan running pulseaudio in the system-wide mode, then the special user "pulse" should still be in the "audio" group in order to have access to the sound card.) If your distribution belongs to group 1 or 2, fast user switching doesn't work properly if users are in the "audio" group.

Changes

github.com/manjaro/manjaro-tools@bdadb4d3d7
github.com/manjaro/thus@30c7c32930
github.com/calamares/calamares-manjaro@4f556e0ee0

*Created by: philmmanjaro* **Should users be in the "audio" group?** There are three kind of distributions: 1) those who control access to the sound card by adding users to the "audio" group, 2) those who use udev (or HAL) and ConsoleKit to dynamically give access to the currently "active" user, but allow overriding that using the "audio" group and 3) those who don't use the "audio" group at all, but rely solely on HAL+ConsoleKit to grant access to the sound card. To find out which group your distribution belongs to, run ls -l /dev/snd. If the permission field of many of the listed files contains a plus character in the end, like this: `crw-rw----+ 1 root audio 116, 7 Aug 2 08:57 pcmC0D0p` then your distribution most likely belongs to group 2 or 3. If the group of the file is "audio", as above, then the distribution belongs to group 2, otherwise it belongs to group 3. If there was no plus character in the permission fields, like in this example: `crw-rw---- 1 root audio 116, 7 Aug 2 08:57 pcmC0D0p` then your distribution belongs to group 1. Now that you know how your distribution does access control to the sound card, it's easy to determine whether you should put users to the "audio" group or not: If your distribution belongs to group 1, you must put all users to the "audio" group or otherwise they can't access the sound card. If your distribution belongs to group 2 or 3, you should make sure that no one is in the "audio" group. (If you plan running pulseaudio in the system-wide mode, then the special user "pulse" should still be in the "audio" group in order to have access to the sound card.) If your distribution belongs to group 1 or 2, fast user switching doesn't work properly if users are in the "audio" group. **Changes** https://github.com/manjaro/manjaro-tools/commit/bdadb4d3d7c92c6f8340305b4f305da4b328d74e https://github.com/manjaro/thus/commit/30c7c329302901af8d67924adba9600e8e090a7d https://github.com/calamares/calamares-manjaro/commit/4f556e0ee0cb4660be3a88364b910a5fc760fdaa

philm commented

2016-05-14 12:18:35 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

openrc editions woud need audio group, they usually don't provide pulse and just alsa.

*Created by: udeved* openrc editions woud need audio group, they usually don't provide pulse and just alsa.

philm commented

2016-05-14 13:03:47 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

@udeved: then how should we handle it? I check if it works without the audio group on that what I want to fix and then we think on how we add audio when needed. This affects manjaro-tools-base, thus and calamares. cli-installer uses the function of manjaro-tools-base.

*Created by: philmmanjaro* @udeved: then how should we handle it? I check if it works without the **audio** group on that what I want to fix and then we think on how we add **audio** when needed. This affects **manjaro-tools-base**, **thus** and **calamares**. **cli-installer** uses the function of **manjaro-tools-base**.

philm commented

2016-05-14 13:08:59 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

User privileges (ALSA)

Usually, local users have permission to play audio and change mixer levels.

To allow remote users to use ALSA, you need to add those users to the audio group.
Note: Adding users to the audio group allows direct access to devices. Keep in mind, that this allows applications to exclusively reserve output devices. This may break software mixing or fast-user-switching on multi-seat systems. Therefore, adding a user to the audio group is not recommended by default; unless you specifically need to [1].

*Created by: philmmanjaro* **User privileges (ALSA)** Usually, local users have permission to play audio and change mixer levels. To allow remote users to use ALSA, you need to add those users to the audio group. Note: Adding users to the audio group allows direct access to devices. Keep in mind, that this allows applications to exclusively reserve output devices. This may break software mixing or fast-user-switching on multi-seat systems. Therefore, adding a user to the audio group is not recommended by default; unless you specifically need to [[1](https://wiki.ubuntu.com/Audio/TheAudioGroup)].

philm commented

2016-05-14 13:30:27 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

@philmmanjaro

I am fine if you remove it from default groups.
We just need to make all maintainers who try openrc edition aware to set up their groups.

Generally, I am asking we all sit together an figure out some defaults, every edition will be using.
I think some suspend issues for example may be related that not all editions configure tlp for systemd properly.
I hold the view, we allow too much freedom for development tools, which hurts us, due to a missing standard.

*Created by: udeved* @philmmanjaro I am fine if you remove it from default groups. We just need to make all maintainers who try openrc edition aware to set up their groups. Generally, I am asking we all sit together an figure out some defaults, every edition will be using. I think some suspend issues for example may be related that not all editions configure tlp for systemd properly. I hold the view, we allow too much freedom for development tools, which hurts us, due to a missing standard.

philm commented

2016-05-14 13:41:58 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

@udeved: yes there should be a standard. We simply have to define one together.

*Created by: philmmanjaro* @udeved: yes there should be a standard. We simply have to define one together.

philm commented

2016-05-14 14:01:18 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Urgently.
We can't ensure certai quality, if many editions are free to basically produce a sonar type sub project.
I am absolutely fine sonar does it, but not community.

*Created by: udeved* Urgently. We can't ensure certai quality, if many editions are free to basically produce a sonar type sub project. I am absolutely fine sonar does it, but not community.

philm commented

2016-05-14 17:17:25 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

I tested it now. Using no audio group don't break anything. However I just tested pulse. Still don't get it run in system wide mode in Gnome.

*Created by: philmmanjaro* I tested it now. Using no **audio** group don't break anything. However I just tested **pulse**. Still don't get it run in **system wide mode** in Gnome.

philm commented

2016-05-14 17:53:54 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

This might give it the power to run as system-wide:

#!/bin/bash
echo "Setup pulseaudio for system-wide mode"
groupadd --system pulse
groupadd --system pulse-access
useradd --system -g pulse -d /var/run/pulse pulse
echo "Add users"
usermod -a -G audio pulse
usermod -a -G pulse root
usermod -a -G pulse sonar
usermod -a -G pulse-access root
usermod -a -G pulse-access pulse
usermod -a -G pulse-access sonar
echo "Update config file ..."
sed -i 's|; system-instance = no|system-instance = yes|' /etc/pulse/daemon.conf

*Created by: philmmanjaro* This might give it the power to run as **system-wide**: ``` #!/bin/bash echo "Setup pulseaudio for system-wide mode" groupadd --system pulse groupadd --system pulse-access useradd --system -g pulse -d /var/run/pulse pulse echo "Add users" usermod -a -G audio pulse usermod -a -G pulse root usermod -a -G pulse sonar usermod -a -G pulse-access root usermod -a -G pulse-access pulse usermod -a -G pulse-access sonar echo "Update config file ..." sed -i 's|; system-instance = no|system-instance = yes|' /etc/pulse/daemon.conf ```

philm commented

2016-05-14 20:40:40 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

@coffeeking: I manged to get pulseaudio now in system mode started: github.com/manjaro/manjaro-tools-iso-profiles@8f2775c8e1 However this doesn't fix your brltty issue.

*Created by: philmmanjaro* @coffeeking: I manged to get **pulseaudio** now in **system mode** started: https://github.com/manjaro/manjaro-tools-iso-profiles/commit/8f2775c8e192a8e8b9e507e81a8c30c7e967ed31 However this doesn't fix your **brltty** issue.

philm commented

2016-05-14 20:49:25 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

This is the actual error:

[sonar@sonar ~]$ systemctl | grep failed
● brltty.service                                 loaded failed failed    Braille Console Driver
● plymouth-quit-wait.service                     loaded failed failed    Wait for Plymouth Boot Screen to Quit
● systemd-modules-load.service                   loaded failed failed    Load Kernel Modules
[sonar@sonar ~]$ systemctl status brltty
● brltty.service - Braille Console Driver
   Loaded: loaded (/usr/lib/systemd/system/brltty.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Sat 2016-05-14 20:41:30 UTC; 5min ago
  Process: 242 ExecStart=/usr/bin/brltty --pid-file=/run/brltty.pid (code=exited, status=0/SUCCESS)
 Main PID: 299 (code=killed, signal=ABRT)

May 14 20:41:27 sonar brltty[242]: BRLTTY 5.3.1 rev unknown [http://brltty.com/]
May 14 20:41:27 sonar brltty[242]: BRLTTY 5.3.1 rev unknown [http://brltty.com/]
May 14 20:41:28 sonar brltty[299]: directory created: /var/lib/brltty
May 14 20:41:28 sonar systemd[1]: Started Braille Console Driver.
May 14 20:41:28 sonar brltty[299]: BrlAPI Server: release 0.6.4
May 14 20:41:30 sonar brltty[299]: eSpeak Speech Driver: version 0.3
May 14 20:41:30 sonar brltty[299]: Linux Screen Driver:
May 14 20:41:30 sonar systemd[1]: brltty.service: Main process exited, code=killed, status=6/ABRT
May 14 20:41:30 sonar systemd[1]: brltty.service: Unit entered failed state.
May 14 20:41:30 sonar systemd[1]: brltty.service: Failed with result 'signal'.

*Created by: philmmanjaro* This is the actual error: ``` [sonar@sonar ~]$ systemctl | grep failed ● brltty.service loaded failed failed Braille Console Driver ● plymouth-quit-wait.service loaded failed failed Wait for Plymouth Boot Screen to Quit ● systemd-modules-load.service loaded failed failed Load Kernel Modules [sonar@sonar ~]$ systemctl status brltty ● brltty.service - Braille Console Driver Loaded: loaded (/usr/lib/systemd/system/brltty.service; enabled; vendor preset: disabled) Active: failed (Result: signal) since Sat 2016-05-14 20:41:30 UTC; 5min ago Process: 242 ExecStart=/usr/bin/brltty --pid-file=/run/brltty.pid (code=exited, status=0/SUCCESS) Main PID: 299 (code=killed, signal=ABRT) May 14 20:41:27 sonar brltty[242]: BRLTTY 5.3.1 rev unknown [http://brltty.com/] May 14 20:41:27 sonar brltty[242]: BRLTTY 5.3.1 rev unknown [http://brltty.com/] May 14 20:41:28 sonar brltty[299]: directory created: /var/lib/brltty May 14 20:41:28 sonar systemd[1]: Started Braille Console Driver. May 14 20:41:28 sonar brltty[299]: BrlAPI Server: release 0.6.4 May 14 20:41:30 sonar brltty[299]: eSpeak Speech Driver: version 0.3 May 14 20:41:30 sonar brltty[299]: Linux Screen Driver: May 14 20:41:30 sonar systemd[1]: brltty.service: Main process exited, code=killed, status=6/ABRT May 14 20:41:30 sonar systemd[1]: brltty.service: Unit entered failed state. May 14 20:41:30 sonar systemd[1]: brltty.service: Failed with result 'signal'. ```

philm commented

2016-05-14 22:01:03 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Package brltty-5.3.1.77.g59d35f9-1 starts now even before gdm is started. However more than Screen and after a while Screen and so on I was not able to do more. However the new systemd.service seems to work. Also I don't know if pulseaudio needs to be in system mode for this. @coffeeking: please check and give feedback.

*Created by: philmmanjaro* Package **brltty-5.3.1.77.g59d35f9-1** starts now even before **gdm** is started. However more than **Screen** and after a while **Screen** and so on I was not able to do more. However the new **systemd.service** seems to work. Also I don't know if **pulseaudio** needs to be in **system mode** for this. @coffeeking: please check and give feedback.

philm commented

2016-05-15 02:07:42 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

so, hear's where we're at. Since you guys have made pulse audio run in system mode on the live image, brltty starts and speaks. But it seems to loop. It restarts itself every couple of seconds, and so never actually speaks the text console like it's supposed to.So I'm not sure if pulse audio in system mode is causing it or the version of brltty we have, which was just updated.

*Created by: coffeeking* so, hear's where we're at. Since you guys have made pulse audio run in system mode on the live image, brltty starts and speaks. But it seems to loop. It restarts itself every couple of seconds, and so never actually speaks the text console like it's supposed to.So I'm not sure if pulse audio in system mode is causing it or the version of brltty we have, which was just updated.

philm commented

2016-05-15 07:33:22 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

@coffeeking: to test if it is the system mode of pulseaudio please revert my patch on your local profiles. Apply the patch in revers with:

wget https://github.com/manjaro/manjaro-tools-iso-profiles/commit/8f2775c8e192a8e8b9e507e81a8c30c7e967ed31.patch -o system-mode.patch
patch -Rp1 -i system-mode.patch

To readd it patch it normal:

patch -Np1 -i system-mode.patch

The new brltty is starting, but in a loop. The old didn't start at all. See error message we had before. So it is a brltty issue after all, as manual the old started also but never talked the console input. I gave you now all the tools I can give you for testing.

*Created by: philmmanjaro* @coffeeking: to test if it is the **system mode** of **pulseaudio** please revert my patch on your local profiles. Apply the patch in revers with: ``` wget https://github.com/manjaro/manjaro-tools-iso-profiles/commit/8f2775c8e192a8e8b9e507e81a8c30c7e967ed31.patch -o system-mode.patch patch -Rp1 -i system-mode.patch ``` To readd it patch it normal: ``` patch -Np1 -i system-mode.patch ``` The **new brltty** is starting, but in a loop. The old didn't start at all. See error message we had before. So it is a **brltty** issue after all, as manual the old started also but never talked the console input. I gave you now all the tools I can give you for testing.

philm commented

2016-05-15 08:10:41 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

That seems to have helped a little, but not entirely. Now brltty no longer speaks, but it still loops. So Pulse audio being in system mode didn't fix brltty not speaking, not entirely, but it didn't cause it to loop either. That seems to be something with brltty. I've reverted the commit but I haven't pushed yet, in case you want to tweak it. I reverted it in my local copy. I really hope we can figure out a fix, otherwise I'll have to use speakup as a console screen reader, and the brltty people are much easier to work with than the speakup people

*Created by: coffeeking* That seems to have helped a little, but not entirely. Now brltty no longer speaks, but it still loops. So Pulse audio being in system mode didn't fix brltty not speaking, not entirely, but it didn't cause it to loop either. That seems to be something with brltty. I've reverted the commit but I haven't pushed yet, in case you want to tweak it. I reverted it in my local copy. I really hope we can figure out a fix, otherwise I'll have to use speakup as a console screen reader, and the brltty people are much easier to work with than the speakup people

philm commented

2016-05-15 08:13:59 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

one side effect that may be causing the problem. I have the mate profile set to use lightdm as the display manager. However, the build scripts install gdm even though gdm isn't in any of the package lists, and the displaymanager field is set to lightdm in profile.conf. That might be what's contributing to brltty looping. It's the only thing I can think of that's changed other than pulse audio being in system mode, which I've reverted.

*Created by: coffeeking* one side effect that may be causing the problem. I have the mate profile set to use lightdm as the display manager. However, the build scripts install gdm even though gdm isn't in any of the package lists, and the displaymanager field is set to lightdm in profile.conf. That might be what's contributing to brltty looping. It's the only thing I can think of that's changed other than pulse audio being in system mode, which I've reverted.

philm commented

2016-05-15 08:27:54 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

When I've Manjaro 16.06-rc1 out in the open I've some more time to tackle this one here. I used the gnome-edition profile for now. Didn't messed yet with mate. Did you used pacman -Qi gdm to check which package needs gdm?

*Created by: philmmanjaro* When I've Manjaro 16.06-rc1 out in the open I've some more time to tackle this one here. I used the **gnome-edition** profile for now. Didn't messed yet with mate. Did you used `pacman -Qi gdm` to check which package needs gdm?

philm commented

2016-05-15 08:31:00 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

hi
Just checked pacman -Qi gdm, and nothing requires it. It's optional for xscreensaver, but nothing explicitly needs it except for gnome shell, which I don't think is installed on mate, but will double check to be sure. Should I push the reverted pulse audio system mode to the repository until you have more time to look at it?

*Created by: coffeeking* hi Just checked pacman -Qi gdm, and nothing requires it. It's optional for xscreensaver, but nothing explicitly needs it except for gnome shell, which I don't think is installed on mate, but will double check to be sure. Should I push the reverted pulse audio system mode to the repository until you have more time to look at it?

philm commented

2016-05-15 08:51:35 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

ok, I've just built a test image. Gdm is no longer included. But lightdm doesn't start. The exact error is: two services allocated for the same bus org.freedesktop.displaymanager, refusing operation. THis from systemd. I have no idea what to do next, and this has little to do with brltty except that it doesn't seem to be looping. I won't know for sure though until lightdm starts, since it no longer speaks. If I'm logged into a graphical session when it restarts, I get two alert sounds, but I get nothing if I'm outside a graphical session.

*Created by: coffeeking* ok, I've just built a test image. Gdm is no longer included. But lightdm doesn't start. The exact error is: two services allocated for the same bus org.freedesktop.displaymanager, refusing operation. THis from systemd. I have no idea what to do next, and this has little to do with brltty except that it doesn't seem to be looping. I won't know for sure though until lightdm starts, since it no longer speaks. If I'm logged into a graphical session when it restarts, I get two alert sounds, but I get nothing if I'm outside a graphical session.

philm commented

2016-05-15 13:18:50 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: coffeeking

I've pushed the reversion of the pulse audio system wide mode to the repositories by accident. I wasn't intending to but I added some screensavers to our mate edition and it got pushed along with the commit. Do you want me to revert it or leave it until you ahve time to look into it thoroughly after your next gnome release?

*Created by: coffeeking* I've pushed the reversion of the pulse audio system wide mode to the repositories by accident. I wasn't intending to but I added some screensavers to our mate edition and it got pushed along with the commit. Do you want me to revert it or leave it until you ahve time to look into it thoroughly after your next gnome release?

philm commented

2016-05-15 15:17:08 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

All is fine. If needed we can re-add it. Just keep me updated.

*Created by: philmmanjaro* All is fine. If needed we can re-add it. Just keep me updated.

philm commented

2016-05-20 20:44:40 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Is this still an issue?

*Created by: udeved* Is this still an issue?

philm commented

2016-05-21 06:26:55 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Yes, we still didn't managed it ...

*Created by: philmmanjaro* Yes, we still didn't managed it ...

philm commented

2016-05-21 08:32:43 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Does this have to do with a sonar Packages-Live in shared/sonar?

Except for Packages-Desktop in shared/sonar, no other package list is read from there.

*Created by: udeved* Does this have to do with a sonar Packages-Live in shared/sonar? Except for Packages-Desktop in shared/sonar, no other package list is read from there.

philm commented

2016-05-21 09:07:43 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

No, it is a generate issue with systemd, polkit and brltty. I'm currently working on the mate-edition to check if it works there. Nothing to do with our tools. I marked this as optional.

*Created by: philmmanjaro* No, it is a generate issue with **systemd**, **polkit** and **brltty**. I'm currently working on the **mate-edition** to check if it works there. Nothing to do with our tools. I marked this as optional.

Rows
Columns

brltty doesn't talk on the live or installed system #215