Status of kernel

[Okash Khawaja]

Hello,

I am currently studying speakup's kernel code. Can someone guide me what is
it's current status? Particularly,

- What needs to be done in order to mainline it? I have read the TODO file
but not sure how up-to-date it is.

- Are there existing plans to do work on the driver?

- Although the code is fairly readable, is there any documentation for the
driver?

Please add anything else you think is relevant.

Thanks,
Okash

[Samuel Thibault]

Post by Okash Khawaja
I am currently studying speakup's kernel code. Can someone guide me what is
it's current status?

It's currently in the staging part of the kernel, which is already a
good thing since it gets updated as the kernel API changes.

Post by Okash Khawaja
- What needs to be done in order to mainline it? I have read the TODO file but
not sure how up-to-date it is.

Its first item might be set to "update TODO" :)

About the "how to communicate with the serial ports" item, I do have
hints how it could be done, I just never got around finding the time to
hack it down.

Post by Okash Khawaja
- Are there existing plans to do work on the driver?

Not that I know of.

Post by Okash Khawaja
- Although the code is fairly readable, is there any documentation for the
driver?

Not that I know of.

Post by Okash Khawaja
Please add anything else you think is relevant.

Make sure to synchronize with the speakup list. Perhaps better
explicitly Cc us like you just did, to catch our eyes, I for instance
don't necessarily follow the speakup list that closely unfortunately.

Samuel

[Okash Khawaja]

Post by Samuel Thibault

Post by Okash Khawaja
I am currently studying speakup's kernel code. Can someone guide me what is
it's current status?

It's currently in the staging part of the kernel, which is already a
good thing since it gets updated as the kernel API changes.

Post by Okash Khawaja
- What needs to be done in order to mainline it? I have read the TODO file but
not sure how up-to-date it is.

Its first item might be set to "update TODO" :)
About the "how to communicate with the serial ports" item, I do have
hints how it could be done, I just never got around finding the time to
hack it down.

Post by Okash Khawaja
- Are there existing plans to do work on the driver?

Not that I know of.

Post by Okash Khawaja
- Although the code is fairly readable, is there any documentation for the
driver?

Not that I know of.

Post by Okash Khawaja
Please add anything else you think is relevant.

Make sure to synchronize with the speakup list. Perhaps better
explicitly Cc us like you just did, to catch our eyes, I for instance
don't necessarily follow the speakup list that closely unfortunately.
Samuel

Thanks. That's very good. Like I said I am exploring the driver code and would like to spend one more weekend doing that - I work during daytime on weekdays.

I will be happy to start discussing comms with serial ports next week and hopefully take this forward.

Cheers,
Okash

[John Covici]

What do you think of Dave Borowski's mods to speakup? He says he is
working on a driver to enable speakup to open any synth such as
usbserial, etc.? What are your thoughts on how to get this to work?

On Thu, 10 Nov 2016 11:10:32 -0500,

Post by Samuel Thibault

Post by Okash Khawaja
I am currently studying speakup's kernel code. Can someone guide me what is
it's current status?

It's currently in the staging part of the kernel, which is already a
good thing since it gets updated as the kernel API changes.

Post by Okash Khawaja
- What needs to be done in order to mainline it? I have read the TODO file but
not sure how up-to-date it is.

Its first item might be set to "update TODO" :)
About the "how to communicate with the serial ports" item, I do have
hints how it could be done, I just never got around finding the time to
hack it down.

Post by Okash Khawaja
- Are there existing plans to do work on the driver?

Not that I know of.

Post by Okash Khawaja
- Although the code is fairly readable, is there any documentation for the
driver?

Not that I know of.

Post by Okash Khawaja
Please add anything else you think is relevant.

Make sure to synchronize with the speakup list. Perhaps better
explicitly Cc us like you just did, to catch our eyes, I for instance
don't necessarily follow the speakup list that closely unfortunately.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Post by John Covici
What do you think of Dave Borowski's mods to speakup? He says he is
working on a driver to enable speakup to open any synth such as
usbserial, etc.? What are your thoughts on how to get this to work?

I don't know about this work, where is it?

Samuel

[John Covici]

It has been announced on the speakup list, or you can download his
current mods from http://davidborowski.ddns.net

