Good news about the state of accessibility in the BIOS!
## Preamble
On my [ideas page](/ideas/), I have always had up the idea of an accessibility layer for blind people to be able to use their BIOS.
Although it targets a very small percentage of the population,
computer programming is often at least a hobby of visually imapired individuals as it is (mostly) a text-based job:
You write code in plain text, then run it to get either plain text or some kind of HTML output.
Mostly an accessible career for those who cannot see.
That said, there has always been an issue with low-level computer infrastructure (i.e. the BIOS/UEFI).
These menus---which let you edit your boot order, RAM timings, CPU and GPU overclocking and sometimes even fan speed---they were completely inaccessible to those who could not see them.
Well, until... soon. I had a talk with one of the big bois working on EDK2, the UEFI implementation which is used by most motherboard vendors to create their firmware.
I thought I would share the info I understand, and the conversation in full.
## News
Here is what I know:
1. This year, the GSoC (Google Summer of Code) project had [a submission of Ethin Probst](https://summerofcode.withgoogle.com/projects/#6499615798460416) to implement VirtIO audio drivers for EDK2.
2. [QEMU](https://qemu.org), the emulator that was chosen to test for this project does not have VirtIO support (yet). I haven't found info on when this will be done.
3. Because of 2, Ethin and his mentors for his project, Ray Ni and Leif Lindholm decided to first implement USB-dongle audio support first, as this is a) supported in QEMU, and b) is good enough to start squashing bugs at the audio level.
4. Because GSoC is usually over around September, there will likely be some more news coming soon!
## The IRC Chat
Here is the log of the IRC chat for anyone who is interested in anything I might have missed:
<preclass="terminal">
tait_dot_tech: Hello there, I'm new to IRC so just checking my messages are coming through.
tait_dot_tech: Looks light it's alright. Ok so I have a question: does anyone know of an active project looking at making UEFI accessible to the blind (i.e. speec) [sic] from within the UEFI environment? Main concern is having blind users be able to boot Linux USBs (I know, very niche thing), but depending on how good it is, could potentially be used to allow blind individuals to change their overclocking,
tait_dot_tech: hardware RAID, boot order, RAM timings, etc. all on their own. Just wondering if there is any project doing this? I have tried my best to find anything, and am just trying not to duplicate effort. Thanks :)
leiflindholm: tait_dot_tech: we have a google summer of code project running this year, prototyping a standard for audio output. To hopefully be added to the UEFI specification in the future.
leiflindholm: once we have a standard for audio output, we can work on adding support for audio output to the Human Interface Infrastructure
leiflindholm: which is the thing that lets menus be loaded and displayed independent of specific graphical implementation
tait_dot_tech: Oh wow! Glad to hear there is progress on this! Is there a link to the Google summer of code project, or anything else where I can keep tabs?
leiflindholm: tait_dot_tech: there isn't much yet, we're only on week 3 of GSoC.
leiflindholm: https://summerofcode.withgoogle.com/projects/#6499615798460416 is the link if it's something you want to point others to, but any discussion/reporting is likely to hapen [sic] on our mailing lists
tait_dot_tech: By "our" mailing list, do you mean GSoC, or Edk2?
leiflindholm: edk2
leiflindholm: although, on average, at least 99% of edk2-devel will *not* be about audio support
leiflindholm: When we have anything interesting to say, we'll also post to edk2-discuss/edk2-announce
tait_dot_tech: Sweet! I'll join that one just in case! I'd be happy to test anything in beta-ish state and report back with any device I can get my hands on. Is that the right list to watch for hepling test it out?
leiflindholm: I'd say so.
leiflindholm: The original plan was to start with wirtio [sic] audio support, so anyone could help out anywhere, but that support is not yet upstream in qemu. So for now we're working on an [sic] USB audio class driver. That will certainly be useful to have more people testing with different equipment once we have something working.
tait_dot_tech: Ahh! So if I want to test, I should get a USB audio dongle. Gotcha! Thank you so much! You've been super helpful!
leiflindholm: np :)
</pre>
Things are (slowly) looking up for audio (and eventually screen-reader support) in UEFI!
Phew! Glad I'm not the only one thinking about this!
<timedatetime="21-06-21"class="post-date">Monday, June 21 2021</time>
</header>
<hr>
<p>Good news about the state of accessibility in the BIOS!</p>
<h2id="preamble">Preamble</h2>
<p>On my <ahref="/ideas/">ideas page</a>, I have always had up the idea of an accessibility layer for blind people to be able to use their BIOS.
Although it targets a very small percentage of the population,
computer programming is often at least a hobby of visually imapired individuals as it is (mostly) a text-based job:
You write code in plain text, then run it to get either plain text or some kind of HTML output.
Mostly an accessible career for those who cannot see.
That said, there has always been an issue with low-level computer infrastructure (i.e. the BIOS/UEFI).
These menus—which let you edit your boot order, RAM timings, CPU and GPU overclocking and sometimes even fan speed—they were completely inaccessible to those who could not see them.
Well, until… soon. I had a talk with one of the big bois working on EDK2, the UEFI implementation which is used by most motherboard vendors to create their firmware.
I thought I would share the info I understand, and the conversation in full.</p>
<h2id="news">News</h2>
<p>Here is what I know:</p>
<ol>
<li>This year, the GSoC (Google Summer of Code) project had <ahref="https://summerofcode.withgoogle.com/projects/#6499615798460416">a submission of Ethin Probst</a> to implement VirtIO audio drivers for EDK2.</li>
<li><ahref="https://qemu.org">QEMU</a>, the emulator that was chosen to test for this project does not have VirtIO support (yet). I haven’t found info on when this will be done.</li>
<li>Because of 2, Ethin and his mentors for his project, Ray Ni and Leif Lindholm decided to first implement USB-dongle audio support first, as this is a) supported in QEMU, and b) is good enough to start squashing bugs at the audio level.</li>
<li>Because GSoC is usually over around September, there will likely be some more news coming soon!</li>
</ol>
<h2id="the-irc-chat">The IRC Chat</h2>
<p>Here is the log of the IRC chat for anyone who is interested in anything I might have missed:</p>
<preclass="terminal">
tait_dot_tech: Hello there, I'm new to IRC so just checking my messages are coming through.
tait_dot_tech: Looks light it's alright. Ok so I have a question: does anyone know of an active project looking at making UEFI accessible to the blind (i.e. speec) [sic] from within the UEFI environment? Main concern is having blind users be able to boot Linux USBs (I know, very niche thing), but depending on how good it is, could potentially be used to allow blind individuals to change their overclocking,
tait_dot_tech: hardware RAID, boot order, RAM timings, etc. all on their own. Just wondering if there is any project doing this? I have tried my best to find anything, and am just trying not to duplicate effort. Thanks :)
leiflindholm: tait_dot_tech: we have a google summer of code project running this year, prototyping a standard for audio output. To hopefully be added to the UEFI specification in the future.
leiflindholm: once we have a standard for audio output, we can work on adding support for audio output to the Human Interface Infrastructure
leiflindholm: which is the thing that lets menus be loaded and displayed independent of specific graphical implementation
tait_dot_tech: Oh wow! Glad to hear there is progress on this! Is there a link to the Google summer of code project, or anything else where I can keep tabs?
leiflindholm: tait_dot_tech: there isn't much yet, we're only on week 3 of GSoC.
leiflindholm: https://summerofcode.withgoogle.com/projects/#6499615798460416 is the link if it's something you want to point others to, but any discussion/reporting is likely to hapen [sic] on our mailing lists
tait_dot_tech: By "our" mailing list, do you mean GSoC, or Edk2?
leiflindholm: edk2
leiflindholm: although, on average, at least 99% of edk2-devel will *not* be about audio support
leiflindholm: When we have anything interesting to say, we'll also post to edk2-discuss/edk2-announce
tait_dot_tech: Sweet! I'll join that one just in case! I'd be happy to test anything in beta-ish state and report back with any device I can get my hands on. Is that the right list to watch for hepling test it out?
leiflindholm: I'd say so.
leiflindholm: The original plan was to start with wirtio [sic] audio support, so anyone could help out anywhere, but that support is not yet upstream in qemu. So for now we're working on an [sic] USB audio class driver. That will certainly be useful to have more people testing with different equipment once we have something working.
tait_dot_tech: Ahh! So if I want to test, I should get a USB audio dongle. Gotcha! Thank you so much! You've been super helpful!
leiflindholm: np :)
</pre>
<p>Things are (slowly) looking up for audio (and eventually screen-reader support) in UEFI!
Phew! Glad I’m not the only one thinking about this!</p>
<p>Happy UEFI hacking :)</p>
</article>
</main>
<hr>
<footer>
This page is mirrored on <ahref="https://beta.tait.tech/2021/06/21/uefi-audio/">beta.tait.tech</a>.
<?xml version="1.0" encoding="utf-8"?><feedxmlns="http://www.w3.org/2005/Atom"><generatoruri="https://jekyllrb.com/"version="4.1.1">Jekyll</generator><linkhref="http://localhost:4000/feed.xml"rel="self"type="application/atom+xml"/><linkhref="http://localhost:4000/"rel="alternate"type="text/html"/><updated>2021-08-31T21:19:20-06:00</updated><id>http://localhost:4000/feed.xml</id><entry><titletype="html">Idea For A VPN Service</title><linkhref="http://localhost:4000/2021/08/31/vpns-api/"rel="alternate"type="text/html"title="Idea For A VPN Service"/><published>2021-08-31T00:00:00-06:00</published><updated>2021-08-31T00:00:00-06:00</updated><id>http://localhost:4000/2021/08/31/vpns-api</id><contenttype="html"xml:base="http://localhost:4000/2021/08/31/vpns-api/"><p>Recently I’ve been thinking about starting a VPN service.
<?xml version="1.0" encoding="utf-8"?><feedxmlns="http://www.w3.org/2005/Atom"><generatoruri="https://jekyllrb.com/"version="4.1.1">Jekyll</generator><linkhref="http://localhost:4000/feed.xml"rel="self"type="application/atom+xml"/><linkhref="http://localhost:4000/"rel="alternate"type="text/html"/><updated>2021-08-31T21:20:13-06:00</updated><id>http://localhost:4000/feed.xml</id><entry><titletype="html">Idea For A VPN Service</title><linkhref="http://localhost:4000/2021/08/31/vpns-api/"rel="alternate"type="text/html"title="Idea For A VPN Service"/><published>2021-08-31T00:00:00-06:00</published><updated>2021-08-31T00:00:00-06:00</updated><id>http://localhost:4000/2021/08/31/vpns-api</id><contenttype="html"xml:base="http://localhost:4000/2021/08/31/vpns-api/"><p>Recently I’ve been thinking about starting a VPN service.
This service has some interesting requirements that I have never seen a VPN service do before, so I’d like to put down my thoughts as to what might be sensible for a centralized yet encrypted* VPN service.</p>
<p>I would license all the code and scripts under the AGPLv3.
@ -180,7 +180,60 @@ Doesn’t really matter which one, unless you’re a nerd—for your average per
<p>Anyway, I think I’ve rambled on long enough about VPNs and my crazy ideas, so I’m going to leave this one for now.</p>
<p>Happy VPN hacking :D</p></content><author><name></name></author><summarytype="html">Recently I’ve been thinking about starting a VPN service. This service has some interesting requirements that I have never seen a VPN service do before, so I’d like to put down my thoughts as to what might be sensible for a centralized yet encrypted* VPN service.</summary></entry><entry><titletype="html">Pinebook Pro, The Ultimate ARM Laptop</title><linkhref="http://localhost:4000/2021/06/02/pinebook-pro/"rel="alternate"type="text/html"title="Pinebook Pro, The Ultimate ARM Laptop"/><published>2021-06-02T00:00:00-06:00</published><updated>2021-06-02T00:00:00-06:00</updated><id>http://localhost:4000/2021/06/02/pinebook-pro</id><contenttype="html"xml:base="http://localhost:4000/2021/06/02/pinebook-pro/"><p>I recently got my Pinebook Pro.
<p>Happy VPN hacking :D</p></content><author><name></name></author><summarytype="html">Recently I’ve been thinking about starting a VPN service. This service has some interesting requirements that I have never seen a VPN service do before, so I’d like to put down my thoughts as to what might be sensible for a centralized yet encrypted* VPN service.</summary></entry><entry><titletype="html">UEFI Audio Protocol &amp; UEFI BIOS Accessibility</title><linkhref="http://localhost:4000/2021/06/21/uefi-audio/"rel="alternate"type="text/html"title="UEFI Audio Protocol &amp; UEFI BIOS Accessibility"/><published>2021-06-21T00:00:00-06:00</published><updated>2021-06-21T00:00:00-06:00</updated><id>http://localhost:4000/2021/06/21/uefi-audio</id><contenttype="html"xml:base="http://localhost:4000/2021/06/21/uefi-audio/"><p>Good news about the state of accessibility in the BIOS!</p>
<p>On my <a href="/ideas/">ideas page</a>, I have always had up the idea of an accessibility layer for blind people to be able to use their BIOS.
Although it targets a very small percentage of the population,
computer programming is often at least a hobby of visually imapired individuals as it is (mostly) a text-based job:
You write code in plain text, then run it to get either plain text or some kind of HTML output.
Mostly an accessible career for those who cannot see.
That said, there has always been an issue with low-level computer infrastructure (i.e. the BIOS/UEFI).
These menus—which let you edit your boot order, RAM timings, CPU and GPU overclocking and sometimes even fan speed—they were completely inaccessible to those who could not see them.
Well, until… soon. I had a talk with one of the big bois working on EDK2, the UEFI implementation which is used by most motherboard vendors to create their firmware.
I thought I would share the info I understand, and the conversation in full.</p>
<h2 id="news">News</h2>
<p>Here is what I know:</p>
<ol>
<li>This year, the GSoC (Google Summer of Code) project had <a href="https://summerofcode.withgoogle.com/projects/#6499615798460416">a submission of Ethin Probst</a> to implement VirtIO audio drivers for EDK2.</li>
<li><a href="https://qemu.org">QEMU</a>, the emulator that was chosen to test for this project does not have VirtIO support (yet). I haven’t found info on when this will be done.</li>
<li>Because of 2, Ethin and his mentors for his project, Ray Ni and Leif Lindholm decided to first implement USB-dongle audio support first, as this is a) supported in QEMU, and b) is good enough to start squashing bugs at the audio level.</li>
<li>Because GSoC is usually over around September, there will likely be some more news coming soon!</li>
<p>Here is the log of the IRC chat for anyone who is interested in anything I might have missed:</p>
<pre class="terminal">
tait_dot_tech: Hello there, I'm new to IRC so just checking my messages are coming through.
tait_dot_tech: Looks light it's alright. Ok so I have a question: does anyone know of an active project looking at making UEFI accessible to the blind (i.e. speec) [sic] from within the UEFI environment? Main concern is having blind users be able to boot Linux USBs (I know, very niche thing), but depending on how good it is, could potentially be used to allow blind individuals to change their overclocking,
tait_dot_tech: hardware RAID, boot order, RAM timings, etc. all on their own. Just wondering if there is any project doing this? I have tried my best to find anything, and am just trying not to duplicate effort. Thanks :)
leiflindholm: tait_dot_tech: we have a google summer of code project running this year, prototyping a standard for audio output. To hopefully be added to the UEFI specification in the future.
leiflindholm: once we have a standard for audio output, we can work on adding support for audio output to the Human Interface Infrastructure
leiflindholm: which is the thing that lets menus be loaded and displayed independent of specific graphical implementation
tait_dot_tech: Oh wow! Glad to hear there is progress on this! Is there a link to the Google summer of code project, or anything else where I can keep tabs?
leiflindholm: tait_dot_tech: there isn't much yet, we're only on week 3 of GSoC.
leiflindholm: https://summerofcode.withgoogle.com/projects/#6499615798460416 is the link if it's something you want to point others to, but any discussion/reporting is likely to hapen [sic] on our mailing lists
tait_dot_tech: By "our" mailing list, do you mean GSoC, or Edk2?
leiflindholm: edk2
leiflindholm: although, on average, at least 99% of edk2-devel will *not* be about audio support
leiflindholm: When we have anything interesting to say, we'll also post to edk2-discuss/edk2-announce
tait_dot_tech: Sweet! I'll join that one just in case! I'd be happy to test anything in beta-ish state and report back with any device I can get my hands on. Is that the right list to watch for hepling test it out?
leiflindholm: I'd say so.
leiflindholm: The original plan was to start with wirtio [sic] audio support, so anyone could help out anywhere, but that support is not yet upstream in qemu. So for now we're working on an [sic] USB audio class driver. That will certainly be useful to have more people testing with different equipment once we have something working.
tait_dot_tech: Ahh! So if I want to test, I should get a USB audio dongle. Gotcha! Thank you so much! You've been super helpful!
leiflindholm: np :)
</pre>
<p>Things are (slowly) looking up for audio (and eventually screen-reader support) in UEFI!
Phew! Glad I’m not the only one thinking about this!</p>
<p>Happy UEFI hacking :)</p></content><author><name></name></author><summarytype="html">Good news about the state of accessibility in the BIOS!</summary></entry><entry><titletype="html">Pinebook Pro, The Ultimate ARM Laptop</title><linkhref="http://localhost:4000/2021/06/02/pinebook-pro/"rel="alternate"type="text/html"title="Pinebook Pro, The Ultimate ARM Laptop"/><published>2021-06-02T00:00:00-06:00</published><updated>2021-06-02T00:00:00-06:00</updated><id>http://localhost:4000/2021/06/02/pinebook-pro</id><contenttype="html"xml:base="http://localhost:4000/2021/06/02/pinebook-pro/"><p>I recently got my Pinebook Pro.
It was more expensive than I was expecting, coming in at (including shipping and handling) C$335.
I always forget the exchange rate and assume it’s similar to the U.S. dollar, but it never is, haha!
Anyway, this is just my first impressions and what I did to fix a few issues.</p>
@ -956,94 +1009,4 @@ It rewarded those who had unique interests and an ability to sell others on thei
<p>Although it’s nice to have a course where these goals align here and there, anyone who has been to collage or university can tell you that is far from the norm.</p>
<p>On the other hand, I never would have started this site if it wasn’t for that class alone.
So I thank you, Kitty Wong, for getting me started running my own “research blog” (?)</p></content><author><name></name></author><summarytype="html">Curiosity is fundamental to a deep understanding of any subject. Masters, Ph.Ds, and other fancy name suffixes will never help you if you don’t have the spirit of curiosity burning inside of you.</summary></entry><entry><titletype="html">Minesweeper Bomb Generation And Tile Revealing</title><linkhref="http://localhost:4000/2020/09/12/minesweeper/"rel="alternate"type="text/html"title="Minesweeper Bomb Generation And Tile Revealing"/><published>2020-09-12T00:00:00-06:00</published><updated>2020-09-12T00:00:00-06:00</updated><id>http://localhost:4000/2020/09/12/minesweeper</id><contenttype="html"xml:base="http://localhost:4000/2020/09/12/minesweeper/"><p>When I was creating a little Minesweeper game, I got confused at some points.
My bomb generation didn’t look quite right, and I for sure didn’t quite get the whole cascading tile reveal thing.
With a bit of internet research, I found what I was looking for.
I’ll explain it all in one place for my own research purposes.</p>
<p>So that’s that, we can put this in a big ‘ol for loop and generate an arbitrary <em>n</em> number of bombs given a width and height of a Minesweeper board.</p>
<p>I wrote this because in the first place because I was writing my own Minesweeper game.
I hope that this helps you with getting the general idea of a Minesweeper game.
The completed version of this game is available on my <a href="https://lamegames.tait.tech/">lamegames</a> site.
Let me know what you think!</p>
<p>Happy hacking!</p></content><author><name></name></author><summarytype="html">When I was creating a little Minesweeper game, I got confused at some points. My bomb generation didn’t look quite right, and I for sure didn’t quite get the whole cascading tile reveal thing. With a bit of internet research, I found what I was looking for. I’ll explain it all in one place for my own research purposes.</summary></entry></feed>
So I thank you, Kitty Wong, for getting me started running my own “research blog” (?)</p></content><author><name></name></author><summarytype="html">Curiosity is fundamental to a deep understanding of any subject. Masters, Ph.Ds, and other fancy name suffixes will never help you if you don’t have the spirit of curiosity burning inside of you.</summary></entry></feed>
Tait Hoyem
3 years ago