supporting more than ttyS*

[Okash Khawaja]

Hi,

The obvious next step is ttyUSB*. What else can we support?

Regarding the user interface, we add a module param which will be a
string like "ttyUSB0". Internally we convert it to dev_t. When the param
is not supplied, we use "ttyS0". Will that be okay?

Finally, what do we do with ser module param? Keep it around for backward
compatibility?

Thanks,
Okash

[Samuel Thibault]

Post by Okash Khawaja
The obvious next step is ttyUSB*. What else can we support?

For the common uses, ttyUSB will be just enough I guess.

Post by Okash Khawaja
Regarding the user interface, we add a module param which will be a
string like "ttyUSB0". Internally we convert it to dev_t.

Yes.

Post by Okash Khawaja
Finally, what do we do with ser module param? Keep it around for backward
compatibility?

Yes.

Samuel

[Gregory Nowak]

Post by Okash Khawaja
The obvious next step is ttyUSB*. What else can we support?

At least the braille blazer, and perhaps other synthesizers support
being used via the parallel port /dev/lpx. Would supporting that be
possible?

Greg

[Samuel Thibault]

Post by Gregory Nowak

Post by Okash Khawaja
The obvious next step is ttyUSB*. What else can we support?

At least the braille blazer, and perhaps other synthesizers support
being used via the parallel port /dev/lpx. Would supporting that be
possible?

Uh. Well, probably, actually. It's a matter of writing the driver, i.e.
having a documentation of the protocol and somebody to do the tests, or
better, lend the hardware for testing.

Samuel

[Gregory Nowak]

Post by Samuel Thibault
Uh. Well, probably, actually. It's a matter of writing the driver, i.e.
having a documentation of the protocol and somebody to do the tests, or
better, lend the hardware for testing.

We already have the driver, for serial anyway. The blazer uses the bns
driver. It sounds from what you said like it wouldn't be straight
forward to open the parallel port instead of the serial port, and just
start writing to it. I thought actually that using the parallel port
is more straight forward, since there are no parameters like baudrate,
stopbits, parity, and handshaking to set. Am I totally off here?

Greg

[Samuel Thibault]

Post by Gregory Nowak

Post by Samuel Thibault
Uh. Well, probably, actually. It's a matter of writing the driver, i.e.
having a documentation of the protocol and somebody to do the tests, or
better, lend the hardware for testing.

We already have the driver, for serial anyway. The blazer uses the bns
driver.

Ah, cool :)

Post by Gregory Nowak
It sounds from what you said like it wouldn't be straight
forward to open the parallel port instead of the serial port, and just
start writing to it.

Yes, since /dev/lp* provide a tty interface, so the tty codebase should
be able to use them. That actually shows that serdev is not enough for
all our uses, so we'll really want to use the tty interface.

Post by Gregory Nowak
I thought actually that using the parallel port
is more straight forward, since there are no parameters like baudrate,
stopbits, parity, and handshaking to set. Am I totally off here?

From a tty perspective, it's just the same :)
But yes, there are a lot less questions with a parallel port.

Samuel

[Okash Khawaja]

Post by Samuel Thibault

Post by Gregory Nowak

Post by Samuel Thibault
Uh. Well, probably, actually. It's a matter of writing the driver, i.e.
having a documentation of the protocol and somebody to do the tests, or
better, lend the hardware for testing.

We already have the driver, for serial anyway. The blazer uses the bns
driver.

Ah, cool :)

Post by Gregory Nowak
It sounds from what you said like it wouldn't be straight
forward to open the parallel port instead of the serial port, and just
start writing to it.

Yes, since /dev/lp* provide a tty interface, so the tty codebase should
be able to use them. That actually shows that serdev is not enough for
all our uses, so we'll really want to use the tty interface.

True

This sounds great. /dev/lp* support should be straightforward. I am thinking of adding ttyS* and ttyUSB* in the first pass. And then add lp* afterwards as that may require testing. Let me know if that's okay.

Thanks,
Okash

[Samuel Thibault]

Post by Okash Khawaja
This sounds great. /dev/lp* support should be straightforward. I am thinking of adding ttyS* and ttyUSB* in the first pass. And then add lp* afterwards as that may require testing. Let me know if that's okay.

I'd say directly implement lp* too, so people can test already. Since
it's chosen by a kernel parameter, it's not a problem if it actually
fails somehow, even the nastiest way.