On Fri, 11 Nov 2016 03:34:47 -0500,

Post by Samuel Thibault

Post by John Covici
What do you think of Dave Borowski's mods to speakup? He says he is
working on a driver to enable speakup to open any synth such as
usbserial, etc.? What are your thoughts on how to get this to work?

I don't know about this work, where is it?
Samuel

[Samuel Thibault]

Hello,

Post by John Covici
On Fri, 11 Nov 2016 03:34:47 -0500,

Post by Samuel Thibault

Post by John Covici
What do you think of Dave Borowski's mods to speakup? He says he is
working on a driver to enable speakup to open any synth such as
usbserial, etc.? What are your thoughts on how to get this to work?

I don't know about this work, where is it?

It has been announced on the speakup list, or you can download his
current mods from http://davidborowski.ddns.net

Ok, thanks.

So it is somehow a fork. Are there plans to merge the upstream
changes in through a git tree or something? There are various fixes
being brought from the kernel, it'd be a shame if we were having two
completely diverging trees... And at some point, of course, David's
work need to be merged into the main kernel through proper patches so
it can benefit everybody without having to compile their own kernel. I
know it'll very probably look very tedious, but that's how things have
work in any kind of software project, to provide proper quality.

Samuel

[Samuel Thibault]

or you can download his current mods from
http://davidborowski.ddns.net

BTW, David, could you fix your mail address in the source code? None of
***@gmail.com, ***@rogers.com, ***@golden.net
works, only ***@gmail.com does.

Samuel

[Okash Khawaja]

Hi Samuel,

What do you expect to be the outcome of this serial comms re-work?

Okash

On Fri, Nov 11, 2016 at 4:32 PM, Samuel Thibault <

Post by Samuel Thibault

or you can download his current mods from
http://davidborowski.ddns.net

BTW, David, could you fix your mail address in the source code? None of
Samuel

[Samuel Thibault]

Post by Okash Khawaja
What do you expect to be the outcome of this serial comms re-work?

Which serial comms re-work are you talking about? I don't know about
David's work. What I was mentioning was to get some interface
integrated to the kernel to access kernel comm ports properly, i.e.
basically an equivalent of open("/dev/ttyS0"), which can thus be used
for usb and pci too.

Samuel

[Okash Khawaja]

On Sat, Nov 12, 2016 at 3:47 PM, Samuel Thibault <

Post by Samuel Thibault

Post by Okash Khawaja
What do you expect to be the outcome of this serial comms re-work?

Which serial comms re-work are you talking about? I don't know about
David's work. What I was mentioning was to get some interface
integrated to the kernel to access kernel comm ports properly, i.e.
basically an equivalent of open("/dev/ttyS0"), which can thus be used
for usb and pci too.
Samuel

Not sure if David's work involves changes to serial. I did cursory checks
and diffed serialio.c which didn't seem much different.

Could you explain your idea a bit more? I have been reading the driver code
and want to contribute to this project.

[Samuel Thibault]

Could you explain your idea a bit more? I have been reading the driver code and
want to contribute to this project.

Just copy/pasting some previous thoughts. The idea would be to make
speakup a tty line discipline, just like it is for a mouse, ppp, etc.

“
land? One of the goals of speakup is to be available before userland
works (otherwise we could as well just move the drivers to userland), so
we don't have any userland helper to set the line disciline up.

And even before setting up the line discipline, how can speakup open
the port? We don't have a process context or /dev/, so we can't just
use sys_open and alike. What we could use is some function which takes
a minor/major pair or a device name, and returns a filp, then we can
tty_set_ldisc(N_SPEAKUP) on file_tty(filp), but I don't know if such
thing exists? That would probably be building a struct inode (getting
inspired from fs/ramfs/), then just open it? Something like:

struct inode *inode = new_inode(sb);

init_special_inode(inode, S_IFCHR, MKDEV(major, minor));
filp = get_empty_filp();
do_dentry_open(filp, inode, NULL, NULL);
struct tty_struct *tty = file_tty(filp);
tty_set_ldisc(tty, N_SPEAKUP);
”

Samuel

[John G. Heim]

One thing I've never understood is why the kernel can have a serial
console yet speakup can't talk to the serial port. How does the kernel's
serial console talk to the serial port? Why can't speakup do the same?

