Staging status of speakup

[Okash Khawaja <okash.khawaja@gmail.com>]

Hi,

We have made progress on the items in TODO file of speakup driver in
staging directory and wanted to get some clarity on the remaining
items. Below is a summary of status of each item along with the quotes
from TODO file.

1. "The first issue has to do with the way speakup communicates
with serial ports.  Currently, we communicate directly with the hardware
ports. This however conflicts with the standard serial port drivers,
which poses various problems. This is also not working for modern
hardware such as PCI-based serial ports.  Also, there is not a way we
can communicate with USB devices.  The current serial port handling
code is in serialio.c in this directory."

Drivers for all external synths now use TTY to communcate with the
devices. Only ones still using direct communication with hardware ports
are internal synths: acntpc, decpc, dtlk and keypc. These are typically
ISA cards and generally hardware which is difficult to make work. We
can leave these in staging.

2. "Some places are currently using in_atomic() because speakup
functions are called in various contexts, and a couple of things can't
happen in these cases. Pushing work to some worker thread would
probably help, as was already done for the serial port driving part."

There aren't any uses of in_atomic anymore. Commit d7500135802c
"Staging: speakup: Move pasting into a work item" was the last one that
removed such uses.

3. "There is a duplication of the selection functions in selections.c.
These functions should get exported from drivers/char/selection.c
(clear_selection notably) and used from there instead."

This is yet to be done. I guess drivers/char/selection.c is now under
drivers/tty/vt/selection.c.

4. "The kobjects may have to move to a more proper place in /sys.The
discussion on lkml resulted to putting speech synthesizers in the
"speech" class, and the speakup screen reader itself
into /sys/class/vtconsole/vtcon0/speakup, the nasty path being handled
by userland tools."

Although this makes logical sense, the change will mean changing
interface with userspace and hence the user space tools. I tried to
search the lkml discussion but couldn't find it. It will be good to
know your thoughts on this.

Finally there is an issue where text in output buffer sometimes gets
garbled on SMP systems, but we can continue working on it after the
driver is moved out of staging, if that's okay. Basically we need a
reproducer of this issue.

In addition to above, there are likely code style issues which will
need to be fixed.

We are very keen to get speakup out of staging both, for settling the
driver but also for getting included in distros which build only the
mainline drivers.

Thank you,
Okash