On Tue, 19 Mar 2019 16:31:21 +0000 Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100 > Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote: > > > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit: > > > Okash Khawaja <okash.khaw...@gmail.com> writes: > > > > 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. > > > > > > What kind of reproducer do you need here? It's straightforward to > > > reproduce in casual use, at least with a software synthesizer. > > > > The problem is that neither Okash nor I are even casual users of > > speakup, so we need a walk-through of the kind of operation that > > produces the issue. It does not have to be reproducible each time > > it is done. Perhaps (I really don't know what that bug is about > > actually) it is a matter of putting text in the selection buffer, > > and try to paste it 100 times, and once every 10 times it will be > > garbled, for instance. > > paste_selection still says > > /* Insert the contents of the selection buffer into the > * queue of the tty associated with the current console. > * Invoked by ioctl(). > * > * Locking: called without locks. Calls the ldisc wrongly with > * unsafe methods, > */ > > from which I deduce that with everyone using X nobody ever bothered to > fix it. So before you look too hard at the speakup code you might > want to review the interaction with selection.c too. Hi, This is a good point. At the moment speakup uses its own set of selection and paste functions but I am in process of changing speakup to use these functions from drivers/tty/vt/selection.c instead. This lack of locking will be worth watching out for. Thanks! Okash