Post by Samuel Thibault

Could you explain your idea a bit more? I have been reading the driver code and
want to contribute to this project.

Just copy/pasting some previous thoughts. The idea would be to make
speakup a tty line discipline, just like it is for a mouse, ppp, etc.
“
land? One of the goals of speakup is to be available before userland
works (otherwise we could as well just move the drivers to userland), so
we don't have any userland helper to set the line disciline up.
And even before setting up the line discipline, how can speakup open
the port? We don't have a process context or /dev/, so we can't just
use sys_open and alike. What we could use is some function which takes
a minor/major pair or a device name, and returns a filp, then we can
tty_set_ldisc(N_SPEAKUP) on file_tty(filp), but I don't know if such
thing exists? That would probably be building a struct inode (getting
struct inode *inode = new_inode(sb);
init_special_inode(inode, S_IFCHR, MKDEV(major, minor));
filp = get_empty_filp();
do_dentry_open(filp, inode, NULL, NULL);
struct tty_struct *tty = file_tty(filp);
tty_set_ldisc(tty, N_SPEAKUP);
”
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

One thing I've never understood is why the kernel can have a serial console
yet speakup can't talk to the serial port. How does the kernel's serial
console talk to the serial port? Why can't speakup do the same?

Because there is special plumbing between the serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon.

Samuel

[John G. Heim]

Well, that's discrimination.

Post by Samuel Thibault

One thing I've never understood is why the kernel can have a serial console
yet speakup can't talk to the serial port. How does the kernel's serial
console talk to the serial port? Why can't speakup do the same?

Because there is special plumbing between the serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon.
Samuel

[Samuel Thibault]

Post by John G. Heim
Well, that's discrimination.

"discrimination" is only when the work to accomodate the disability
is unreasonable. The plumbing that'd be necessary here is really
unreasonable.

The plumbing I mentioned in another mail, is however not. It's "just" a
matter of somebody actually working on working it out eventually.

Samuel

[Al Sten-Clanton]

qUOTING sAMUEL tHIBAULT, "Because there is special plumbing between the
serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon."

i WONDER IF WE SHOULD FROWN UPON THE FROWNERS AND TRY TO GET IT DONE, AS
HARDWARE SPEECH WOULD HELP A LOT. wOULD IT WRECK THE KERNEL OR
SOMETHING? aLTERNATIVELY, IS USING USB PROTS NOT A GOOD OPTION?

i'VE FINALLY DECIDED TO TRY TO LEARN c, HOPING i MIGHT KNOW ENOUGH TO
HELP DOWN THE ROAD. iT WILL BE A WHILE EVEN AT BEST BEFORE i CAN BE
USEFUL, SO MAYBE IT WON'T MATTER BY THEN, BUT i'D LIKE TO DO MORE THAN
COMPLAIN.

tHANKS FOR ANY THOUGHTS.

aL

Post by Samuel Thibault

One thing I've never understood is why the kernel can have a serial console
yet speakup can't talk to the serial port. How does the kernel's serial
console talk to the serial port? Why can't speakup do the same?

Because there is special plumbing between the serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Would it wreck the kernel or something?

Yes.

Alternatively, is using usb prots not a good option?

It's exactly the same issue.

Samuel

[John G Heim]

Post by Samuel Thibault

Would it wreck the kernel or something?

Yes.

Alternatively, is using usb prots not a good option?

It's exactly the same issue.

What is exactly the same problem?

[Samuel Thibault]

Post by John G Heim

Post by Samuel Thibault

Would it wreck the kernel or something?

Yes.

Alternatively, is using usb prots not a good option?

It's exactly the same issue.

What is exactly the same problem?

Plugging speakup onto the serial drivers (be they ISA, PCI, or USB),
instead of poking ports.

Samuel

[John G Heim]

Years ago, I had a discussion via private email with some members of the
kernel development team. I asked why the speakup code was stuck in
staging and they said the code wasn't up to standards. I asked them for
specific examples and the stuff they sent me was fairly trivial. I said,
"Are you saying I couldn't find equally bad or worse stuff in the main
kernel code?" To wich they responded that, yes, if you went looking for
it you could find worse but what I was asking for was for them to
approve known sub-standard code. At which point I started calling them
names and threatening lawsuits. That's a joke. I didn't really do that.
Although I did use the d-workd (discrimination) in my response. That was
pretty much the end of it. But now I think if they had simply phrased it
differently, I might have had a different perspective. If they had said
that other sub-standard code was "grandfathered" in and they now have a
strict no sub-standard code policy, I would have been more willing to
accept their explanation. Likewise, I guess you could say the serial
console code is grandfathered in and the speakup code is not. The one
thing that bothers me is that somebody is always messing with the code
that disables speakup access to the serial port. I have to keep re-doing
the patch file I use to disable the disabling. So somebody is taking the
time to diddle with it but not to fix it. Trying to put this as
tactfully as I can, it looks to me as if a non-trivial amount of work is
being put into disabling speakup's access to the serial port. If it ever
gets to the point where you can't re-enable access by commenting out
that one line of code, then I'll be ... irritated.


Something just occured to me... I wonder if I could get permission from
the University of Wisconsin, where I work, to rewrite speakup for USB.
Everybody who has serial only synths would still be screwed but it'd be
a step forward.

Post by Al Sten-Clanton
qUOTING sAMUEL tHIBAULT, "Because there is special plumbing between
the serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon."
i WONDER IF WE SHOULD FROWN UPON THE FROWNERS AND TRY TO GET IT DONE,
AS HARDWARE SPEECH WOULD HELP A LOT. wOULD IT WRECK THE KERNEL OR
SOMETHING? aLTERNATIVELY, IS USING USB PROTS NOT A GOOD OPTION?
i'VE FINALLY DECIDED TO TRY TO LEARN c, HOPING i MIGHT KNOW ENOUGH TO
HELP DOWN THE ROAD. iT WILL BE A WHILE EVEN AT BEST BEFORE i CAN BE
USEFUL, SO MAYBE IT WON'T MATTER BY THEN, BUT i'D LIKE TO DO MORE THAN
COMPLAIN.
tHANKS FOR ANY THOUGHTS.
aL

Post by Samuel Thibault

One thing I've never understood is why the kernel can have a serial console
yet speakup can't talk to the serial port. How does the kernel's serial
console talk to the serial port? Why can't speakup do the same?

Because there is special plumbing between the serial console and the
serial drivers. Doing the same plumbing between speakup and serial
drivers would be very very frowned upon.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

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

[Samuel Thibault]

The one thing that bothers me is that somebody is always
messing with the code that disables speakup access to the serial port.
So somebody is taking the time to diddle with it but not to fix it.

Just to be sure: really, nobody is trying hard to break speakup. It's
just a side effect of Speakup doing things in a way which is really not
supported. When there are changes in the main code, it has side effects
on speakup. Plugging properly into the serial as a line discipline
drivers would avoid the issue entirely.

Something just occured to me... I wonder if I could get permission from the
University of Wisconsin, where I work, to rewrite speakup for USB.

You'd get exactly the same issue. If you write a USB driver that pokes
port, then it'll be disturbed by the rest of the kernel.

Everybody who has serial only synths would still be screwed but it'd be a
step forward.

No, it'd be just a step aside.

Samuel

[John G Heim]

I wasn't suggesting "poking ports" -- cuz I don't even know what that
is. I downloaded a ebook on writing linux kernel drivers. I used to
write unix kernel drivers for a living. I figure I can understand the
linux kernel. But maybe you're saying that by the time /dev is
populated, it's too late? Speakup cannot work like any other device driver?

I already have udev rules to recognize when I plug in the USB cable on
my tripletalk. When it's plugged in during boot, I get speech during
boot via the searial port. Instead of enableing speakup through the
serial port, why can't it talk to my tripletalk via the USB port?

I haven't really listened that closely to the messages spoken when the
udev subsystem recognizes my tripletalk. It might be that it is already
so far into the boot sequence thatyou might as well wait until user
space is ready to start speech. Is that the problem? I am going to
reboot right now and see.

Post by Samuel Thibault

The one thing that bothers me is that somebody is always
messing with the code that disables speakup access to the serial port.
So somebody is taking the time to diddle with it but not to fix it.

Just to be sure: really, nobody is trying hard to break speakup. It's
just a side effect of Speakup doing things in a way which is really not
supported. When there are changes in the main code, it has side effects
on speakup. Plugging properly into the serial as a line discipline
drivers would avoid the issue entirely.

Something just occured to me... I wonder if I could get permission from the
University of Wisconsin, where I work, to rewrite speakup for USB.

You'd get exactly the same issue. If you write a USB driver that pokes
port, then it'll be disturbed by the rest of the kernel.

Everybody who has serial only synths would still be screwed but it'd be a
step forward.

No, it'd be just a step aside.
Samuel

[Samuel Thibault]

I figure I can understand the linux kernel. But
maybe you're saying that by the time /dev is populated, it's too late?

Please would like to have speakup ready to talk before the /dev
directory even exists.

Speakup cannot work like any other device driver?

No, because it shouldn't drive hardware, it should be a layer on top of
serial drivers.

I already have udev rules to recognize when I plug in the USB cable on my
tripletalk. When it's plugged in during boot, I get speech during boot via
the searial port. Instead of enableing speakup through the serial port, why
can't it talk to my tripletalk via the USB port?

It could if it implemented drivers for USB ports. But it's a loot
better to just layer it on top of the existing drivers.

Samuel

[Rob]

Post by John G. Heim
How does the kernel's

serial console talk to the serial port? Why can't speakup do the same?


How does BRLTTY do it? Can we implement similar code?

[Samuel Thibault]

Post by John G. Heim

Post by John G. Heim
How does the kernel's

serial console talk to the serial port? Why can't speakup do the same?
How does BRLTTY do it? Can we implement similar code?

BRLTTY lives in userland, not kernel land.

Samuel

[Gregory Nowak]

Post by Rob
How does BRLTTY do it? Can we implement similar code?

Brltty does it like any other program that runs in userland.

Greg

[Okash Khawaja]

Hi Samuel,

Apologies for the delay - got abducted by aliens while I was sniffing hot
coffee through nose.

Please bear with me as I try and understand this. So we have:

1. speakup tty line discipline N_SPEAKUP
2. device /dev/ttyx

N_SPEAKUP is set as line discipline for /dev/ttyx. The challenge is
enabling speakup before userland.

Is the above correct? And how will /dev/ttyx be used? Also is there a link
to where you pasted your idea from?

Someone attempted something similar back in 2005:
http://lkml.iu.edu/hypermail/linux/kernel/0510.2/0803.html

Thanks,
Okash

On Sat, Nov 12, 2016 at 10:18 PM, Samuel Thibault <

Post by Okash Khawaja

Post by Okash Khawaja
Could you explain your idea a bit more? I have been reading the driver

code and

Post by Okash Khawaja
want to contribute to this project.

Just copy/pasting some previous thoughts. The idea would be to make
speakup a tty line discipline, just like it is for a mouse, ppp, etc.
“
land? One of the goals of speakup is to be available before userland
works (otherwise we could as well just move the drivers to userland), so
we don't have any userland helper to set the line disciline up.
And even before setting up the line discipline, how can speakup open
the port? We don't have a process context or /dev/, so we can't just
use sys_open and alike. What we could use is some function which takes
a minor/major pair or a device name, and returns a filp, then we can
tty_set_ldisc(N_SPEAKUP) on file_tty(filp), but I don't know if such
thing exists? That would probably be building a struct inode (getting
struct inode *inode = new_inode(sb);
init_special_inode(inode, S_IFCHR, MKDEV(major, minor));
filp = get_empty_filp();
do_dentry_open(filp, inode, NULL, NULL);
struct tty_struct *tty = file_tty(filp);
tty_set_ldisc(tty, N_SPEAKUP);
”
Samuel

[Samuel Thibault]

Post by Okash Khawaja
1. speakup tty line discipline N_SPEAKUP
2. device /dev/ttyx
N_SPEAKUP is set as line discipline for /dev/ttyx. The challenge is enabling
speakup before userland.

That's the idea yes.

Post by Okash Khawaja
And how will /dev/ttyx be used?

It won't be used. As a line discipline speakup will plug higher in the
stack.

Post by Okash Khawaja
Also is there a link to where you pasted your idea from?

I wrote it.

Samuel

[Okash Khawaja]

On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <

Post by Okash Khawaja

Post by Okash Khawaja
1. speakup tty line discipline N_SPEAKUP
2. device /dev/ttyx
N_SPEAKUP is set as line discipline for /dev/ttyx. The challenge is

enabling

Post by Okash Khawaja
speakup before userland.

That's the idea yes.

Post by Okash Khawaja
And how will /dev/ttyx be used?

It won't be used. As a line discipline speakup will plug higher in the
stack.

Could you explain this more? May be a concrete example?

Post by Okash Khawaja

Post by Okash Khawaja
Also is there a link to where you pasted your idea from?

I wrote it.

Of course. I mean a link to full discussion to get more context.

Post by Okash Khawaja
Samuel

[John Covici]

What do you think of Dave Borowski's mods to speakup? He says he is
working on a driver to enable speakup to open any synth such as
usbserial, etc.? What are your thoughts on how to get this to work?

On Thu, 10 Nov 2016 11:10:32 -0500,

Post by Samuel Thibault

Post by Okash Khawaja
I am currently studying speakup's kernel code. Can someone guide me what is
it's current status?

It's currently in the staging part of the kernel, which is already a
good thing since it gets updated as the kernel API changes.

Post by Okash Khawaja
- What needs to be done in order to mainline it? I have read the TODO file but
not sure how up-to-date it is.

Its first item might be set to "update TODO" :)
About the "how to communicate with the serial ports" item, I do have
hints how it could be done, I just never got around finding the time to
hack it down.

Post by Okash Khawaja
- Are there existing plans to do work on the driver?

Not that I know of.

Post by Okash Khawaja
- Although the code is fairly readable, is there any documentation for the
driver?

Not that I know of.

Post by Okash Khawaja
Please add anything else you think is relevant.

Make sure to synchronize with the speakup list. Perhaps better
explicitly Cc us like you just did, to catch our eyes, I for instance
don't necessarily follow the speakup list that closely unfortunately.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]

Post by Okash Khawaja
And how will /dev/ttyx be used?

It won't be used. As a line discipline speakup will plug higher in the
stack.
Could you explain this more? May be a concrete example?
I mean is this something that a user space application will read from?

Normally what happens, for instance when running a serial mouse driver,
is that a userland program opens /dev/ttyS0, calls an ioctl to set the
N_MOUSE line discipline, and then leaves /dev/ttyS0 alone. All the work
is done by the line discipline, userland doesn't do any read/write on
the device. I.e. the line discipline catches the data before it reaches
userland.

If so, what is the specific advantage of speakup being line
discipline?

It's simply because that's the way things work for all other drivers
"over serial lines", like mice, joysticks ppp, gsm, etc. There is then
no risk for speakup to break at all, these have been working for decades
without a fuss. And they will work with anything that looks more or less
like a serial port, be it ISA, PCI, USB, bluetooth, irda, whatever.

Please add any links/documentation that will help
understand this. Thanks

Unfortunately line disciplines are a rather obscure area not many people
work on.

There is linux/Documentation/serial/tty.txt

Post by Okash Khawaja
Also is there a link to where you pasted your idea from?

I wrote it.
Of course. I mean a link to full discussion to get more context.

There is a thread starting here:

http://www.spinics.net/lists/linux-serial/msg21752.html

Samuel

[John G Heim]

Is that list, linux-serial, the place where most of the discussion on
the status of speakup goes on? I think part of the problem here is that
if you just go by what you hear on this list, you'd get the impression
that nothing is being done.

Post by Samuel Thibault

On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]

