[BRLTTY] Inka's non-standard flow control
Samuel Thibault
samuel.thibault at ens-lyon.org
Mon Apr 24 04:22:22 EDT 2006
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)
> 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.
> > Doesn't it need the strobe to be quite responsive?
>
> How responsive does it need to be?
~174µs.
> > We tried to implement the VisioBraille non-standard flow control, and it
> > wasn't working because it wasn't responsive enough.
>
> How was it implemented?
That was two years ago, I can't remember precisely. I guess we were
using TIOCMIWAIT.
> > If strobing _each
> > character_ from user space is responsive enough, then fine. But I really
> > doubt it will ever work at 57600bps...
>
> Why not? Did you try it?
I don't have the hardware. Dave, do you have it?
> Isn't the protocol working in lock state? If so the transfer rate will
> be just as fast as the amount of CPU you can give it. If you can
> transfer only 100 characters in 100ms so what? It should be plenty
> functional already.
Then it would be useless compared to Mode 2 of the Inka device. 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.
> Otherwise, if it can't be done in user space, I'm afraid you'll have to
> tweak each low level serial drivers
Not so much. I only had to add two serial_core hooks. I of course don't
mean to tweak low level serial drivers that don't use serial_core.
> and frankly I'm afraid you'll be granted with a big "no no" if you
> don't have a strong case for it.
There are other strong cases for this: DSR/DTR and half-duplex, as I
said, and this has lead Russell King to a "yes yes" when the issue was
discussed on lkml and lsml.
Regards,
Samuel
More information about the BRLTTY
mailing list