Contributing to speakup

[Okash Khawaja]

Okay the initial refactoring seems straightforward. If no one has picked it
up, I can start working on it. However, I am not sure about what the new
implmentation of serial_out() et el will look like.

Also, I understand speakup being a line discipline and the challenges
involved in creating device file and assigning speakup ldisc to it. But
don't know how it ties with it this work. And how it facilitates comms with
USB, PCI etc. Perhaps we can come back to that later and start with the
refactor first.

Thanks

On Wed, Nov 16, 2016 at 8:42 AM, Samuel Thibault <
samuel.thibault at ens-lyon.org> wrote:

> Hello,
>
> Okash Khawaja, on Wed 16 Nov 2016 05:36:19 +0000, wrote:
> > Looks like there are some ideas on what to do. Is there any piece of
> work that I can take up?
>
> AFAIK, there has been no real code written.
>
> I've however digged up my mails with Shraddha a bit, to find this:
>
> “
> Testing
> with all actual synthesis hardware will be needed at some point, yes,
> but most of the work can be done with the dummy driver.  Then we can ask
> the speakup community to make tests with actual hardware.  I don't think
> you need actual hardware (I have myself actually worked on speakup for a
> long time without any particular hardware).
>
> The I/O operations are already very well factorized (some drivers do
> some I/O by hand, but we can forget about them in a first step), into
> the following functions used by the drivers:
>
> - spk_serial_synth_probe
> - spk_serial_out
> - spk_synth_immediate
>
> To make things go smoothly, I'd say we should add equivalents of those
> functions that would use proper kernel APIs, testing them with the
> dummy driver. Then, for each driver, we can have it tested with the
> new equivalents (that would be a matter of switching the probe and
> synth_immediate methods of the driver), and once verified by users with
> the actual hardware, commit the switch to the equivalents.
>
> You will notice calls to spk_serial_out() in spk_do_catch_up() and
> spk_synth_flush(). Actually the very first step of your work could be
> to add a serial_out() method to drivers, which for now would be set
> to spk_serial_out() in all drivers, and make spk_do_catch_up() and
> spk_synth_flush() call the method instead of spk_serial_out(). Direct
> calls to spk_serial_out() within drivers could be converted into calling
> the method too, so that switching methods will be trivial.
>
> About spk_stop_serial_interrupt, it could be made to return immediately
> if spk_serial_init was never called.
>
> > And also I'll have to convert spk_serial_in() too right?
>
> Ah, I missed that one while checking functions. Yes, just like
> spk_serial_out.
> ”
>
> Samuel
>