Post by Okash Khawaja
And how will /dev/ttyx be used?

It won't be used. As a line discipline speakup will plug higher in the
stack.
Could you explain this more? May be a concrete example?
I mean is this something that a user space application will read from?

Normally what happens, for instance when running a serial mouse driver,
is that a userland program opens /dev/ttyS0, calls an ioctl to set the
N_MOUSE line discipline, and then leaves /dev/ttyS0 alone. All the work
is done by the line discipline, userland doesn't do any read/write on
the device. I.e. the line discipline catches the data before it reaches
userland.

If so, what is the specific advantage of speakup being line
discipline?

It's simply because that's the way things work for all other drivers
"over serial lines", like mice, joysticks ppp, gsm, etc. There is then
no risk for speakup to break at all, these have been working for decades
without a fuss. And they will work with anything that looks more or less
like a serial port, be it ISA, PCI, USB, bluetooth, irda, whatever.

Please add any links/documentation that will help
understand this. Thanks

Unfortunately line disciplines are a rather obscure area not many people
work on.
There is linux/Documentation/serial/tty.txt

Post by Okash Khawaja
Also is there a link to where you pasted your idea from?

I wrote it.
Of course. I mean a link to full discussion to get more context.

http://www.spinics.net/lists/linux-serial/msg21752.html
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Samuel Thibault]

