[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian installer accessibility for arm64



Greetings Samuel,

On Feb 14, 2023, at 6:21 PM, Samuel Thibault <sthibault@debian.org> wrote:
> 
> Samuel Thibault, le lun. 13 févr. 2023 22:41:16 +0100, a ecrit:
>> Frank Carmickle, le dim. 12 févr. 2023 21:07:14 -0500, a ecrit:
>>> I've tried different emulated sound devices but the modules are not being loaded for any sound cards.
>> 
>> Indeed, the sound drivers have not been included in the arm images. When
>> the issue with wxwidgets will be solved, I'll have a try at including
>> them.
> 
> I have uploaded a test image, could you give it a try from:
> 
> https://people.debian.org/~sthibault/mini.iso

Well that was speedy. Thank you.

I've given it a try and I have quite a bit to report, mostly problems that are unrelated.

The first thing to note is that the image does not come up talking at all in stock configuration. If the kernel detects hardware where it can run a virtual terminal, serial console or a framebuffer device, then speakup will load. I'm not so sure what it is doing with these modern virtual graphics adapters. I'm guessing we can force some kind of video mode if we are asked to run the installer with speech? 

Once you get through that hurtle the installer doesn't speak until you do some screen review. This may be do to the first step of the installer failing. It prints an error that the language selection has failed. 

Later on there are other errors when it tries to download components from deb.debian.org <http://deb.debian.org/>. It says that it can't find the kernel modules. 

It's also not detecting disks, either scsi or virtio.

I guess it's just early days for the bookworm debian installer. Once I get through this hurtle I'll grab the debian installer sources and see if I can lend a hand sorting some of this out. I'm not a debian developer so I'm not sure how best to lend a hand, and/or become one.

Another accessibility related item is that the buffer size of the audio in the virt seems to impact the buffer size of the audio on the host machine, observable that Voiceover has a significant delay when the virt is running, but interestingly, not all the time. I'm wondering where the buffer sizes are being set and why there might be different code paths being taken on subsequent executions? 

Thanks for working through this with me.
--FC


Reply to: