Keyboard issues w/Orca screen reader

[Simon Ser]

On Wednesday, February 24th, 2021 at 10:59 PM, Mike Gorse <mgorse at suse.com> wrote:

> As part of the GNOME project, we have Orca.

Thanks for reaching out!

It seems like Orca uses X11 keyboard grabs for two different things…

> Orca uses this key filter for a few things. It wants to announce the key that
> the user just pressed.

The first one is announcing the keys. I don't think there's a way around having
some kind of backdoor for this one. Orca needs to be a privileged process in
order to listen to all key events. What "privileged" means isn't clear yet.

As prior art, I can think of wshowkeys [1] which displays which keys are being
pressed on screen. It uses a helper suid process, opens /dev/input/whatever,
drops privileges, and relays key presses to the main process.

[1]: https://git.sr.ht/~sircmpwn/wshowkeys

> If the user presses the control key, then Orca will stop reading whatever it
> is reading. It also implements commands in this way (the user can press a key
> to have it read the current line, to give one example).

This sounds like a separate requirement: global keybinds. In general these are
configured directly in the compositor. With the status quo, a manual user
action would be needed to set them up.

There is a proposal to add a standardized way to setup compositor-wide
keybindings [2]. Maybe you can have a look at it if you're interested?

[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/56