"Speakup" Promoted Out Of Staging For Linux 5.9

[Guest]

This should be in userspace IMO and not the kernel. I wonder what happened to that idea to move VT into userspace from the kernel?

I understand your concerns but it goes against the goal of being able to get to early bootup and late shutdown messages.

[tildearrow]

Spend more time thinking about what the other person said and less being an insufferable dick. Petitboot is a kexec bootloader that is accessible, the bit you insulted is the part that tries to explain this. A hit on Google does some good instead of making fun of their writing.

I am done with loneliness already. I know I could have searched but why am I here then?
By that definition, we all should live in severe distancing and lack of cooperation, and when we cannot find an already-established solution to a problem, we must give up because asking is a crime.

I did not mean that as an insult. :l

Plus I just looked it up and how is it "accessible"? Oh wait I am sorry I should not ask anything :l

[onlyLinuxLuvUBack]

The guy coding plop boot manager 6 is using morse code beeps with the pc speaker to assist blind users boot...

PBM6 has PC Speaker support for a simple screen reader and notifications. This will help blind and visually impaired people to use the boot manager. The Morse Code is used for the text.

Maybe users could use this as a backup boot plan to boot linux.

https://www.plop.at/en/pbm6/home.html

[chuckula]

Same ones who developed this feature for Linux. The blind. Please note this is not a new feature added to the Linux kernel at all. This feature was added to the Linux kernel in the staging section the Linux kernel tree in 2010. So its finally lost the staging tag 10 years latter. We are talking 10 years of development from the Blind community to have this feature.

Of course the blind still have the issue that boot loaders like grub so you have to set there systems up with petitboot yes this is Linux kernel being bootloader so using this Linux feature of speakup of course this does not support booting windows. Yes Windows bootloader also has zero blind accessibility features..

Now UEFI/bios issue blind are really stuffed at that point as most UEFI and BIOS have basically zero accessibility features.

Please note I am not joking around most of the developers who coded up this Linux kernel feature are truly blind so they developed Speakup feature out of need. Of course since the blind depend on the audio stack so much they also work on it a hell of a lot fixing issues. So part of the price here to fix up Linux kernel audio issues is having Speakup support so I really cannot call Speakup bloat. Speakup is a feature we need early Linux kernel to have. We need more firmwares and bootloaders to support it as well.

I know its a little hard to think of blind people using computers when you are not blind and have not experienced being blind. Please note the blind are just like everyone else in the sense they want to-do as much as they can by themselves of course missing accessibility features don't help them and is highly annoying to them.

As I said, I'm not against screen readers, I am against kernel bloat and I'm against thinking that putting more stuff in the kernel [that could break] is the only way to solve the problem. Since you say that the problem you are trying to solve is for super-early boot sequence issues when other things may break, then I have a much better solution: Just make a simple & cheap hardware device that receives text from the standard TTY output and implements screen reading in the device. I know for a fact that braille TTY devices have been out there for years and frankly I'm puzzled that for such a low-level debugging process that braille is not really considered to be useful when we are dealing with 100% text in the first place.

Anyway, an inexpensive separate device that handles this rare (even for blind users) situation well in a way that literally cannot crash the kernel, introduce security holes, bloat the code that needs to be audited, etc. would clearly be my solution. Oh, and it could work fine on older kernels that don't have this extra stuff thrown in too.

[zamadatix]

Plus I just looked it up and how is it "accessible"? Oh wait I am sorry I should not ask anything :l

Asking questions is fine just dont respond to points with how bad you think their sentence structure is if what you mean is to ask more.

https://wiki.debian.org/accessibility#Complete_Accessibility

That section gives a decent overview of how to configure petitboot with accessibility options for booting into different installs. The general page is also useful to see options and capabilities of other things (like grub beeps) can be done but, of course, most of the page is tool and/or Debian specific and not out of the box configured which is where this comes in.

[oiaohm]

As I said, I'm not against screen readers, I am against kernel bloat and I'm against thinking that putting more stuff in the kernel [that could break] is the only way to solve the problem. Since you say that the problem you are trying to solve is for super-early boot sequence issues when other things may break, then I have a much better solution: Just make a simple & cheap hardware device that receives text from the standard TTY output and implements screen reading in the device. I know for a fact that braille TTY devices have been out there for years and frankly I'm puzzled that for such a low-level debugging process that braille is not really considered to be useful when we are dealing with 100% text in the first place.

Except you did not read how speakup works before commenting.
https://cateee.net/lkddb/web-lkddb/SPEAKUP.html is a good start.

Reality is the blind use items like Braille 'n Speak of course these devices need support so they work right yes speakup is the Linux kernel driver for all those devices. There is a interesting problem if you are on a braille TTY devices while the linux kernel is booting is insanely hard on the fingers and the speed you are trying to read with your fingers at. Something to be aware of fingers are lot slower at reading braille than vision or text to speech . Text to speech by hardware has to be used for early boot diagnostics with speakup yes the the developers of speakup have already considered your problem. The reality is you cannot take the standard TTY output of the Linux kernel and shove it straight as is into standard TTY of speech device there is some processing required to make the speech coming out be sane by filtering the text being sent.

