On Fri, 15 Mar 2019 20:18:31 -0700 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote: > > 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. > > Ok, that's fine. > > > 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. > > Great, let's remove that todo item then. > > > 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. > > Yes, someone should update the todo item :) > > > 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. > > I don't remember, sorry. I can review the kobject/sysfs usage if you > think it is "good enough" now and see if I find anything > objectionable. > > > 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. > > That's great, I am glad to see this happen. How about work on the > selection thing and then I can review the kobject stuff in a few > weeks, and then we can start moving things for 5.2? Hi Greg, Apologies for the delay. I de-duplicated selection code in speakup to use code that's already in kernel (commit ids 496124e5e16e and 41f13084506a). Following items are what remain now: 1. moving kobjects location 2. fixing garbled text I couldn't replicate garbled text but Simon (also in CC list) is looking into it. Can you please advise on the way forward? Thanks, Okash _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
