[BRLTTY] Inka's non-standard flow control
Nicolas Pitre
nico at cam.org
Mon Apr 24 09:24:50 EDT 2006
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
More information about the BRLTTY
mailing list