There are things are kernel displays on screen that are useful for us with vision that are complete nightmare listen to if you just straight convert into speech think all those square brackets being read to you open square bracket followed by close square bracket though the boot process and this is just one example of many where the output need to be altered to be sane for text to speech. Yes what is ideal in text for blind and those with vision are in fact two different things this is where speakup comes in to make the Linux kernel output compatible with being processed into speech without coming a waffling mess.

http://www.linux-speakup.org/spkguide.txt

So the manual tells you something important.

Speakup does support two other synthesizers, but because they work in conjunction with other software, they must be loaded as modules after their related software is loaded, and so are not available at boot up.

Yes they are using a hardware device for early boot. But when blind person has laptop out and about they may be using just software mode so they don't have to have the device plugged in.

Chuckula the reality is speakup puts the least possible into the Linux kernel to get the job done.

[microcode]

kmscon should have been better.

[oiaohm]

They should have moved the feature to userspace and start it on the init ramdisk or something. Because what if the TTS system crashes. It would cause bugs and panics in the kernel.

Except you have not read http://www.linux-speakup.org/spkguide.txt the manual for speakup. The reality it does not put TTS engine in kernel space. Instead it allows hardware TTS devices to be detect and used in real early boot. Speakup also altering text going to those TTS hardware devices to not be waffling with the likes of open square bracket/close square bracket and so on. Yes speakup can use a software TTS that can be placed init ramdisk and does run in userspace

And what about Mac. Yes Mac is the most accessible computer ever.

This is not true for a blind person. Lot of blind interface hardware does not work with Mac at all.

The bootloader does not support text to speech also..

The reality is apple devices are not really designed with the idea you will fix anything.

Petitboot. What is that.

https://mirrors.edge.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html

It is a bootloader based around the Linux kenrel.

That is an issue that should go to the firmware manufacturers. Not Linux. Also this is not possible on BIOS firmware. Like it or not you have no space to fit in text to speech synthesizer and code to initialize the audio hardware. BIOS is extremely small.

This is total crap. Linuxboot can be placed in UEFI rom space with speakup enabled with espeak in init ram.

https://www.techdrivein.com/2019/04/linuxboot-uefi-replacement-for-linux.html

Yes this is 90 percent UEFI replacement based around the Linux kernel.

Yes your UEFI for people with vision has to loss some fancy graphics to make room to have drivers for the blind. Or maybe to reduce on space hardware makers might come up with a nice universal standard for a text to speech device?

Really there is no valid reason other than being bias against the blind that your UEFI firmware cannot support the blind well.

Not all computers or motherboards have a beeper anymore so it is not a viable solution either.

The horrible point is all AMD and Intel chip-sets have the speaker/beeper in the chip-set so if there is not a jumper to connect a beeper/speaker or beeper on board the motherboard vendor is cutting corners.

However I am sure you want it in kernel for reasons. Are you perhaps in need of it too. Maybe. I am curious.

The reason why speakup has to be in kernel space is so that when you send kernel dmseg like text to a TTS hardware device you get something that you can in fact listen to.

I have noted that. The problem is usage share. Few people are blind. Just like Linux is used by few. Therefore most applications do not support accessibility features just like most application developers are not willing to port to Linux.

Funny enough one of the most popular OS for the blind is the Linux terminal. So the blind is a small market share that Linux deployments have the largest market share of yes larger than OS X or Windows.

Speakup has been quite successful to get Linux domination in the blind desktop usage due to work well for them. Think its a market Linux is doing well in there is every reason for them to have a kernel feature or two just for them.

Really I am sick of these arguments just because something is a small market share we don't have to support it well. Maybe to support it well will take getting some standards and agreements in place. Doing bootloaders and firmware that supports the blind well can truly be demoed today so its not that its impossible.

[oiaohm]

kmscon should have been better.

Even if kmscon worked out speakup being early kernel for the early log messages still would not have been avoided.

[Terrablit]

Don't forget that current logging "standards" today are formatted almost entirely for the visually-oriented. This is also another reason why text-based logs with half-assed roll-your-own formatting aren't the epitome of logging. Structured logging with properties and structures that gets formatted into a visual display format (with easily-colorized output) could also easily be formatted into an easier audio format. As well as being far more searchable when you're hunting through gigabytes of text logs to look for errors. I'm in the process of converting text logging to structured logging on a product and it's a lot more work after the fact than doing it the right way from the beginning. But the support benefits are immeasurable.

Blind users and devs are an extremely valuable resource in showing us where these unsupported assumptions lie. And you may be able to see now, but age and accidents can claim the vision of any of us. Do you expect people to just not do anything when blind? Are they just supposed to roll over and die? No. Many of them grew up with computers, and computers are the way of the future. We can't just lock people out of that because of self-absorbed concerns about bloat. We can't just say that only sighted people deserve being able to interact with the system during the boot process. Or that they need to blindly figure out what to install so their systems work. There's a minimal level of effort needed to enable them to do the work themselves, and they know what it is more than we do.

What's more, some day in the future we're going to have electroneural interfaces. And piping visual data over an information interface to be processed in a much slower, more lossy manner instead of the raw information is going to get in the way of that. Especially since we're not necessarily going to have a route to every area in the brain. We're not near to it, but here in the present we can at least learn to not log so shittily so that it obstructs the many ways visually-impaired people have designed to work around our egos.

The goddamn bike-shedding from pretend experts that goes on here over every single topic is ridiculous.