Samuel

[Okash Khawaja]

Post by Samuel Thibault

Post by Okash Khawaja
This sounds great. /dev/lp* support should be straightforward. I am thinking of adding ttyS* and ttyUSB* in the first pass. And then add lp* afterwards as that may require testing. Let me know if that's okay.

I'd say directly implement lp* too, so people can test already. Since
it's chosen by a kernel parameter, it's not a problem if it actually
fails somehow, even the nastiest way.

Cool, sounds good

[Tom Fowle]

Since many parallel ports are not bidirectional, it might be hard or
impossible to support indexing on a parallel port. I'm pretty sure the
LiteTalk synth, a doubletalk LT with parallel port, does not support
indexing on the parallel port for that reason. There is no means of
returning data on a "printer" port.

Tom Fowle WA6IVG

Post by Samuel Thibault

Post by Gregory Nowak

Post by Samuel Thibault
Uh. Well, probably, actually. It's a matter of writing the driver, i.e.
having a documentation of the protocol and somebody to do the tests, or
better, lend the hardware for testing.

We already have the driver, for serial anyway. The blazer uses the bns
driver.

Ah, cool :)

Post by Gregory Nowak
It sounds from what you said like it wouldn't be straight
forward to open the parallel port instead of the serial port, and just
start writing to it.

Yes, since /dev/lp* provide a tty interface, so the tty codebase should
be able to use them. That actually shows that serdev is not enough for
all our uses, so we'll really want to use the tty interface.

Post by Gregory Nowak
I thought actually that using the parallel port
is more straight forward, since there are no parameters like baudrate,
stopbits, parity, and handshaking to set. Am I totally off here?

From a tty perspective, it's just the same :)
But yes, there are a lot less questions with a parallel port.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Post by Tom Fowle
Since many parallel ports are not bidirectional, it might be hard or
impossible to support indexing on a parallel port.

Yes.

Samuel

[Gregory Nowak]

Post by Tom Fowle
Since many parallel ports are not bidirectional, it might be hard or
impossible to support indexing on a parallel port.

Yes.

That did occur to me as well. The blazer manual doesn't mention
anywhere that a ieee1284 cable is required. I have in fact used it
under a windows screen reader using a standard non-bidirectional cable
without issues. If a synthesizer supports indexing, would speakup
enable it when using a serial port, and disable it when using a
parallel port, or a different approach?

Greg

[Okash Khawaja]

Post by Gregory Nowak

Post by Tom Fowle
Since many parallel ports are not bidirectional, it might be hard or
impossible to support indexing on a parallel port.

Yes.

That did occur to me as well. The blazer manual doesn't mention
anywhere that a ieee1284 cable is required. I have in fact used it
under a windows screen reader using a standard non-bidirectional cable
without issues. If a synthesizer supports indexing, would speakup
enable it when using a serial port, and disable it when using a
parallel port,

Yes, that should be possible. Haven't looked at code but can't see why we can't disable it on parallel port.

On a general note, I don't know much about parallel port programming yet, so there still might be issues unaddressed in the first pass. Of course we can come back to them in subsequent patches.

Thanks,
Okash

[Okash Khawaja]

Post by Okash Khawaja

Post by Gregory Nowak

Post by Tom Fowle
Since many parallel ports are not bidirectional, it might be hard or
impossible to support indexing on a parallel port.

Yes.

That did occur to me as well. The blazer manual doesn't mention
anywhere that a ieee1284 cable is required. I have in fact used it
under a windows screen reader using a standard non-bidirectional cable
without issues. If a synthesizer supports indexing, would speakup
enable it when using a serial port, and disable it when using a
parallel port,

Yes, that should be possible. Haven't looked at code but can't see why we can't disable it on parallel port.
On a general note, I don't know much about parallel port programming yet, so there still might be issues unaddressed in the first pass. Of course we can come back to them in subsequent patches.

Indexing on /dev/lp* can be disabled by returning 0 from
synth_supports_indexing function in synth.c, whenever the device is lp*.
However, there are other places where input is also used. Ideally we
would disable all such functionality for lp*. Some synths also toggle
serial control lines which I am not sure will be possible or supported
by default in lp. Will have to look into this.

So I suggest, for the first pass we limit lp support to bns, acntsa,
dummy and txprt. Then we expand it to other synths based on their
functionality, e.g. on ltlk we disable indexing and interrogating to
print ROM version.