Hello,

Is that list, linux-serial, the place where most of the discussion on the
status of speakup goes on?

No, it was to raise the discussion on how it's supposed to plug.

Samuel

[Willem Venter]

Hi all.
Since I don't know anything about line discipline I did some searching
and found the following:
http://www.linux-mag.com/id/1891/
It is quite interesting. Not sure how up to date this is since it was
published in2005. Maybe with this combined with the kernel API updates
it might be useful to someone here. It details an example read-only
driver for a touch-screen, but the descriptions are quite general. It
mentions /dev, so maybe it's not exactly what is required, but it also
mentions examples in the kernel to look at.

Also see:
https://utcc.utoronto.ca/~cks/space/blog/unix/TTYLineDisciplineWhy

Post by Okash Khawaja
Hello,

Is that list, linux-serial, the place where most of the discussion on the
status of speakup goes on?

No, it was to raise the discussion on how it's supposed to plug.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

[Al Sten-Clanton]

This is just a quick thank you for the discussion and links on this
subject. Maybe over some good time I'll understand it, but for now I'm
glad for the pointers. I'm also glad to know that people are
considering this aspect of non-visual access and may be able to make it
work again.

Al

Post by Willem Venter
Hi all.
Since I don't know anything about line discipline I did some searching
http://www.linux-mag.com/id/1891/
It is quite interesting. Not sure how up to date this is since it was
published in2005. Maybe with this combined with the kernel API updates
it might be useful to someone here. It details an example read-only
driver for a touch-screen, but the descriptions are quite general. It
mentions /dev, so maybe it's not exactly what is required, but it also
mentions examples in the kernel to look at.
https://utcc.utoronto.ca/~cks/space/blog/unix/TTYLineDisciplineWhy

