Status of kernel

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

Re: Status of kernel

[Samuel Thibault]

Okash Khawaja, on Thu 10 Nov 2016 15:02:21 +0000, wrote:
> 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.

> - 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.

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

Not that I know of.

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

Not that I know of.

> 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

Re: Status of kernel

[Okash Khawaja]

> On 10 Nov 2016, at 16:10, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> 
> Okash Khawaja, on Thu 10 Nov 2016 15:02:21 +0000, wrote:
>> 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.
> 
>> - 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.
> 
>> - Are there existing plans to do work on the driver?
> 
> Not that I know of.
> 
>> - Although the code is fairly readable, is there any documentation for the
>> driver?
> 
> Not that I know of.
> 
>> 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

Re: Status of kernel

[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,
Samuel Thibault wrote:
> 
> Okash Khawaja, on Thu 10 Nov 2016 15:02:21 +0000, wrote:
> > 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.
> 
> > - 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.
> 
> > - Are there existing plans to do work on the driver?
> 
> Not that I know of.
> 
> > - Although the code is fairly readable, is there any documentation for the
> > driver?
> 
> Not that I know of.
> 
> > 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
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Status of kernel

[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,
Samuel Thibault wrote:
> 
> Okash Khawaja, on Thu 10 Nov 2016 15:02:21 +0000, wrote:
> > 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.
> 
> > - 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.
> 
> > - Are there existing plans to do work on the driver?
> 
> Not that I know of.
> 
> > - Although the code is fairly readable, is there any documentation for the
> > driver?
> 
> Not that I know of.
> 
> > 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
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Status of kernel

[Samuel Thibault]

John Covici, on Thu 10 Nov 2016 20:35:02 -0500, wrote:
> 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

Re: Status of kernel

[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,
Samuel Thibault wrote:
> 
> John Covici, on Thu 10 Nov 2016 20:35:02 -0500, wrote:
> > 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

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Status of kernel

[Samuel Thibault]

Hello,

John Covici, on Fri 11 Nov 2016 05:59:23 -0500, wrote:
> On Fri, 11 Nov 2016 03:34:47 -0500,
> Samuel Thibault wrote:
> > 
> > John Covici, on Thu 10 Nov 2016 20:35:02 -0500, wrote:
> > > 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

Re: Status of kernel

[Samuel Thibault]

Samuel Thibault, on Fri 11 Nov 2016 17:27:50 +0100, wrote:
> John Covici, on Fri 11 Nov 2016 05:59:23 -0500, wrote:
> > 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
david.a.gborowski@gmail.com, david575@rogers.com, david575@golden.net
works, only david.a.borowski@gmail.com does.

Samuel

Re: Status of kernel

[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 <
samuel.thibault@ens-lyon.org> wrote:

> Samuel Thibault, on Fri 11 Nov 2016 17:27:50 +0100, wrote:
> > John Covici, on Fri 11 Nov 2016 05:59:23 -0500, wrote:
> > > 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
> david.a.gborowski@gmail.com, david575@rogers.com, david575@golden.net
> works, only david.a.borowski@gmail.com does.
>
> Samuel
>

Re: Status of kernel

[Samuel Thibault]

Okash Khawaja, on Sat 12 Nov 2016 15:20:48 +0000, wrote:
> 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

Re: Status of kernel

[Okash Khawaja]

On Sat, Nov 12, 2016 at 3:47 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Okash Khawaja, on Sat 12 Nov 2016 15:20:48 +0000, wrote:
> > 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.

Re: Status of kernel

[Samuel Thibault]

Okash Khawaja, on Sat 12 Nov 2016 16:13:22 +0000, wrote:
> 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

Re: Status of kernel

[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?




On 11/12/2016 04:18 PM, Samuel Thibault wrote:
> Okash Khawaja, on Sat 12 Nov 2016 16:13:22 +0000, wrote:
>> 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
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

Re: Status of kernel

[Samuel Thibault]

John G. Heim, on Sun 13 Nov 2016 16:05:53 -0600, wrote:
> 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

Re: Status of kernel

[John G. Heim]

Well, that's discrimination.



On 11/13/2016 04:11 PM, Samuel Thibault wrote:
> John G. Heim, on Sun 13 Nov 2016 16:05:53 -0600, wrote:
>> 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

Re: Status of kernel

[Samuel Thibault]

John G. Heim, on Sun 13 Nov 2016 16:25:22 -0600, wrote:
> 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

Re: Status of kernel

[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


On 11/13/2016 05:11 PM, Samuel Thibault wrote:
> John G. Heim, on Sun 13 Nov 2016 16:05:53 -0600, wrote:
>> 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
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: Status of kernel

[Samuel Thibault]

Al Sten-Clanton, on Tue 15 Nov 2016 12:07:32 -0500, wrote:
>  Would it wreck the kernel or something?

Yes.

> Alternatively, is using usb prots not a good option?

It's exactly the same issue.

Samuel

Re: Status of kernel

[John G Heim]

On 11/15/2016 11:13 AM, Samuel Thibault wrote:
> Al Sten-Clanton, on Tue 15 Nov 2016 12:07:32 -0500, wrote:
>>   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?

Re: Status of kernel

[Samuel Thibault]

John G Heim, on Tue 15 Nov 2016 12:26:45 -0600, wrote:
> On 11/15/2016 11:13 AM, Samuel Thibault wrote:
> >Al Sten-Clanton, on Tue 15 Nov 2016 12:07:32 -0500, wrote:
> >>  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

Re: Status of kernel

[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.




On 11/15/2016 11:07 AM, Al Sten-Clanton wrote:
> 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
>
>
> On 11/13/2016 05:11 PM, Samuel Thibault wrote:
>> John G. Heim, on Sun 13 Nov 2016 16:05:53 -0600, wrote:
>>> 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
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Status of kernel

[Samuel Thibault]

John G Heim, on Tue 15 Nov 2016 12:16:26 -0600, wrote:
> 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

Re: Status of kernel

[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.




On 11/15/2016 12:41 PM, Samuel Thibault wrote:
> John G Heim, on Tue 15 Nov 2016 12:16:26 -0600, wrote:
>> 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; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Status of kernel

[Samuel Thibault]

John G Heim, on Tue 15 Nov 2016 13:12:49 -0600, wrote:
> 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

Re: Status of kernel

[Rob]

John G. Heim <jheim@math.wisc.edu> wrote:
> 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?

Re: Status of kernel

[Samuel Thibault]

Rob, on Sun 13 Nov 2016 16:12:27 -0600, wrote:
> John G. Heim <jheim@math.wisc.edu> wrote:
> > 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

Re: Status of kernel

[Gregory Nowak]

On Sun, Nov 13, 2016 at 04:12:27PM -0600, Rob wrote:
> How does BRLTTY do it? Can we implement similar code?

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

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-manager@EU.org

Re: Status of kernel

[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 <
samuel.thibault@ens-lyon.org> wrote:

> Okash Khawaja, on Sat 12 Nov 2016 16:13:22 +0000, wrote:
> > 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
>

Re: Status of kernel

[Samuel Thibault]

Okash Khawaja, on Tue 15 Nov 2016 06:23:53 +0000, wrote:
> 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.

> And how will /dev/ttyx be used?

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

> Also is there a link to where you pasted your idea from?

I wrote it.

Samuel

Re: Status of kernel

[Okash Khawaja]

On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Okash Khawaja, on Tue 15 Nov 2016 06:23:53 +0000, wrote:
> > 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.
>
> > 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?


>
> > 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.


> Samuel
>

Re: Status of kernel

[Samuel Thibault]

Okash Khawaja, on Tue 15 Nov 2016 06:58:24 +0000, wrote:
>     On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]
>     samuel.thibault@ens-lyon.org> wrote:
>         > 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

>         > 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

Re: Status of kernel

[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.





On 11/15/2016 12:47 PM, Samuel Thibault wrote:
> Okash Khawaja, on Tue 15 Nov 2016 06:58:24 +0000, wrote:
>>      On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]
>>      samuel.thibault@ens-lyon.org> wrote:
>>          > 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
>
>>          > 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
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org

Re: Status of kernel

[Samuel Thibault]

Hello,

John G Heim, on Tue 15 Nov 2016 13:31:36 -0600, wrote:
> 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

Re: Status of kernel

[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



On 11/15/16, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> Hello,
>
> John G Heim, on Tue 15 Nov 2016 13:31:36 -0600, wrote:
>> 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
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: Status of kernel

[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

On 11/15/2016 04:08 PM, Willem Venter wrote:
> 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
>
>
>
> On 11/15/16, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
>> Hello,
>>
>> John G Heim, on Tue 15 Nov 2016 13:31:36 -0600, wrote:
>>> 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
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: Status of kernel

[Samuel Thibault]

Willem Venter, on Tue 15 Nov 2016 23:08:01 +0200, wrote:
> 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

Re: Status of kernel

[Okash Khawaja]

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

> On 15 Nov 2016, at 18:47, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> 
> Okash Khawaja, on Tue 15 Nov 2016 06:58:24 +0000, wrote:
>>    On Tue, Nov 15, 2016 at 6:36 AM, Samuel Thibault <[2]
>>    samuel.thibault@ens-lyon.org> wrote:
>>> 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
> 
>>> 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