archinstall
archinstall copied to clipboard
archlinux
v2.4.0 accessibility mode requires speakup mode to be changed with *
The new menu system works with accessability. However, a recent update (not sure which yet) breaks the reading of current selected menu option (this used to work).
So no matter which entry we select, only the first entry will be read by espeakup. Here's a video of the issue: https://youtu.be/6lIa2iTOa54
Worth noting that, during first load of the menu it works. It's only when navigating up/down the menu.
@svartkanin Perhaps you might have a hunch of where the issue is? I cannot locate it and this one will be a blocker before we can release v2.4.0 unfortunately.
I'll give it another go tonight, but I suspect it's a recent change to simple-term-menu or one of the abstractions we did.
@Torxed i can have a look at it during the week. I'd suggest to go back a couple of PR commits and check at what point it started breaking :(
Cheers, any help would be greatly appreciated. I've squashed some other bugs today and fixed some feature requests. Tomorrow I intend to go backwards through the history and see where it broke.
@Torxed I tried to reach a point where this worked all the way back to https://github.com/archlinux/archinstall/pull/910. But I can't find any stage where the espeakup was reading the lines as moved up/down but it only keeps reading the first entry of the menu. I remember you mentioned that you tested this at some point in the past so we're certain that this used to work fine?
But then I've seen this one https://github.com/archlinux/archinstall/issues/825#issuecomment-1023137413 and it seems to have been confirmed by people actually using it that it worked, so I'm lost
It turns out, to quote Alex19EP from IRC:
you can use numpad * to change speakup mode. try that...
That might be what others have done too in order to get it working. It would be nice it worked "out of the box" but if that's a possible workaround that'd be great. I can't get Qemu to work with Pipewire at the moment so I have to try on physical hardware tonight.
If you have the time and energy, you're more than welcome to try the above tip out.
@Torxed stupid question but what does this mean numpad * I don't quite get it :( is it just the asterisk key on the numpad side of the keyboard?
Just FYI I'm on KVM+qemu+pipewire and things work
Ohh it actually worked! I can confirm the above seems to work. I wonder if there's a way to pass parameters to espeakup
http://linux-speakup.org/spkguide.txt search for asterisk key
Quote from Alex19EP again:
ok I tested this my self. since the hardware cursor always stays on the first menu item, in standard mode speakup actually only reads it, but in tracking selection mode, everything works fine. the question is, is it possible to set a hardware cursor where the > sign is?
So somewhere in the simple-term-menu.py after printing the menu, and printing where the arrow keys have selected, we reset the hardware cursor to the top entry for some reason. Instead of moving it to where the keyboard arrow keys are so to speak.
Just for reference, I think this is the code that needs to be tweaked: https://github.com/IngoMeyer441/simple-term-menu/blob/b6bc73e60649d745452ac156d75ccc73f8be4e85/simple_term_menu.py#L1272-L1290
I can have a look at it, not sure yet though how the hardware cursor ought to be set explicitly though. Is this still a blocker for you for the 2.4.0 rollout?
I'd say knowing there's a workaround, I'm fine with releasing v2.4.0. Could tag it and bag it tonight :)
Moving this forward as there's no time to finish this reasonable quickly without making things worse hehe.