lkml.org 
[lkml]   [2019]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Staging status of speakup
    On Fri, 15 Mar 2019 20:18:31 -0700
    Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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

    \
     
     \ /
      Last update: 2019-07-06 21:10    [W:3.046 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site