Post by Okash Khawaja
Hello,

Is that list, linux-serial, the place where most of the discussion on the
status of speakup goes on?

No, it was to raise the discussion on how it's supposed to plug.
Samuel
_______________________________________________
Speakup mailing list
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

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

[Samuel Thibault]

Post by Willem Venter
http://www.linux-mag.com/id/1891/
It is quite interesting. Not sure how up to date this is since it was
published in2005.

Things haven't really changed in that area of Linux in the past
decades, so it's probably very up to date.

Samuel

[Okash Khawaja]

Thanks Samuel. That email thread is helpful too. Appreciate your patience.

Post by Samuel Thibault

On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]

Post by Okash Khawaja
And how will /dev/ttyx be used?

It won't be used. As a line discipline speakup will plug higher in the
stack.
Could you explain this more? May be a concrete example?
I mean is this something that a user space application will read from?

Normally what happens, for instance when running a serial mouse driver,
is that a userland program opens /dev/ttyS0, calls an ioctl to set the
N_MOUSE line discipline, and then leaves /dev/ttyS0 alone. All the work
is done by the line discipline, userland doesn't do any read/write on
the device. I.e. the line discipline catches the data before it reaches
userland.

If so, what is the specific advantage of speakup being line
discipline?

It's simply because that's the way things work for all other drivers
"over serial lines", like mice, joysticks ppp, gsm, etc. There is then
no risk for speakup to break at all, these have been working for decades
without a fuss. And they will work with anything that looks more or less
like a serial port, be it ISA, PCI, USB, bluetooth, irda, whatever.

Please add any links/documentation that will help
understand this. Thanks

Unfortunately line disciplines are a rather obscure area not many people
work on.
There is linux/Documentation/serial/tty.txt

Post by Okash Khawaja
Also is there a link to where you pasted your idea from?

I wrote it.
Of course. I mean a link to full discussion to get more context.

http://www.spinics.net/lists/linux-serial/msg21752.html
Samuel