[BRLTTY] Inka's non-standard flow control

[Nicolas Pitre]

On Mon, 24 Apr 2006, Samuel Thibault wrote:

> Before I go into technical details and loose people: do anybody has an
> Inka serial device and could test a few things?
> 
> 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?

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.

> > 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.  And RS425, even if it is 
not so standard, is still way more ubiquitous than Inka devices.

> And I guess that if Inka people implemented a 57600bps mode, that's 
> because there is some file transfer protocol for which we'd like to 
> have full speed.

According to Jason it seems not.


Nicolas