Re: UEFI accessibility mandate
Rafael Machado <rafaelrodrigues.machado@...>
Sorry for the delay on the response, to many things happening at the same
I will try to answer e-mails to this thread every Saturday or Sunday
morning at least.
About Andrew's and Laszlo's comments and questions
help implement this feature, but I happy to help work on the architecturePlease let us know what you find out. I probably don''t have the time to
and design for UEFI accessibility on the edk2 mailing lists, and I >>can
also represent what ever we come up with at the UEFI Spec Work Group.
During my MSc I had to study a lot the audio and BIOS architectures. The
idea was to eliminate the first barrier to the creation of a screen reader
for pre-OS environment, that was the lack of some open implementation of
audio control and actions at UEFI. To do that I studied the Intel High
Definition Audio Spec and a lot of UEFI specs to understand better how to
The initial target was to do all this development at OVMF, but as far as I
could get, the sound card is not available to OVMF. as Laszlo mentioned at
this e-mail there are some projects that may help on this, but at the time
I was working on my MSc I didn't find this, so I did everything on a real
system (a ASUS notebook).
It took me 2 years of work, because I didn't know a lot of things and
working on a MSc degree at the same time having a 40hours/week job, being a
father and a husband is not an easy task, but it got to what I was
The evolution of the project was this:
1 - First tests using some registers named "Immediate Registers", that
later I noticed that are not mandatory. This is a simple C Major scale:
2 - Some months later I started to work with the Ring Buffers and DMA
memory access. For the ones that have good years, it's possible to listen
some music behing the noise.
3 - Later, wen I was almost giving up, I noticed that the problem was that
one of my write operations was causing some misunderstanding between the
audio controller and the audio codec. The controller was sending packets
with 16bit depth, but the codec was processing them as 8bit depth
So the conclusion is that doing this at UEFI us much easier that doing at
the OS level.
The reference code, that is just a proof-of-concept, and that has several
things to be improved, can be found here:
Currently it is just an UEFI Application, but we can convert this to UEFI
drivers after some discussion. Everything is released as BDS so companies
can use without IP problems.
Just to give some more information about the need of this kind of solution.
There is a lot of blind people that work with hardware support, so
formatting disk, configuring RAID and booting dual-boot systems is always a
challenge to them. Even set the BIOS clock. How to do that without the
no guideline on how a User Interface (UI) works. If accessibility requiresIt would be hard to have a UEFI mandate for accessibility, given there is
some from of hardware abstraction, like audio, then we could >>likely get
that into the UEFI Spec. What might be possible is an EDK2 reference
implementation of accessibility. Maybe we could use the reference
implementation to write a UEFI white paper on design >>for accessibility? I
there is an open source implementation, and an official design guide this
would make it much easier for advocacy groups to lobby for this feature.
I agree this is the way. Writing a white paper as an official EDK2 papers
is one of my targets since the beginning of my MSc almost 5 years ago.
has a UI for the Full Disk Encryption password. If you press the powerI've got some experience with accessibility as the macOS EFI OS Loader
button quickly 3 times at the disk encryption password prompt
localized voice prompts when you move between UI elements. Since this isaccessibility is enabled and Voice Over gets turned on. You then get
the OS loader all the resources are stored on the disk. You >>quickly run
into a range of challenges since, audio is hard, abstracting audio is hard
(what codec does firmware have to support), Audio files are not small and
firmware is size constrained, the need to localize >>the audio responses
causes even more size issues, the boot options are usually written by an OS
installer so how would firmware know what to call them?
The solution to this would be the porting of some voice synthesizer, so no
audio files would need to be stored. There are some open-source
implementations that are not GPL.
This was described at my MSc as future works that can continue what I have
choose to go to the Moon!" speech sometimes we chose to do things "notI listed a lot of reasons it is hard but as Kennedy stated in his "We
because they are easy, but because they are hard; because that >>goal will
serve to organize and measure the best of our energies and skills, because
that challenge is one that we are willing to accept". If we have a design
that means we can break the problem up into >>smaller parts, and maybe we
can find people that have expertise in that part to build a chunk at a
time. If we could implement the prototype in OVMF that would show how it
works, but run on everyone's >>machines, so that would be really helpful
for demos and design review.
I totally agree. Amazing words that I didn't have heard yet. Thanks!
As far as I could understand, and with Leif's help, some possible future
steps could be (not at this specific order):
- 1) Convert proof-of-concept HDA driver to UEFI driver model with
proper PCI discovery.
- 2) Design a prototype EFI_AUDIO_OUTPUT_PROTOCOL, rework driver
to produce this and application to discover and consume it.
- 3) Implement a USB Audio Class driver also
producing EFI_AUDIO_OUTPUT_PROTOCOL and ensure test application
- 4) Separate controller and codec code by creating
an EFI_AUDIO_CODEC_PROTOCOL, implement this in HDA driver, and separate out
the codec support into individual drivers.
- 5) Prototype audio output additions to HII. (using pre-recorder audio
- 6) Porting of some voice synthesizer to UEFI. (eliminating the need of
Beyond this, there are other things we should look at adding, like
- Audio input additions to HII.
It's a lot of work, but I accept the challenge.
It may take a long time, but it is possible.
I am still trying to find some time to finish the translation of my thesis
I wrote everything in Portuguese because there was not material about UEFI
to the Brazilian audience, and another target I have is to show companies
that we have people that can work at this kind of projects in Brazil,
bringing this kind of development to south america. (Yes, I have
complicated target, but I like the challenge :) )
Thanks and Regards
Rafael R. Machado
Em qui, 19 de set de 2019 às 14:45, Laszlo Ersek <firstname.lastname@example.org>
On 09/18/19 19:57, Andrew Fish wrote:Rafael,Somewhat related, in April there was a thread on virtio-dev that