Description of problem: Brltty package is not installed for netinst, so it is not possible to install by using Braille terminal. Version-Release number of selected component (if applicable): anaconda-29.15-1.fc29 How reproducible: Always Steps to Reproduce: 1. Switch to shell 2. Run brltty 3. Actual results: brltty is not installed Expected results: brltty installed Additional info: Also I think it would be great to have GUI option and maybe kickstart options for starting brltty to ease the process. For liveinst it's possible to run orca and/or brltty in separate terminal, it's not optimal, but it works.
(In reply to Jaroslav Škarvada from comment #0) > Additional info: > Also I think it would be great to have GUI option and maybe kickstart > options for starting brltty to ease the process. For liveinst it's possible > to run orca and/or brltty in separate terminal, it's not optimal, but it > works. Well, for liveinst it works, but I think it kills the purpose of assistive technology, because it's nearly impossible to switch the assistive technology on for person with disabilities. I propose: - install brltty - run brltty (service) - run orca maybe with speech output disabled - run the liveinst In such case, the brltty should autodetect connected Braille terminals and the Braille output should work without any other work.
I was told that e.g. in Debian the installer supports Braille terminals out of the box.
Thanks for this report. We will look onto this.
Is there any reason why not to enable brltty service for every installation and create a special kickstart option for that? And similar question what is the purpose of having the GUI option? It would be hard to activate this option for somebody who needs it.
(In reply to Jiri Konecny from comment #4) > Is there any reason why not to enable brltty service for every installation > and create a special kickstart option for that? > I don't see any problem with the brltty service running for the installer. It should be harmless and use low resources. It by default autodetects Braille terminals, so it should work out of the box. The brltty service uses systemd presets, thus it should be enough to enable it in the presets used for the creation of the installer image. > And similar question what is the purpose of having the GUI option? It would > be hard to activate this option for somebody who needs it. I think it could be done similar way as Gnome/GDM did - they have GUI option for switching Orca on/off. This is good for people with visual difficulties who are not completely blind. There is also hotkey support (Alt + Super + S) which starts Orca with the Braille enabled. It runs "orca --disable main-window,splash-window --enable speech,braille". If brltty service is running then everything works as expected.
I think this can be even improved (e.g. to work similarly like in Debian). If user enables Braille during the install I propose Anaconda to add the Braille package into the installation and enable the brltty service. Then the user will have working Braille terminal out of the box.
(In reply to Jaroslav Škarvada from comment #6) > I think this can be even improved (e.g. to work similarly like in Debian). > If user enables Braille during the install I propose Anaconda to add the > Braille package into the installation and enable the brltty service. Then > the user will have working Braille terminal out of the box. We already even have a mechanism[0] for stuff like this, which is used to add packages to the install transaction when Anaconda detect they will be needed (realm related packages when joing a domain, virtualisation related packages when we detect virtualization is used, etc.). Of course this currently works only with package based payloads, but if the live system already has the accessibility packages installed, they will also be part of the installed system. [0] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/__init__.py#L172
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Moving to rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Moving to f34.
Jaroslav, I have a few questions: - I have trouble understanding what would be actually enabled. "Reading" the TUI in tty1? If this depends on Orca to produce output, then there's no point, boot.iso does not have the necessary parts to make it work. - Is installing the brltty package and starting the systemd unit enough? - For Live CD (a serparate use case), you probably want to run the service by default, correct?
(In reply to Vladimír Slávik from comment #15) > Jaroslav, I have a few questions: > > - I have trouble understanding what would be actually enabled. "Reading" the > TUI in tty1? If this depends on Orca to produce output, then there's no > point, boot.iso does not have the necessary parts to make it work. > > - Is installing the brltty package and starting the systemd unit enough? > > - For Live CD (a serparate use case), you probably want to run the service > by default, correct? Hi Vladimír, thanks for looking at it. It depends what do you want to support. For TUI it should be enough to install brltty and start it. Then brltty should interface with the console driver. With the default configuration it also tries to auto detect connected USB and bluetooth braille terminals. For the GUI you need either: a) install brltty-at-spi2 package, enable at-spi2 on the desktop (at-spi2 requires D-bus) and start brltty with the following environment variable BRLTTY_SCREEN_DRIVER=a2 or run brltty manually as 'brltty -x a2' (in such case you don't need to use the brltty systemd service), or b) start brltty service and run orca, in such case orca will communicate with the brltty through the brlapi, the user has to be in the 'brlapi' group Usually b) is recommended, other installers usually has the hot key set to start the orca.
A quick test ruled out "just dnf install brltty while building boot.iso": - Having alsa-libs does not make sense to me, unless sound is expected to be made somehow. There isn't anything sound-related on netinst, so that won't do anything. To clarify, this will be a waste of space, and I think it might also be a problem due to dependency creep potential. Maybe this part can be somehow shaved off? - libicu seems to be 33 MB after installation. The rest then raises the requirement to 46 MB anyway. That's such a large slice of the space budget (700MB-ish) that I can't see how that could ever fit. Can brltty work without some of these things, and if so, how? (On the installer side, we boot.iso builds are controlled by lorax templates, and these can remove specific things after installing packages.)
(In reply to Vladimír Slávik from comment #17) > A quick test ruled out "just dnf install brltty while building boot.iso": > > - Having alsa-libs does not make sense to me, unless sound is expected to be > made somehow. There isn't anything sound-related on netinst, so that won't > do anything. To clarify, this will be a waste of space, and I think it might > also be a problem due to dependency creep potential. Maybe this part can be > somehow shaved off? > > - libicu seems to be 33 MB after installation. The rest then raises the > requirement to 46 MB anyway. That's such a large slice of the space budget > (700MB-ish) that I can't see how that could ever fit. > > Can brltty work without some of these things, and if so, how? > > (On the installer side, we boot.iso builds are controlled by lorax > templates, and these can remove specific things after installing packages.) It uses alsa for speech synthesis and tone notifications. It can be built without alsa and also without the icu. The icu is used for unicode. But I don't know how it will work with some exotic languages (characters) without icu. I could build some stripped down version, e.g. brltty-minimal, or maybe some special spin with the installer could be created. Or what about some special parameter or hotkey which would download, install and run brltty from the internet as soon as possible during the installation? I think it maybe worth thinking about it. I was asked about this feature during some openhouse event and it was also told me that Fedora installer is behind its competitors here, that's why I opened this RFE.
I agree it's definitely worth it, for multiple reasons. However the criteria is that netinst fits onto a CD, and that's it. How much work would it be to build this minimal version? I can build the whole installation image, but ideally I'd have a RPM to plug in, not raw binaries... Perhaps it could be better to invert the process and first build an "anaconda" brltty with pretty much nothing, then add things as needed. Looking through the dependencies and configure options, I see eg. polkit. We run everything as root, so perhaps that's another thing to drop. etc.
Please keep in mind that the boot.iso is supposed to be small, so if this adds a bunch of new dependencies I'd rather see this kind of support in the livecd, or in a custom spin.
(In reply to Vladimír Slávik from comment #19) > I agree it's definitely worth it, for multiple reasons. However the criteria > is that netinst fits onto a CD, and that's it. > > How much work would it be to build this minimal version? I can build the > whole installation image, but ideally I'd have a RPM to plug in, not raw > binaries... > > Perhaps it could be better to invert the process and first build an > "anaconda" brltty with pretty much nothing, then add things as needed. > Looking through the dependencies and configure options, I see eg. polkit. We > run everything as root, so perhaps that's another thing to drop. etc. I tried to create stripped down version of the brltty [1]. It's provided by the subpackage brltty-minimal. The binary is named brltty-minimal. There is no systemd service and no brlapi key preset, but it should be possible to run it manually as (-N is to disalbe brlapi, i.e. it will not work with orca, but the brlapi key can be generated if needed): brltty-minimal -N The brltty-minimal package conflicts with the brltty package, but I think it shouldn't block brltty-minimal to be in the image and the installer installing brltty into the target root filesystem. I built the package for rawhide (f35). Feel free to test, feedback welcome. [1] https://src.fedoraproject.org/rpms/brltty/c/387902cb8d235deb3fe1ced6e812b9bbdb8cd4b0?branch=rawhide
Thank you! Unfortunately, I can't install this package: dnf install brltty-minimal Koji 2.8 MB/s | 57 MB 00:20 Last metadata expiration check: 0:00:31 ago on Tue Jun 1 07:30:59 2021. Error: Problem: package brltty-minimal-6.3-7.fc35.x86_64 requires brltty(x86-64) = 6.3-7.fc35, but none of the providers can be installed - package brltty-6.3-7.fc35.x86_64 conflicts with brltty-minimal provided by brltty-minimal-6.3-7.fc35.x86_64 - package brltty-minimal-6.3-7.fc35.x86_64 conflicts with brltty provided by brltty-6.3-7.fc35.x86_64 - conflicting requests (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) Given that all the usual machinery I'd use relies on dnf, I could not get past this point.
(In reply to Vladimír Slávik from comment #22) > Thank you! Unfortunately, I can't install this package: > > dnf install brltty-minimal > Koji 2.8 MB/s | > 57 MB 00:20 > Last metadata expiration check: 0:00:31 ago on Tue Jun 1 07:30:59 2021. > Error: > Problem: package brltty-minimal-6.3-7.fc35.x86_64 requires brltty(x86-64) = > 6.3-7.fc35, but none of the providers can be installed > - package brltty-6.3-7.fc35.x86_64 conflicts with brltty-minimal provided > by brltty-minimal-6.3-7.fc35.x86_64 > - package brltty-minimal-6.3-7.fc35.x86_64 conflicts with brltty provided > by brltty-6.3-7.fc35.x86_64 > - conflicting requests > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages) > > Given that all the usual machinery I'd use relies on dnf, I could not get > past this point. Please try brltty-minimal-6.3-8.fc35.
Thank you, the -8 build works nicely. The good news is that size of the image did not go up as much as I expected! It's about +2-3 MB. (Actually, brltty-minimal gives me a larger ISO than brltty... might be churn in the repositories though.) Here is the boot.iso with "full" brltty automatically enabled: https://vladimirslavik.fedorapeople.org/vs-boot-bf.iso And this is the change: https://github.com/VladimirSlavik/anaconda/commit/7b79eab55b4fda76e29ff25fcd52643b657e6989 How do I check that it does what it should? I didn't find any hints on how to debug this without an actual device.
So, 20 days later, I think I need an actual device to verify this, or a bugfix. I have a VM that is started directly via qemu, and has a "virtual braille device". (KVM and its tooling do not consider this kind of device so I must do it one layer lower in qemu.) What should happen is that brltty in the guest sees the device and talks to it. However, the device only passes stuff to brlapi on the host, and that needs a correctly configured brltty on the host. That requires somewhere to send things to, on the host. I have no refreshable braille display, so I configured espeak-ng instead. However that throws a ton of AVC denials from speech-driver, and then does nothing. Running setenforce 0 did not help the "nothing" part, either. The messages are almost identical on both f32 and rawhide, so it seems nobody uses this... (Other audio on the host is fine, as well as direct espeak-ng use.) Not sure how to proceed. I have asked on the brltty mailing list about some kind of debug output, but the selinux issue is probably independent of it.
Sorry for delay, I was on some prio stuff. Unfortunately, I don't have physical braille display for testing at the moment, but you could use the xw emulator. Unfortunately it requires spawning the brltty different way, or you can alter the brltty configuration file. For the testing use two machines, one running the xw braille terminal emulator under X and the other running the the anaconda installer. On the machine which will run the emulator unfirewall port 4101 and under X run the following command: $ brltty -b xw -x no -A auth=none,host=LISTEN_IP:0 Legend: -b xw : the X braille terminal emulator, -x no : no screen driver, -A auth=none,host=LISTEN_IP:0 : no authorization, i.e. no brlapi key, just for testing, LISTEN_IP is the IP/hostname of the local interface where to listen for incoming brlapi connections, 0 is the port + 4101, i.e. port 4101 in this case, it has to be unfirewalled. On the machine running the anaconda run the following command by anaconda: # brltty -b ba -B auth=none,host=CONNECT_IP:0 Legend: -b ba : braille API driver, normally without it it should automatically find the physical braille terminal connected to the machine, -B auth=none,host=CONNECT_IP:0 : no authorization, i.e. no brlapi key, just for testing, CONNECT_IP is the IP/hostname of the remote machine where the xw emulator is running, 0 is the port + 4101, i.e. port 4101 in this case.
(In reply to Jaroslav Škarvada from comment #26) > Sorry for delay, I was on some prio stuff. Unfortunately, I don't have > physical braille display for testing at the moment, but you could use the xw > emulator. Unfortunately it requires spawning the brltty different way, or > you can alter the brltty configuration file. > > For the testing use two machines, one running the xw braille terminal > emulator under X and the other running the the anaconda installer. > > On the machine which will run the emulator unfirewall port 4101 and under X > run the following command: > $ brltty -b xw -x no -A auth=none,host=LISTEN_IP:0 > > Legend: -b xw : the X braille terminal emulator, -x no : no screen driver, > -A auth=none,host=LISTEN_IP:0 : no authorization, i.e. no brlapi key, just > for testing, LISTEN_IP is the IP/hostname of the local interface where to > listen for incoming brlapi connections, 0 is the port + 4101, i.e. port 4101 > in this case, it has to be unfirewalled. > > On the machine running the anaconda run the following command by anaconda: > # brltty -b ba -B auth=none,host=CONNECT_IP:0 > > Legend: -b ba : braille API driver, normally without it it should > automatically find the physical braille terminal connected to the machine, > -B auth=none,host=CONNECT_IP:0 : no authorization, i.e. no brlapi key, just > for testing, CONNECT_IP is the IP/hostname of the remote machine where the > xw emulator is running, 0 is the port + 4101, i.e. port 4101 in this case. Or maybe you could also add kickstart option allowing starting it this way with the customized IP. I.e. it could be useful in cases where you will run anaconda installer on some virtual machine while you will have braille terminal connected to the physical machine. In such case it could be useful to use the brlapi key authorization, e.g. kickstart option which will write /etc/brlapi.key or any other file with the key and start brltty with the: -B auth=KEYFILE,host=CONNECT_IP:0
Thank you, the steps from comment 26 worked exactly as you said, connecting to a brltty instance on another machine. QEMU should be able to present a virtualized Baum device using brlapi of the host. Running that with brltty-xw should give me a complete system to test my custom-built media. However I can't get this to work, qemu always fails its braille thing cryptically before even starting (unpausing) the VM. --- What will probably happen is that we'll merge the initial change that merely adds brltty in default configuration: https://github.com/rhinstaller/anaconda/pull/3434 Once it's in official builds, I could ask <somebody> to do some testing. Based on that, we will see if this is useful, or how much flexibility would be needed to run this. Kickstart and boot options can come then.
brltty is now officially a dependency of anaconda-35.22-1 (tagged yesterday). It should be in the next nightly build of Rawhide. However, I do not consider this bug resolved: - Nothing has been verified in terms of the actual user story: "As a blind user, I want to install Fedora to my computer using my braille hardware, so that I get Fedora without help of others." An assumption is that the default config leads to some braille output in a large enough % of cases. In the next weeks, I hope to get access to actual hardware and test this. - What we have so far is text mode only. Ideally I'd get the driver for reading stuff from X to work, and GUI would become "readable" too. I am not sure what that needs, probably at least at-spi... - It might be useful to actually control whether brltty should be started, and certainly to configure it. I think a boot option would be best. Out of scope for this bug / project: - Kickstart commands to install brltty on target system.
(In reply to Vladimír Slávik from comment #29) > brltty is now officially a dependency of anaconda-35.22-1 (tagged > yesterday). It should be in the next nightly build of Rawhide. > > However, I do not consider this bug resolved: > > - Nothing has been verified in terms of the actual user story: "As a blind > user, I want to install Fedora to my computer using my braille hardware, so > that I get Fedora without help of others." An assumption is that the default > config leads to some braille output in a large enough % of cases. In the > next weeks, I hope to get access to actual hardware and test this. > Where get you the terminal? We are interested in getting/buying one. > - What we have so far is text mode only. Ideally I'd get the driver for > reading stuff from X to work, and GUI would become "readable" too. I am not > sure what that needs, probably at least at-spi... > at-spi2 (at-spi is deprecated) and configuration changes. Or orca, it communicates with the brltty through the API, in such case the at-spi2 brltty driver may be not needed, and it could work with the default config - just starting the orca.
> Where get you the terminal? We are interested in getting/buying one. Ha, I didn't! I saw a person with white cane walk into the company building, thought "there's a potential tester", ran after them and started a conversation. They said they would be happy to help test this, once <something> is over, and they have the hardware in the office. > at-spi2 (at-spi is deprecated) Sorry, I don't know this well, so forgot the number. > Or orca, it communicates with the brltty through the API, in such case the at-spi2 brltty driver may be not needed, and it could work with the default config - just starting the orca. I may be wrong about this, but orca is mainly a speaking thing, so without audio it would be mostly dead weight.
FEDORA-2021-c55ce41cef has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c55ce41cef
Proposed as a Freeze Exception for 35-beta by Fedora user m4rtink using the blocker tracking app because: This adds support for using Braille terminal to the boot.iso, improving usability for blind and vision impaired users.
FEDORA-2021-c55ce41cef has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c55ce41cef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c55ce41cef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/401 , marking accepted.
FEDORA-2021-c55ce41cef has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
The bug is closed because it was used for the exception, but the issues/plans outlined above remain. I am close to testing the current setup, then we'll know what else is needed.
We can re-open it and drop the blocker/FE tags.
Actually it's fine to keep this closed. The other plans don't even need a bug.