From: Okash Khawaja <okash.khawaja@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, Kirk Reiser <kirk@reisers.ca>,
Simon Dickson <simonhdickson@gmail.com>,
"Speakup is a screen review system for Linux."
<speakup@linux-speakup.org>,
linux-kernel@vger.kernel.org,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
Christopher Brannon <chris@the-brannons.com>
Subject: Re: Staging status of speakup
Date: Fri, 12 Jul 2019 10:24:31 +0100 [thread overview]
Message-ID: <CAOtcWM2zV_VbWGu65tQ6j9Q+v_3Una3SarXrb6_3JRxOzZJzxA@mail.gmail.com> (raw)
In-Reply-To: <20190712083819.GA8862@kroah.com>
On Fri, Jul 12, 2019 at 9:38 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sun, Jul 07, 2019 at 08:57:10AM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Jul 06, 2019 at 08:08:57PM +0100, Okash Khawaja wrote:
> > > 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?
> >
> > I don't think the "garbled text" is an issue to get this out of staging
> > if others do not see this. It can be fixed like any other bug at a
> > later point if it is figured out.
> >
> > The kobject stuff does need to be looked at. Let me carve out some time
> > next week to do that and I will let you know what I see/recommend.
>
> At first glance, this might all be just fine.
>
> But, I can't quite figure out what some files are doing. No matter
> what, you will need Documentation/ABI/ entries for the speakup code for
> these sysfs files.
>
> Can you make up a patch to create a
> drivers/staging/speakup/sysfs-speakup file with the needed information?
> That way it will be much easier to determine exactly what these sysfs
> files do and my review can be easier, and perhaps not needed at all :)
Thanks for looking into this. I agree these descriptions will
generally be helpful for future also.
Will get back to you once it's done.
Okash
prev parent reply other threads:[~2019-07-12 9:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 13:01 Staging status of speakup Okash Khawaja
2019-03-16 1:19 ` Chris Brannon
2019-03-16 9:35 ` Samuel Thibault
2019-03-16 10:22 ` Samuel Thibault
2019-03-19 16:31 ` Alan Cox
2019-03-19 17:07 ` Samuel Thibault
2019-03-19 17:11 ` Adam Borowski
2019-03-20 20:54 ` Okash Khawaja
2019-03-16 10:05 ` Okash Khawaja
2019-03-16 3:18 ` Greg Kroah-Hartman
2019-03-16 10:09 ` Okash Khawaja
2019-07-06 19:08 ` Okash Khawaja
2019-07-07 6:57 ` Greg Kroah-Hartman
2019-07-12 8:38 ` Greg Kroah-Hartman
2019-07-12 9:23 ` [HELP REQUESTED from the community] Was: " Samuel Thibault
2019-07-13 0:46 ` Gregory Nowak
2019-07-25 3:53 ` Gregory Nowak
2019-07-25 4:04 ` Chris Brannon
2019-07-25 10:44 ` John Covici
2019-08-21 16:39 ` Okash Khawaja
2019-08-21 22:22 ` Gregory Nowak
2019-09-08 9:43 ` Okash Khawaja
2019-09-09 2:54 ` Gregory Nowak
2019-09-14 21:08 ` Okash Khawaja
2019-09-14 23:32 ` Samuel Thibault
2019-09-15 13:43 ` Greg Kroah-Hartman
2019-09-15 18:41 ` Okash Khawaja
2019-09-16 13:47 ` Samuel Thibault
2019-09-16 14:11 ` Greg Kroah-Hartman
2019-09-16 22:38 ` Gregory Nowak
2019-09-17 8:01 ` Greg Kroah-Hartman
2019-09-18 1:03 ` Gregory Nowak
2019-09-18 6:16 ` Greg Kroah-Hartman
2019-09-18 20:30 ` Gregory Nowak
2019-09-20 7:46 ` Greg Kroah-Hartman
2019-09-20 10:18 ` Okash Khawaja
2019-09-16 20:21 ` Gregory Nowak
2019-07-25 6:11 ` Willem van der Walt
2019-07-25 6:33 ` Greg Kroah-Hartman
2019-07-25 10:41 ` John Covici
2019-07-12 9:24 ` Okash Khawaja [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOtcWM2zV_VbWGu65tQ6j9Q+v_3Una3SarXrb6_3JRxOzZJzxA@mail.gmail.com \
--to=okash.khawaja@gmail.com \
--cc=chris@the-brannons.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=kirk@reisers.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=simonhdickson@gmail.com \
--cc=speakup@linux-speakup.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).