[BRLTTY] Inka's non-standard flow control

[Samuel Thibault]

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