[BRLTTY] Inka's non-standard flow control

[Samuel Thibault]

Nicolas Pitre, le Mon 24 Apr 2006 09:24:50 -0400, a écrit :
> On Mon, 24 Apr 2006, Samuel Thibault wrote:
> > Nicolas Pitre, le Sun 23 Apr 2006 22:29:00 -0400, a écrit :
> > > > > Do it in user space.  Please.
> > > > 
> > > > Why?
> > > 
> > > Because it is portable that way.
> > 
> > Ok, but the example of VisioBraille showed that it will hardly work, or
> > maybe work slowlier than with Mode 2 (no hardware flow control, hence
> > 19200 bps)
> 
> So what?  Why would the kernel need support for a device that apparently 
> could use a standard mode (mode 2) which already works and is plenty 
> good enough?

Not so good for file transfers, but as Jason said, there doesn't seem to
be any. And for braille stuff, 19200bps would be sufficient.

> Trying to support mode 1 and adding extra non-standard baggage using 
> non-portable interface to the kernel just to avoid the inconvenience of 
> switching mode isn't probably worth it IMHO.

Inconveniences should always be taken care of. Remember that people
don't read documentations...

So ok, all things considered, _if_ a user-level implementation works
(even slowly), then fine.

Dave, I can write a simple thread-based implementation for this, to
begin with.

> > > Because, frankly, I doubt the current serial maintainer will accept
> > > such a non standard behavior added to the kernel for only one
> > > "obscure" device.  And I know what I'm talking about when it comes to
> > > dealing with that person.
> > 
> > There are other not-so-standard hardware flow controls that people would
> > like to see added to the kernel: DSR/DTR and half-duplex for instance.
> > Russell King was willing to have high-level part in serial_core for
> > this.
> 
> Oh really?  All I've seen about people wanting to use RS425 for example 
> have been told by RMK to do it in user space.

Mmm, this was in another thread then. Here is a quote from 7th Oct 2004:

«
> Right now that poses a challenge but if drivers were to implement
> ldisc->modem_change() or a similar callback for such events an ldisc
> could then handle many of the grungy suprises and handle them once and
> in one place.

To me at least that sounds like a good solution.  I can't help but
wonder whether moving some of the usual modem line status change
processing should also be moved into the higher levels.  This will
probably make more sense if the "block till ready" code also moves,
which I think Ted was considering at one point.
»
Note: "higher level" here doesn't mean "into line disciplines", but in a
new level.

Regards,
Samuel