Let me know if that's okay.

Thanks,
Okash

[Samuel Thibault]

Some synths also toggle serial control lines which I am not sure will
be possible or supported by default in lp.

Well, the serial control lines don't make any sense for a parallel port.
But there might be some parallel ports lines used for the same kind of
signalling, manuals of these syntheses should be checked.

So I suggest, for the first pass we limit lp support to bns, acntsa,
dummy and txprt. Then we expand it to other synths based on their
functionality, e.g. on ltlk we disable indexing and interrogating to
print ROM version.

Sounds good.

Samuel

[Tom Fowle]

Post by Samuel Thibault

Some synths also toggle serial control lines which I am not sure will
be possible or supported by default in lp.

Well, the serial control lines don't make any sense for a parallel port.
But there might be some parallel ports lines used for the same kind of
signalling, manuals of these syntheses should be checked.

So I suggest, for the first pass we limit lp support to bns, acntsa,
dummy and txprt. Then we expand it to other synths based on their
functionality, e.g. on ltlk we disable indexing and interrogating to
print ROM version.

Sounds good.
Samuel

There are at least two control lines on a basic printer parallel port, an
output that is put high when the data lines have been setup, and I thiink
taken low again after a defined time. There is an input, from the external
device, that goes high when the device is busy and low again when it's ready
to receive a new character.

Sorry I've forgotten the names of these, but that's the basics.

Of course there are bidirectional parallele ports, but they get rather
complex as pins must change function as direction changes. I'd be surprised
if synths used bidirectional ports as way back they weren't common and
everybody'd have to test for them.

Tom Fowle

Post by Samuel Thibault
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Post by Tom Fowle
There are at least two control lines on a basic printer parallel port,

I know these, I played with them when I was a child :)

What I was wondering was whether the synths are actually making use of
them.

Samuel

[Gregory Nowak]

Post by Okash Khawaja
Some synths also toggle
serial control lines which I am not sure will be possible or supported
by default in lp. Will have to look into this.

I haven't tried using the blazer over parallel for a few years, so
tried it again a couple of days ago with a windows screen
reader. There is no hand shaking of any sort over parallel as far as I
can tell. Once the parallel port is selected as the output port in the
screen reader I'm working with, other serial options, including hand
shaking are disabled.

As far as using the blazer over parallel, it seems to be just dump and
wait. Once the screen reader starts sending speech to the blazer,
there is no way to interrupt until the speech is done. This does
include indexing of course as well. Looking at the parallel
communication between the blazer and the screen reader, I see no
attempt by the screen reader to read the parallel port in any way. All
it does is just write data one way. I will check the blazer manual to
see if it has anything to say about using the parallel port with a
screen reader, other than stating this is possible.

Using the blazer over parallel is never my first choice. However,
it's better than nothing if a serial port or a usb to serial converter
aren't available, and it's either parallel or nothing.

Greg

[Chris Brannon]

Post by Gregory Nowak
I will check the blazer manual to
see if it has anything to say about using the parallel port with a
screen reader, other than stating this is possible.

I looked through the Braille Blazer manual. The only thing it really
says is that if speech is enabled for the parallel port, then when a
document is sent to the port, the Braille Blazer will speak it.
I read that as "speak whatever is dumped as it comes". They probably
didn't intend this to be used with screen readers; it was a nice feature
that let you hear a document being read to you as it was being
embossed. Though I really don't know how someone could understand the
synth while the Braille Blazer was making all its clickity-clack racket.

-- Chris

[Gregory Nowak]

Post by Chris Brannon
I looked through the Braille Blazer manual. The only thing it really
says is that if speech is enabled for the parallel port, then when a
document is sent to the port, the Braille Blazer will speak it.
I read that as "speak whatever is dumped as it comes". They probably
didn't intend this to be used with screen readers; it was a nice feature
that let you hear a document being read to you as it was being
embossed. Though I really don't know how someone could understand the
synth while the Braille Blazer was making all its clickity-clack racket.

That's what I gathered when I looked through it last night.
Since the service manual would deal with servicing the hardware, it's
possible it also went into more detail on parallel port communication
(E.G. if it handshakes in some way, and how). I'm not able to get my
hands on that though, it sounds like it would be an interesting read.

Greg