the push to get rid of CONFIG_VT in the kernel and the future of Speakup

the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

As seen on Slashdot:

<quote>
An anonymous reader writes: The next version of systemd is poised to introduce
{an experimental "systemd-consoled"
that serves as a user-space console daemon}.
The consoled furthers the Linux developers' goal of eventually deprecating the
VT subsystem found within the Linux kernel in favor of a user-space driven
terminal that supports better localization, increased security,
and greater robustness of {the kernel's seldom touched and hairy
CONFIG_VT'ed code}.
</quote>

Taken from:
http://linux.slashdot.org/story/14/10/08/134208/systemd-adding-its-own-console-to-linux-systems

This is an interesting development, and I've been expecting it for a
long time in some form.
See, for example, the following proposal from 2003:
http://homepage.ntlworld.com/jonathan.deboynepollard/Proposals/linux-console-daemon.html
So I'm pretty sure that the future of the Linux console will be in user
space.  Thoughts?

PS.  The integration into systemd is irrelevant.  The original work
started outside of that project.  So I'm hoping this *won't* turn into a
discussion about systemd, a very divisive issue which evokes strong
feelings on both sides...

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Deedra Waters]

I love speakup but i think here is where maybe we a look at helping with
yasr to make it a better screenreader, b, help with brltty and improve
it's screen reader functions, or c, just reinvent the wheel. Personally
it might be worth improving on the existing screen readers like brltty
or yasr 
-- 
Website: http://deedra.the-brannons.com
blog: http://deedra.the-brannons.com/blog

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Hart Larry]

Well Deedra-and-All, while I know next2nothing about kernels, as a user of 
practicly an only Linux screen-reader which I can use with my Dec-Talk U S B, on 
1 large hand, durring the last 11years, I am greatful that Speakup was created, 
but on another hand, I really miss much of the customination which I had with 
Vocal-Eyes in DOS, where I could completely configure 3 different dictionaries, 
so I had complete controll of how characters, keystrokes, and words were 
read-and-pronounced.
I think its been several years since YASR was updated-and-Mike was unable to get 
it running in my DecTalk unit. I suppose in a certain way, Emacspeak is an only 
other example of a non-commercial solution in Linux, as where NVDA on the 
windows side has received seemingly great exceptance, but in general when you 
have a commercial product, there are more features, more development, and 
certainly more interaction among users-and-staff.
Quite some months ago Kirk took an informal servey of improvements which we were 
interested in-and-there was going to be some sort of live chatt. Thanks for 
listening
Hart

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Brian Buhrow]

	hello.  My two cents is that it's worth developing Yasr further.  Yasr
runs on any version of Unix, in fact I use it every day on NetBSD systems
and am typing this message from a Yasr equipped NetBSD system.  I find Yasr
to be stable, responsive and quite functional.  In fact, for me, it just
gets out of the way and lets me get my job done.
-thanks
-Brian

On Oct 8, 12:25pm, Deedra Waters wrote:
} Subject: Re: the push to get rid of CONFIG_VT in the kernel and the future
} SSBsb3ZlIHNwZWFrdXAgYnV0IGkgdGhpbmsgaGVyZSBpcyB3aGVyZSBtYXliZSB3ZSBhIGxvb2sg
} YXQgaGVscGluZyB3aXRoCnlhc3IgdG8gbWFrZSBpdCBhIGJldHRlciBzY3JlZW5yZWFkZXIsIGIs
} IGhlbHAgd2l0aCBicmx0dHkgYW5kIGltcHJvdmUKaXQncyBzY3JlZW4gcmVhZGVyIGZ1bmN0aW9u
} cywgb3IgYywganVzdCByZWludmVudCB0aGUgd2hlZWwuIFBlcnNvbmFsbHkKaXQgbWlnaHQgYmUg
} d29ydGggaW1wcm92aW5nIG9uIHRoZSBleGlzdGluZyBzY3JlZW4gcmVhZGVycyBsaWtlIGJybHR0
} eQpvciB5YXNyIAotLSAKV2Vic2l0ZTogaHR0cDovL2RlZWRyYS50aGUtYnJhbm5vbnMuY29tCmJs
} b2c6IGh0dHA6Ly9kZWVkcmEudGhlLWJyYW5ub25zLmNvbS9ibG9nCgpfX19fX19fX19fX19fX19f
} X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpTcGVha3VwIG1haWxpbmcgbGlzdApTcGVh
} a3VwQGxpbnV4LXNwZWFrdXAub3JnCmh0dHA6Ly9saW51eC1zcGVha3VwLm9yZy9jZ2ktYmluL21h
} aWxtYW4vbGlzdGluZm8vc3BlYWt1cAo=
>-- End of excerpt from Deedra Waters

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Igor Gueths]

Yeah Yasr could definitely use some TLC, it'll be interesting to see what the
kernel devs do as far as providing an I/O event interface for something like a
userspace screen reader to attach to. Also not sure what it would take to migrate
Speakup to such an interface, as I have unfortunately lacked time to poke at it
in any great depth for a bit now.
On Wed, Oct 08, 2014 at 12:25:13PM -0700, Deedra Waters wrote:
> I love speakup but i think here is where maybe we a look at helping with
> yasr to make it a better screenreader, b, help with brltty and improve
> it's screen reader functions, or c, just reinvent the wheel. Personally
> it might be worth improving on the existing screen readers like brltty
> or yasr 
> -- 
> Website: http://deedra.the-brannons.com
> blog: http://deedra.the-brannons.com/blog
> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-- 
Igor

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

It does appear to me that something like this will force more of Speakup
into userspace. However, unlike others, I'm not entirely opposed to the
idea of Speakup leaving the kernel, and I think it can only be a good
thing, especially on newer machines, where dedicated serial ports are
all but obsolete, and software in userspace can take better advantage of
things like Pulseaudio and libusb, meaning more extensive software and
hardware speech support. For example, there would no longer be a need
for kernel modules to control speech synthesizers, and there would no
longer be a need to have external userspace connectors such as Espeakup,
as the entire Speakup screen reader could be moved into userspace, and
anything that interfaces with a speech synthesizer could be either
internal or could be a library that interfaces with a speech API like
speech-dispatcher or others. Even better, if Speakup is moved entirely
into userspace, it could give rise to far better access to consoles on
*BSD and other Unix operating systems, as the code could be far more
portable between operating systems when it doesn't have to be tied into
a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Al Sten-Clanton]

My knowledge of this business is minimal, but I thought that one 
advantage of the current approach, if you can use a hardware speech 
synthesizer, is that you can get at least some of the boot-up 
messages--not as early as sighted folks get them, but well before 
software speech can kick in.  If this is true, wouldn't the proposed 
change be a very builty-in reduction in non-visual access?

Al

On 10/08/2014 03:43 PM, Kyle wrote:
> It does appear to me that something like this will force more of Speakup
> into userspace. However, unlike others, I'm not entirely opposed to the
> idea of Speakup leaving the kernel, and I think it can only be a good
> thing, especially on newer machines, where dedicated serial ports are
> all but obsolete, and software in userspace can take better advantage of
> things like Pulseaudio and libusb, meaning more extensive software and
> hardware speech support. For example, there would no longer be a need
> for kernel modules to control speech synthesizers, and there would no
> longer be a need to have external userspace connectors such as Espeakup,
> as the entire Speakup screen reader could be moved into userspace, and
> anything that interfaces with a speech synthesizer could be either
> internal or could be a library that interfaces with a speech API like
> speech-dispatcher or others. Even better, if Speakup is moved entirely
> into userspace, it could give rise to far better access to consoles on
> *BSD and other Unix operating systems, as the code could be far more
> portable between operating systems when it doesn't have to be tied into
> a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
> ~Kyle
> http://kyle.tk/
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[covici]

That is what I think as well -- and most motherboards do have serial
ports, just the headers are not brought out to the back.  
Al Sten-Clanton <albert.e.sten_clanton@verizon.net> wrote:

> My knowledge of this business is minimal, but I thought that one
> advantage of the current approach, if you can use a hardware speech
> synthesizer, is that you can get at least some of the boot-up
> messages--not as early as sighted folks get them, but well before
> software speech can kick in.  If this is true, wouldn't the proposed
> change be a very builty-in reduction in non-visual access?
> 
> Al
> 
> On 10/08/2014 03:43 PM, Kyle wrote:
> > It does appear to me that something like this will force more of Speakup
> > into userspace. However, unlike others, I'm not entirely opposed to the
> > idea of Speakup leaving the kernel, and I think it can only be a good
> > thing, especially on newer machines, where dedicated serial ports are
> > all but obsolete, and software in userspace can take better advantage of
> > things like Pulseaudio and libusb, meaning more extensive software and
> > hardware speech support. For example, there would no longer be a need
> > for kernel modules to control speech synthesizers, and there would no
> > longer be a need to have external userspace connectors such as Espeakup,
> > as the entire Speakup screen reader could be moved into userspace, and
> > anything that interfaces with a speech synthesizer could be either
> > internal or could be a library that interfaces with a speech API like
> > speech-dispatcher or others. Even better, if Speakup is moved entirely
> > into userspace, it could give rise to far better access to consoles on
> > *BSD and other Unix operating systems, as the code could be far more
> > portable between operating systems when it doesn't have to be tied into
> > a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
> > ~Kyle
> > http://kyle.tk/
> >
> _______________________________________________
> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Gregory Nowak]

When the serial port question comes up, someone always points out that
the headers for a serial port are still there, even though the actual
outside db-9/db-25 port isn't there. Unfortunately, this assumption
seems to be geared to desktop users. What about those of us using
laptops, and said laptop doesn't have pc-express/pcmcia? From this
point of view, moving speakup into user space at least partly has
advantages. This is especially true since the way things are now, I
can't connect a hardware synthesizer to my laptop anyway. On the other
hand, having speakup in user space would mean that I could use a usb
to serial converter.

I'm sure there are more of us in a similar situation, not just yours
truly. Ideally, speakup should support as many hardware configurations
as possible. Standard serial ports should be supported, as well as
non-standard ports. Some of you may recall I still have a machine here
with a doubletalk PC installed in a ISA slot. Ideally, I would like to
be able to keep using my doubletalk if possible.

One more thing to consider. Back when speakup first came out, kernels
weren't as modularized as they are now (more modules were built-in),
and initial ramdisks weren't as big as they are now (assuming they
were used in something other than install media. I first started with
GNU/linux using slackware 7.1. From what I recall (and I could be
wrong), when the system was installed, there was no initrd, all the
modules needed to mount the root FS were in the kernel. In such a
situation, having speakup be part of the kernel was a must. Nowadays,
I don't know of any distribution which doesn't create a initial
ramdisk as part of the install process. So, the only situation where
having speakup be a part of the kernel is if someone is building a
custom kernel, and including everything needed for booting into the
kernel without an initial ramdisk. How many of us here still do that?
My guess is very few of us if any.

I am not saying speakup should be moved out of the kernel. I'm merely
gently suggesting that the case for keeping speakup fully in kernel
space isn't as strong as it once was. It does seem to me though like
there just might be more advantages to putting at least part of
speakup into user space today. Ok, that's my $0.01 worth.

Greg


On Wed, Oct 08, 2014 at 04:26:09PM -0400, covici@ccs.covici.com wrote:
> That is what I think as well -- and most motherboards do have serial
> ports, just the headers are not brought out to the back.  


-- 
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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

Well, there is a significant difference between your problem and that 
which is solved with the header block on the motherboard. I am 
responsible for several servers that weren't bought at my request. I had 
nothing to do with the purchase of the hardware yet I have to keep them 
operating. I am going to say that is a fairly common phenomena in the 
sys admin world. Every time you switch jobs or even get a promotion, you 
are going to be responsible for computers you didn't spec out.  I've 
already installed 2 of those converters so I could use my hardware synth 
with these machines.

So I think it would depend on why you want to use a hardware synth with 
your laptop. Is that a choice or something you absolutely have to do? 
The linux kernel developers aren't ethically obligated to be all things 
to all people. They couldn't do that even if they tried. But I am 
suggesting that they do have an ethical obligation to try very hard not 
to do something that would cost a blind sys admin his job. I understand 
that it may be impossible for them to avoid it in this case. But that 
decision should not be made lightly.

PS: I am not really talking about myself personally. I am about as 
secure in my job as I can be. I'm just assuming other blind sys admins 
have jobs similar to mine.  Here at the University of Wisconsin, there 
are a lot of linux systems admin jobs. And for the majority of them, it 
would be a big problem if you couldn't access the boot messages.

On 10/08/14 21:18, Gregory Nowak wrote:
> When the serial port question comes up, someone always points out that
> the headers for a serial port are still there, even though the actual
> outside db-9/db-25 port isn't there. Unfortunately, this assumption
> seems to be geared to desktop users. What about those of us using
> laptops, and said laptop doesn't have pc-express/pcmcia? From this
> point of view, moving speakup into user space at least partly has
> advantages. This is especially true since the way things are now, I
> can't connect a hardware synthesizer to my laptop anyway. On the other
> hand, having speakup in user space would mean that I could use a usb
> to serial converter.
>
> I'm sure there are more of us in a similar situation, not just yours
> truly. Ideally, speakup should support as many hardware configurations
> as possible. Standard serial ports should be supported, as well as
> non-standard ports. Some of you may recall I still have a machine here
> with a doubletalk PC installed in a ISA slot. Ideally, I would like to
> be able to keep using my doubletalk if possible.
>
> One more thing to consider. Back when speakup first came out, kernels
> weren't as modularized as they are now (more modules were built-in),
> and initial ramdisks weren't as big as they are now (assuming they
> were used in something other than install media. I first started with
> GNU/linux using slackware 7.1. From what I recall (and I could be
> wrong), when the system was installed, there was no initrd, all the
> modules needed to mount the root FS were in the kernel. In such a
> situation, having speakup be part of the kernel was a must. Nowadays,
> I don't know of any distribution which doesn't create a initial
> ramdisk as part of the install process. So, the only situation where
> having speakup be a part of the kernel is if someone is building a
> custom kernel, and including everything needed for booting into the
> kernel without an initial ramdisk. How many of us here still do that?
> My guess is very few of us if any.
>
> I am not saying speakup should be moved out of the kernel. I'm merely
> gently suggesting that the case for keeping speakup fully in kernel
> space isn't as strong as it once was. It does seem to me though like
> there just might be more advantages to putting at least part of
> speakup into user space today. Ok, that's my $0.01 worth.
>
> Greg
>
>
> On Wed, Oct 08, 2014 at 04:26:09PM -0400, covici@ccs.covici.com wrote:
>> That is what I think as well -- and most motherboards do have serial
>> ports, just the headers are not brought out to the back.
>
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

"John G. Heim" <jheim@math.wisc.edu> writes:

> Here at the University of Wisconsin, there
> are a lot of linux systems admin jobs. And for the majority of them,
> it would be a big problem if you couldn't access the boot messages.

Is the serial console support not appropriate / acceptable?
When I first started out with Linux, I had a Braille 'n Speak, and I
used it as a dumb terminal.  If I started the serial console at boot, I
got to see all of the boot messages from the kernel, regardless of
whether I had Speakup.  It's not really a good way to work, when
compared to Speakup, but for tasks such as diagnosing boot failures, it
was usable.
If I worked professionally as an on-site sysadmin, I might try to
do something similar today.  The BNS isn't manufactured any more, but
I'm sure there's something that would work as well.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[covici]

What I have done in those cases is to hook up another computer with a
null modem cable and use the terminal program in that computer to read
the output where I wuld say console=0 on the command line to redirect
the output.  However, speakup built in catches a lot.

Chris Brannon <chris@the-brannons.com> wrote:

> "John G. Heim" <jheim@math.wisc.edu> writes:
> 
> > Here at the University of Wisconsin, there
> > are a lot of linux systems admin jobs. And for the majority of them,
> > it would be a big problem if you couldn't access the boot messages.
> 
> Is the serial console support not appropriate / acceptable?
> When I first started out with Linux, I had a Braille 'n Speak, and I
> used it as a dumb terminal.  If I started the serial console at boot, I
> got to see all of the boot messages from the kernel, regardless of
> whether I had Speakup.  It's not really a good way to work, when
> compared to Speakup, but for tasks such as diagnosing boot failures, it
> was usable.
> If I worked professionally as an on-site sysadmin, I might try to
> do something similar today.  The BNS isn't manufactured any more, but
> I'm sure there's something that would work as well.
> 
> -- Chris
> _______________________________________________
> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

On 10/09/14 09:32, Chris Brannon wrote:
> "John G. Heim" <jheim@math.wisc.edu> writes:
>
>> Here at the University of Wisconsin, there
>> are a lot of linux systems admin jobs. And for the majority of them,
>> it would be a big problem if you couldn't access the boot messages.
>
> Is the serial console support not appropriate / acceptable?


Well, I brought this up myself in another message. I would indeed 
consider it adequate ifa blind sys admin could get access to the boot 
messages via the serial console. But I'd like to know with absolute 
certainty that the proposed change to the linux kernel wouldn't also 
effect a serial console.

I am not a kernel developer but it doesn't make sense to me that 
something that would force speakup out of kernel space wouldln't also 
force a serial console out of  kernel space. In  which case, how is it 
going to get boot messages? As a technical issue, what's the difference 
between speakup and a serial console? Why is one so bad and the other 
one okay?

This is another example of some questions I asked on the kernel 
developers list and didn't get satisfactory answers. But I suspect that 
the answer is that the serial console was once in common use in the 
linux/unix community and speakup is not. Serial consoles are familiar 
and speakup is not.

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

"John G. Heim" <jheim@math.wisc.edu> writes:

> On 10/09/14 09:32, Chris Brannon wrote:
>> "John G. Heim" <jheim@math.wisc.edu> writes:
>>
>>> Here at the University of Wisconsin, there
>>> are a lot of linux systems admin jobs. And for the majority of them,
>>> it would be a big problem if you couldn't access the boot messages.
>>
>> Is the serial console support not appropriate / acceptable?
>
>
> But I'd like to know with absolute
> certainty that the proposed change to the linux kernel wouldn't also
> effect a serial console.

Well, I can't give you absolute certainty, but I suspect that the
kernel support for serial consoles is here to stay.  Part of the
difference is the amount of code.  The virtual console subsystem is a
lot more complicated than the simple serial console used for boot
messages, because it has to provide a full VT100 terminal
emulator in kernelspace.  On the other hand, the serial console doesn't
have to emulate anything, since the thing on the other end of the cable
is a real terminal of some sort.  All it has to do is blast the kernel
messages out the serial port.  So the main difference is
complexity.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Gregory Nowak]

On Thu, Oct 09, 2014 at 09:08:54AM -0500, John G. Heim wrote:
> Well, there is a significant difference between your problem and
> that which is solved with the header block on the motherboard. I am
> responsible for several servers that weren't bought at my request. I
> had nothing to do with the purchase of the hardware yet I have to
> keep them operating. I am going to say that is a fairly common
> phenomena in the sys admin world. Every time you switch jobs or even
> get a promotion, you are going to be responsible for computers you
> didn't spec out.

Naturally.

> So I think it would depend on why you want to use a hardware synth
> with your laptop. Is that a choice or something you absolutely have
> to do?

It's something I'd like to be able to do, but not strictly necessary.

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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

According to Al Sten-Clanton:
# My knowledge of this business is minimal, but I thought that one
# advantage of the current approach, if you can use a hardware speech
# synthesizer, is that you can get at least some of the boot-up
# messages--not as early as sighted folks get them, but well before
# software speech can kick in.  If this is true, wouldn't the proposed
# change be a very builty-in reduction in non-visual access?

This was a lot more true in the early days of Linux than it is now.
Computers have evolved to the point where most of them, especially home
computers, no longer have dedicated serial ports, which is the only type
of port over which Speakup is able to communicate with a hardware speech
synthesizer. To add to the problem, very few hardware speech
synthesizers are currently being made these days, and those that are
still being produced only have a USB interface. So in order to take
advantage of receiving every kernel message from startup to shutdown,
one must have an old computer or a server, as well as an old hardware
synthesizer purchased used, probably something like an old DECTalk
Express, accent SA, DoubleTalk LT, etc. And sadly no, a USB to serial
converter will not solve the problem of getting a serial port onto a
laptop or most desktop computers, as Speakup has no knowledge of this
type of device, nor does it know how to communicate through it, as I
believe it has to be enumerated by udev or similar, meaning it isn't
*always* going to have the name /dev/ttyS1 or /dev/ttyS2 or similar. I
hope this answers your question.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Al Sten-Clanton]

My follow-up question, then, is whether it's possible to revise Speakup 
to work as well with USB ports as it does with serial ports.  (I know 
that whether somebody would have the time to do it is another matter.)

Al

On 10/08/2014 04:32 PM, Kyle wrote:
> According to Al Sten-Clanton:
> # My knowledge of this business is minimal, but I thought that one
> # advantage of the current approach, if you can use a hardware speech
> # synthesizer, is that you can get at least some of the boot-up
> # messages--not as early as sighted folks get them, but well before
> # software speech can kick in.  If this is true, wouldn't the proposed
> # change be a very builty-in reduction in non-visual access?
>
> This was a lot more true in the early days of Linux than it is now.
> Computers have evolved to the point where most of them, especially home
> computers, no longer have dedicated serial ports, which is the only type
> of port over which Speakup is able to communicate with a hardware speech
> synthesizer. To add to the problem, very few hardware speech
> synthesizers are currently being made these days, and those that are
> still being produced only have a USB interface. So in order to take
> advantage of receiving every kernel message from startup to shutdown,
> one must have an old computer or a server, as well as an old hardware
> synthesizer purchased used, probably something like an old DECTalk
> Express, accent SA, DoubleTalk LT, etc. And sadly no, a USB to serial
> converter will not solve the problem of getting a serial port onto a
> laptop or most desktop computers, as Speakup has no knowledge of this
> type of device, nor does it know how to communicate through it, as I
> believe it has to be enumerated by udev or similar, meaning it isn't
> *always* going to have the name /dev/ttyS1 or /dev/ttyS2 or similar. I
> hope this answers your question.
> ~Kyle
> http://kyle.tk/
>

Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Cleverson Casarin Uliana]

Guys,

There already exists a console screen reader running on the users space, 
it is very configurable and is able to replace speakup for quite most 
tasks, especially with pure command line programs but also for some 
NCurses applications. It's Jupiter, developed by Karl Dahlke. I don't 
know why he doesn't advertise it more, but here it is:
https://github.com/eklhad/acsint
Cheers
Cleverson

Re: Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

Cleverson Casarin Uliana <clcaul@gmail.com> writes:

> There already exists a console screen reader running on the users
> space, it is very configurable and is able to replace speakup for
> quite most tasks, especially with pure command line programs but also
> for some NCurses applications. It's Jupiter, developed by Karl
> Dahlke.

It's mostly userspace, yes, but there's a tiny part that's still in the
kernel.  The kernel part just hooks into the same vt and keyboard
notifiers that Speakup uses, and forwards most of the real work to
userspace.  So if CONFIG_VT goes away, Jupiter will have the same
problem that Speakup will have.

- Chris

Re: Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

According to Chris Brannon:
# So if CONFIG_VT goes away, Jupiter will have the same problem that
# Speakup will have.

Not exactly the same problem, as all that would need to be done is for
Jupiter to hook into the new implementation in userspace. Because most
of Jupiter is already in userspace, it will have far less of a problem
than Speakup would have, as Speakup is still almost entirely in the
kernel, with the exception of the Speakupconf utility and the connectors
such as Espeakup and speechd-up.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Hart Larry]

Well Cleverson, thanks for mentioning Jupitor. Actually around 2004 or 5 when I 
got this DecTalk U S B Karl-and-I were on the phone, but he couldn't get me 
speech, although I did have it with an older DecPC. And yes, at least it had an 
exception dictionary. Actually orriginally when I did a search for something 
like, linux screen-readers dictionary   Jupitor came up. But for me the part 
which would be harder, Karl explains Jupitor is a "line reader" not a 
screen-reader. But having all those helpful progress sounds while its booting, 
well, those were nice.
Hart

Re: Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

Woe! Jupiter is still available? Last time I saw it anywhere, it was a
set of kernel modules much like Speakup, although the last time I saw it
anywhere was probably about 8 to 10 years ago. Is Jupiter entirely in
userspace now, and does it have software speech support, at least via
Espeak? Depending on how well it works, it could be great for those
people who need text console speech as well as Orca on the graphical
desktop.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: Jupiter rocks; was Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Cleverson Casarin Uliana]

Kyle: Jupiter itself is in user space, but it still depends on a kernel 
module called acsint for some processing. Yes it supports espeak with 
the help of the espeakup connector, which has a special mode called 
acsint mode, for working with jupiter. This feature is only available in 
the git version of espeakup.

Another nice kernel module made by Karl is ttyclicks, which generates 
clicks through the pc speaker so that one can work at the console 
without speech for easy tasks. Here I can for example upgrade the entire 
system without having to check every minute whether it has finished, I 
just need to notice when the clicks stop.

And yes jupiter has evolved much, I think Karl should advertise it more 
often. It allows for example to group a set of commands into a macro and 
assign it to a keystroke, it allows also to make different configuration 
files for each console so that you can customize the behavior of the 
reader for each console.

Greetings
Cleverson

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

According to Al Sten-Clanton:
# My follow-up question, then, is whether it's possible to revise Speakup
# to work as well with USB ports as it does with serial ports.  (I know
# that whether somebody would have the time to do it is another matter.)

I will leave the final answer to this question up to a kernel developer.
I do know that although there are indeed modules that work with specific
devices, i.e. device drivers that work with specific chips, speech
synthesizers generally don't fall into this category, as they usually
just take plain text + maybe some markup that they handle internally and
convert it into speech, in much the same way as a software speech
synthesizer does. So something in userspace that could communicate over
USB would be far more flexible and portable, and staying out of kernel
memory wherever possible is generally a good thing as well.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Samuel Thibault]

Al Sten-Clanton, le Wed 08 Oct 2014 19:53:01 -0400, a écrit :
> My follow-up question, then, is whether it's possible to revise Speakup to
> work as well with USB ports as it does with serial ports.  (I know that
> whether somebody would have the time to do it is another matter.)

It definitely is possible. It however needs some changes in the kernel
itself, not only speakup, and nobody has gotten the time to take up the
task up to now.

Samuel

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kelly Prescott]

I am not sure I am a fan of this upcoming change, but I believe we can 
find ways to continue without much more inconvenience than we already 
have.
First, I agree with Brian, I never install speakup on a server I manage, 
and I manage lots of them.
They are all managed through the network.
Second, I actually see a possible advantage in the systemd interface as it 
does lots of detailed logging of the boot process.
I think we have all known for years that the hardware synthesizers are 
going the way of the land-line telephone... ;) <smiles>
With that said, however, I have a few thoughts:
1:  either use yasr or rewrite speakup to be in userspace.
2:  Take Chris's idea of a ramdisk approach and maybe write a little thing 
for systemd to hold and either echo the boot messages or put them 
somewhere they can be read by the user.
Most distributions already place them in /var/log anyway.
3:  why not look at writing something to go with a UEFI boot loader to 
speak the early boot screens.
I am not a UEFI expert, but it looks like it might be possible to get boot 
loaders to push text out a serial port or maybe a USB interface.
This would only leave a small gap between the loading of the kernel and 
enabling speech from the ramdisk.

I have done some checking and I get software speakup speech with systemd 
between 8 and 13 seconds into the boot.
The time difference is related to which distribution I use.

I welcome all thoughts or constructive criticism.

-- Kelly prescott


On Wed, 8 Oct 2014, Kyle wrote:

> According to Al Sten-Clanton:
> # My knowledge of this business is minimal, but I thought that one
> # advantage of the current approach, if you can use a hardware speech
> # synthesizer, is that you can get at least some of the boot-up
> # messages--not as early as sighted folks get them, but well before
> # software speech can kick in.  If this is true, wouldn't the proposed
> # change be a very builty-in reduction in non-visual access?
>
> This was a lot more true in the early days of Linux than it is now.
> Computers have evolved to the point where most of them, especially home
> computers, no longer have dedicated serial ports, which is the only type
> of port over which Speakup is able to communicate with a hardware speech
> synthesizer. To add to the problem, very few hardware speech
> synthesizers are currently being made these days, and those that are
> still being produced only have a USB interface. So in order to take
> advantage of receiving every kernel message from startup to shutdown,
> one must have an old computer or a server, as well as an old hardware
> synthesizer purchased used, probably something like an old DECTalk
> Express, accent SA, DoubleTalk LT, etc. And sadly no, a USB to serial
> converter will not solve the problem of getting a serial port onto a
> laptop or most desktop computers, as Speakup has no knowledge of this
> type of device, nor does it know how to communicate through it, as I
> believe it has to be enumerated by udev or similar, meaning it isn't
> *always* going to have the name /dev/ttyS1 or /dev/ttyS2 or similar. I
> hope this answers your question.
> ~Kyle
> http://kyle.tk/
> -- 
> "Kyle? ... She calls her cake, Kyle?"
> Out of This World, season 2 episode 21 - "The Amazing Evie"
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

Kelly Prescott writes:
> I think we have all known for years that the hardware synthesizers are going
> the way of the land-line telephone... ;) <smiles>
Ah, land line isn't going away--ever. Don't believe the cell phone
industry hype.

Take a look into any modern office and you'l find plenty land line
phones on desks all around.

But, don't forget to look in the back and notice they're lines are cat5 cables.

OK. I digress from an important conversation that I really should drop
my 2cents Bahamian Dollars into! <grin>

Janina

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

Maybe we should change the discussion toward trouble shooting techniques.

Suppose you are the one and only linux systems admin where you work. You 
come in one morning and there are 8 people at your office door saying 
they can't get to their email. You ping the email server and get 
nothing. What do you do next?

On 10/09/14 03:08, Kelly Prescott wrote:
> I am not sure I am a fan of this upcoming change, but I believe we can
> find ways to continue without much more inconvenience than we already have.
> First, I agree with Brian, I never install speakup on a server I manage,
> and I manage lots of them.
> They are all managed through the network.
> Second, I actually see a possible advantage in the systemd interface as
> it does lots of detailed logging of the boot process.
> I think we have all known for years that the hardware synthesizers are
> going the way of the land-line telephone... ;) <smiles>
> With that said, however, I have a few thoughts:
> 1:  either use yasr or rewrite speakup to be in userspace.
> 2:  Take Chris's idea of a ramdisk approach and maybe write a little
> thing for systemd to hold and either echo the boot messages or put them
> somewhere they can be read by the user.
> Most distributions already place them in /var/log anyway.
> 3:  why not look at writing something to go with a UEFI boot loader to
> speak the early boot screens.
> I am not a UEFI expert, but it looks like it might be possible to get
> boot loaders to push text out a serial port or maybe a USB interface.
> This would only leave a small gap between the loading of the kernel and
> enabling speech from the ramdisk.
>
> I have done some checking and I get software speakup speech with systemd
> between 8 and 13 seconds into the boot.
> The time difference is related to which distribution I use.
>
> I welcome all thoughts or constructive criticism.
>
> -- Kelly prescott
>
>
> On Wed, 8 Oct 2014, Kyle wrote:
>
>> According to Al Sten-Clanton:
>> # My knowledge of this business is minimal, but I thought that one
>> # advantage of the current approach, if you can use a hardware speech
>> # synthesizer, is that you can get at least some of the boot-up
>> # messages--not as early as sighted folks get them, but well before
>> # software speech can kick in.  If this is true, wouldn't the proposed
>> # change be a very builty-in reduction in non-visual access?
>>
>> This was a lot more true in the early days of Linux than it is now.
>> Computers have evolved to the point where most of them, especially home
>> computers, no longer have dedicated serial ports, which is the only type
>> of port over which Speakup is able to communicate with a hardware speech
>> synthesizer. To add to the problem, very few hardware speech
>> synthesizers are currently being made these days, and those that are
>> still being produced only have a USB interface. So in order to take
>> advantage of receiving every kernel message from startup to shutdown,
>> one must have an old computer or a server, as well as an old hardware
>> synthesizer purchased used, probably something like an old DECTalk
>> Express, accent SA, DoubleTalk LT, etc. And sadly no, a USB to serial
>> converter will not solve the problem of getting a serial port onto a
>> laptop or most desktop computers, as Speakup has no knowledge of this
>> type of device, nor does it know how to communicate through it, as I
>> believe it has to be enumerated by udev or similar, meaning it isn't
>> *always* going to have the name /dev/ttyS1 or /dev/ttyS2 or similar. I
>> hope this answers your question.
>> ~Kyle
>> http://kyle.tk/
>> --
>> "Kyle? ... She calls her cake, Kyle?"
>> Out of This World, season 2 episode 21 - "The Amazing Evie"
>> _______________________________________________
>> 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

trouble shooting, was: Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Gregory Nowak]

On Thu, Oct 09, 2014 at 09:23:51AM -0500, John G. Heim wrote:
> Maybe we should change the discussion toward trouble shooting techniques.
> 
> Suppose you are the one and only linux systems admin where you work.
> You come in one morning and there are 8 people at your office door
> saying they can't get to their email. You ping the email server and
> get nothing. What do you do next?

That depends. Is the e-mail server local, or remote in another part of
the country, or world? If local, does it have speakup installed, and
can it be physically accessed through a serial port/hardware synth,
software speech/no serial port, or both? If remote, do you have out of
band access to it which is accessible (I.E. not through VNC only)? If
there isn't out of band access (really bad idea for remote machine),
what is the procedure to gain access to it indirectly (I.E. call data
center support, or travel there)?

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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Brian Buhrow]

Date: Thu, 09 Oct 2014 09:23:51 -0500
From: "John G. Heim" <jheim@math.wisc.edu>

Maybe we should change the discussion toward trouble shooting techniques.

Suppose you are the one and only linux systems admin where you work. You 
come in one morning and there are 8 people at your office door saying 
they can't get to their email. You ping the email server and get 
nothing. What do you do next?


	Hello.  I've been a Unix sysadmin for over 20 years and I've never
worked with servers where I require Speakup in the kernel.  In addition,
I've been confronted with John's dilemma many times.  Here are some of the
ways I've tackled the problem, with various kinds of Unix and a wide
variety of machines:

1.  If the server has a serial port, even if it's not used as the console,
I keep a special version of bootable media around that will let me boot the
OS in an accessible form, using the serial port as console, thus giving me
the ability to look at the crashed system and find out what happened and
why it won't just reboot and run again.

2.  If the serial console is not an option, I can usually get the system to
come up  by simply rebooting it.  (most often, if it's not completely
crashed, logging in on the console without speech and shutting down
manually works while, if it is crashed, a power cycle will often do the
trick.)  Failing that, I usually can employ  a modification to option1
whereby I boot from alternate media which I know will get the network up
and running enough for me to get in and diagnos the issue that started this
chain of events.

3.  If those two options don't work, grabbing one of the 8 people banging
on the door saying their mail isn't working for 5 minutes and having them
serve as a 5 minute reader will usually tell me what's  wrong and how to go
about fixing it.  Sometimes it's a quick command that getts things going
and sometimes its more involved, but most of the time, if it is more
involved, I can do something quick to get me going independently, with the
reader's help, and take it from there.  When faced with this situation
where a large number of people are affected, I've rarely heard people
complain that I had to borrow their eyes for 5 minutes or that they wished
they could find someone who could fix things without their help.

	The most important thing I do, however, is try to plan for the
eventuality that John describes.  One of the ways I do that is to perform
system reboots when ever changes are made to the server that could affect
its ability to boot.  These reboots are performed under controlled
conditions and when I know I can get to the machine and get to it via one
of the methods described above.  This technique, combined with a very
conservative upgrade process, gives me a high degree of confidence when I
reboot a server that it will make it up enough to let me in via the network
and thus be able to fix any issues that might crop  up.

	I am a big fan of IPMI enabled servers and so, when possible, when
replacing a server, I'll advocate getting one that has IPMI capabilities.
this gives me access to almost all aspects of the server and, in fact, lets
me build it from many miles away in  most cases.  However, John's point
about not having IPMI available everywhere is well taken and most of my
experience is with environments where IPMI was not available.  Now that it
is more readily available, I embrace it fully and without reservation.  IPMI
has a learning curve, but it's well worth climbing and I recommend it
highly.

	There are those who will disagree with my choices and will have their
own way of doing things; that's ok.  What I wil  say, however, is that a
screen reader that works entirely in user space is a nice thing to have,
and, given the number of people we have working on and using Speakup versus
the number of people orking on and using more main stream portions of the
kernel, including the console driver, I think it's reasonable for folks to
be nervous about including Speakup in their production kernels.  Having a
user-space screen reader that's just as capable, or even more capable in
many cases than Speakup, would go a long way toward making folks feel
comfortable including it in their distros.  

	Many many machines today, including small embedded machines, don't hav
consoles available, even for sighted folks.  In most cases, the sighted
folks use tricks similar to mine to get access to crashed machines witout
consoles.  My point here is that the console, as we know it, is going away
and we, along with everyone else, need to learn how to deal with that new
reality.  One way is a user-space screen reader.  I use Yasr all day every
day, and hav done so for 7 years.  I like it and it works well for me.
There are folks here who don't like Yasr; that's ok too.  Having another
user-space screen reader available won't offend me and, in fact, I think it
would be a good thing to pursue.

-thanks
-Brian

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Deedra Waters]

I dont see it as a reduction in access in all i mean i guess there is to
some degree but the reality is that this change in the end reguardless
of wether it comes in systemd or some other form is they're going to end
up moving the console out of the kernel if they do this, well, you wont
have working speech to begin with so how is it a reduction in access if
we have no choice in the matter?


-- 
Website: http://deedra.the-brannons.com
blog: http://deedra.the-brannons.com/blog

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

Huh? Not having a choice doesn't mean it's not a reduction in access. 
That logic makes no sense what so ever. I mean, you could argue that we 
are stuck with it but that doesn't mean it won't hurt.



On 10/08/14 16:26, Deedra Waters wrote:
> I dont see it as a reduction in access in all i mean i guess there is to
> some degree but the reality is that this change in the end reguardless
> of wether it comes in systemd or some other form is they're going to end
> up moving the console out of the kernel if they do this, well, you wont
> have working speech to begin with so how is it a reduction in access if
> we have no choice in the matter?
>
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Mike Ray]

Personally I would hate to see Speakup disappear.  IMHO a Linux PC is
not truly accessible if the console is not accessible.





On 08/10/2014 22:43, John G. Heim wrote:
> Huh? Not having a choice doesn't mean it's not a reduction in access.
> That logic makes no sense what so ever. I mean, you could argue that we
> are stuck with it but that doesn't mean it won't hurt.
> 
> 
> 
> On 10/08/14 16:26, Deedra Waters wrote:
>> I dont see it as a reduction in access in all i mean i guess there is to
>> some degree but the reality is that this change in the end reguardless
>> of wether it comes in systemd or some other form is they're going to end
>> up moving the console out of the kernel if they do this, well, you wont
>> have working speech to begin with so how is it a reduction in access if
>> we have no choice in the matter?
>>
>>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup


-- 
Michael A. Ray
Analyst/Programmer
Witley, Surrey, South-east UK

The box said: 'install Windows XP, 7 or better'. So I installed Linux

Interested in accessibility on the Raspberry Pi?
Visit: http://www.raspberryvi.org/
>From where you can join our mailing list for visually-impaired Pi hackers

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Trevor Astrope]

I'm a blind sys admin and I've never installed speakup on a server. The 
servers I work with have lightsout management whereby I can get remote 
access to the console and get more than just bootup messages, but also the 
post messages and even interact with the bios on some hardware.

Granted, there is a bit of a gap between the time the kernel loads and the 
time the serial driver is loaded, but it hasn't prevented me from 
diagnosing issues that were preventing the system from booting.

At my current place of employment, the unix ops don't even work in the 
same city as the data center, nevermind the same building.

I'd be in favor of speakup in userspace if it meant speakup working with 
usb devices and pcie serial cards.


On Wed, 8 Oct 2014, John G. Heim wrote:

> Huh? Not having a choice doesn't mean it's not a reduction in access. That 
> logic makes no sense what so ever. I mean, you could argue that we are stuck 
> with it but that doesn't mean it won't hurt.
>
>
>
> On 10/08/14 16:26, Deedra Waters wrote:
>> I dont see it as a reduction in access in all i mean i guess there is to
>> some degree but the reality is that this change in the end reguardless
>> of wether it comes in systemd or some other form is they're going to end
>> up moving the console out of the kernel if they do this, well, you wont
>> have working speech to begin with so how is it a reduction in access if
>> we have no choice in the matter?
>> 
>> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

But I hope you're not  suggesting that losing access to boot messages in 
the kernel isn't a problem because we can all just get servers with 
lights out management. Or get jobs where you're not even in the same 
city as the hardware you service.

I think we should try not to say it's not a problem because it doesn't 
effect me. I really doubt that the majority of blind sys admins work 
primarily with servers with lights out managementor where the admin 
isn't even in the same city as the hardware. I work for the University 
of Wisconsin. Working for a university has an advantage for a blind 
systems admin in that they care more about quality than speed. There are 
a lot of linux systems admin jobs here. In fact, there was a position 
open for 6 months because they couldn't find a qualified candidate at 
the salary they were offering. But every one of the dozen or so jobs 
I've seen advertized in the past year was for an on-site guy. In fact, 
most of them were for jobs where you'd be the one and only linux admin.
On 10/08/14 17:52, Trevor Astrope wrote:
> I'm a blind sys admin and I've never installed speakup on a server. The
> servers I work with have lightsout management whereby I can get remote
> access to the console and get more than just bootup messages, but also
> the post messages and even interact with the bios on some hardware.
>
> Granted, there is a bit of a gap between the time the kernel loads and
> the time the serial driver is loaded, but it hasn't prevented me from
> diagnosing issues that were preventing the system from booting.
>
> At my current place of employment, the unix ops don't even work in the
> same city as the data center, nevermind the same building.
>
> I'd be in favor of speakup in userspace if it meant speakup working with
> usb devices and pcie serial cards.
>
>
> On Wed, 8 Oct 2014, John G. Heim wrote:
>
>> Huh? Not having a choice doesn't mean it's not a reduction in access.
>> That logic makes no sense what so ever. I mean, you could argue that
>> we are stuck with it but that doesn't mean it won't hurt.
>>
>>
>>
>> On 10/08/14 16:26, Deedra Waters wrote:
>>> I dont see it as a reduction in access in all i mean i guess there is to
>>> some degree but the reality is that this change in the end reguardless
>>> of wether it comes in systemd or some other form is they're going to end
>>> up moving the console out of the kernel if they do this, well, you wont
>>> have working speech to begin with so how is it a reduction in access if
>>> we have no choice in the matter?
>>>
>>>
>> _______________________________________________
>> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

Yeah, if you're a linux sysadmin, hardware speech is not some luxury you 
can do without.  It's not a matter of convenience, it's a matter of 
possible or not possible.

I know there are still some people who use speakup as their primary 
screen reader. But that user base has to be dwindling. In my opinion, 
the only reason that speakup remains a key part of the linux 
infrastructure is that it allows blind systems admins to get speech 
during boot. I think it would be understandible if they said you blind 
people will just have to  use the GUI if not for the fact that if you 
are a sys admin, you need those boot messages.

On 10/08/14 15:16, Al Sten-Clanton wrote:
> My knowledge of this business is minimal, but I thought that one
> advantage of the current approach, if you can use a hardware speech
> synthesizer, is that you can get at least some of the boot-up
> messages--not as early as sighted folks get them, but well before
> software speech can kick in.  If this is true, wouldn't the proposed
> change be a very builty-in reduction in non-visual access?
>
> Al
>
> On 10/08/2014 03:43 PM, Kyle wrote:
>> It does appear to me that something like this will force more of Speakup
>> into userspace. However, unlike others, I'm not entirely opposed to the
>> idea of Speakup leaving the kernel, and I think it can only be a good
>> thing, especially on newer machines, where dedicated serial ports are
>> all but obsolete, and software in userspace can take better advantage of
>> things like Pulseaudio and libusb, meaning more extensive software and
>> hardware speech support. For example, there would no longer be a need
>> for kernel modules to control speech synthesizers, and there would no
>> longer be a need to have external userspace connectors such as Espeakup,
>> as the entire Speakup screen reader could be moved into userspace, and
>> anything that interfaces with a speech synthesizer could be either
>> internal or could be a library that interfaces with a speech API like
>> speech-dispatcher or others. Even better, if Speakup is moved entirely
>> into userspace, it could give rise to far better access to consoles on
>> *BSD and other Unix operating systems, as the code could be far more
>> portable between operating systems when it doesn't have to be tied into
>> a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
>> ~Kyle
>> http://kyle.tk/
>>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Glenn]

Isn't SpeakUp used in the terminal after booting to a GUI?
----- Original Message ----- 
From: "John G. Heim" <jheim@math.wisc.edu>
To: "Speakup is a screen review system for Linux." 
<speakup@linux-speakup.org>
Sent: Wednesday, October 08, 2014 4:37 PM
Subject: Re: the push to get rid of CONFIG_VT in the kernel and the future 
of Speakup


Yeah, if you're a linux sysadmin, hardware speech is not some luxury you
can do without.  It's not a matter of convenience, it's a matter of
possible or not possible.

I know there are still some people who use speakup as their primary
screen reader. But that user base has to be dwindling. In my opinion,
the only reason that speakup remains a key part of the linux
infrastructure is that it allows blind systems admins to get speech
during boot. I think it would be understandible if they said you blind
people will just have to  use the GUI if not for the fact that if you
are a sys admin, you need those boot messages.

On 10/08/14 15:16, Al Sten-Clanton wrote:
> My knowledge of this business is minimal, but I thought that one
> advantage of the current approach, if you can use a hardware speech
> synthesizer, is that you can get at least some of the boot-up
> messages--not as early as sighted folks get them, but well before
> software speech can kick in.  If this is true, wouldn't the proposed
> change be a very builty-in reduction in non-visual access?
>
> Al
>
> On 10/08/2014 03:43 PM, Kyle wrote:
>> It does appear to me that something like this will force more of Speakup
>> into userspace. However, unlike others, I'm not entirely opposed to the
>> idea of Speakup leaving the kernel, and I think it can only be a good
>> thing, especially on newer machines, where dedicated serial ports are
>> all but obsolete, and software in userspace can take better advantage of
>> things like Pulseaudio and libusb, meaning more extensive software and
>> hardware speech support. For example, there would no longer be a need
>> for kernel modules to control speech synthesizers, and there would no
>> longer be a need to have external userspace connectors such as Espeakup,
>> as the entire Speakup screen reader could be moved into userspace, and
>> anything that interfaces with a speech synthesizer could be either
>> internal or could be a library that interfaces with a speech API like
>> speech-dispatcher or others. Even better, if Speakup is moved entirely
>> into userspace, it could give rise to far better access to consoles on
>> *BSD and other Unix operating systems, as the code could be far more
>> portable between operating systems when it doesn't have to be tied into
>> a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
>> ~Kyle
>> http://kyle.tk/
>>
> _______________________________________________
> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

You can switch to a character user interface and use speakup even after 
starting the graphical user interface. But as I said, I don't consider 
that a key part of the linux  accessibility infrastructure. Again, I 
understand some people prefer to use the character user interface full 
time. I could understand if the linux big shots said that was going to 
have to go away. But doing something that would make it impossible for 
blind people to have access to the boot messages that sighted people get 
-- that is unacceptable. Well, like somebody else said, we may have to 
accept it. But that would be very bad.

On 10/08/14 16:50, Glenn wrote:
> Isn't SpeakUp used in the terminal after booting to a GUI?
> ----- Original Message -----
> From: "John G. Heim" <jheim@math.wisc.edu>
> To: "Speakup is a screen review system for Linux."
> <speakup@linux-speakup.org>
> Sent: Wednesday, October 08, 2014 4:37 PM
> Subject: Re: the push to get rid of CONFIG_VT in the kernel and the future
> of Speakup
>
>
> Yeah, if you're a linux sysadmin, hardware speech is not some luxury you
> can do without.  It's not a matter of convenience, it's a matter of
> possible or not possible.
>
> I know there are still some people who use speakup as their primary
> screen reader. But that user base has to be dwindling. In my opinion,
> the only reason that speakup remains a key part of the linux
> infrastructure is that it allows blind systems admins to get speech
> during boot. I think it would be understandible if they said you blind
> people will just have to  use the GUI if not for the fact that if you
> are a sys admin, you need those boot messages.
>
> On 10/08/14 15:16, Al Sten-Clanton wrote:
>> My knowledge of this business is minimal, but I thought that one
>> advantage of the current approach, if you can use a hardware speech
>> synthesizer, is that you can get at least some of the boot-up
>> messages--not as early as sighted folks get them, but well before
>> software speech can kick in.  If this is true, wouldn't the proposed
>> change be a very builty-in reduction in non-visual access?
>>
>> Al
>>
>> On 10/08/2014 03:43 PM, Kyle wrote:
>>> It does appear to me that something like this will force more of Speakup
>>> into userspace. However, unlike others, I'm not entirely opposed to the
>>> idea of Speakup leaving the kernel, and I think it can only be a good
>>> thing, especially on newer machines, where dedicated serial ports are
>>> all but obsolete, and software in userspace can take better advantage of
>>> things like Pulseaudio and libusb, meaning more extensive software and
>>> hardware speech support. For example, there would no longer be a need
>>> for kernel modules to control speech synthesizers, and there would no
>>> longer be a need to have external userspace connectors such as Espeakup,
>>> as the entire Speakup screen reader could be moved into userspace, and
>>> anything that interfaces with a speech synthesizer could be either
>>> internal or could be a library that interfaces with a speech API like
>>> speech-dispatcher or others. Even better, if Speakup is moved entirely
>>> into userspace, it could give rise to far better access to consoles on
>>> *BSD and other Unix operating systems, as the code could be far more
>>> portable between operating systems when it doesn't have to be tied into
>>> a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
>>> ~Kyle
>>> http://kyle.tk/
>>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

John G. Heim writes:
> You can switch to a character user interface and use speakup even after
> starting the graphical user interface. But as I said, I don't consider that
> a key part of the linux  accessibility infrastructure.


I have to disagree strongly, John.

But, let me phrase my disagreement this way, is the console a key part
of Linux? Or shall we dump the console entirely in favor of a terminal
in the gui?

If the answer is that the console needs to stay, then we need console
based a11y.

Speaking for myself, I still spend most of my time in the console. I
don't care for Thunderbird. And, while I routinely use Firefox, I still
use Lynx more. I could go on, but I think I've made my point.

BTW: I also conduct most of my business phone calls from a Linux CLI SIP
client because this gives me far better latency and far better audio
quality than the best cell phone out there.

Just two of my BSD cents.

Janina

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[covici]

I have to agree, we need console access, not just a terminal in the
gui.  Even if we write speech dispatcher drivers for more synths, how
would speakup work then if they get rid of this interface?

Janina Sajka <janina@rednote.net> wrote:

> John G. Heim writes:
> > You can switch to a character user interface and use speakup even after
> > starting the graphical user interface. But as I said, I don't consider that
> > a key part of the linux  accessibility infrastructure.
> 
> 
> I have to disagree strongly, John.
> 
> But, let me phrase my disagreement this way, is the console a key part
> of Linux? Or shall we dump the console entirely in favor of a terminal
> in the gui?
> 
> If the answer is that the console needs to stay, then we need console
> based a11y.
> 
> Speaking for myself, I still spend most of my time in the console. I
> don't care for Thunderbird. And, while I routinely use Firefox, I still
> use Lynx more. I could go on, but I think I've made my point.
> 
> BTW: I also conduct most of my business phone calls from a Linux CLI SIP
> client because this gives me far better latency and far better audio
> quality than the best cell phone out there.
> 
> Just two of my BSD cents.
> 
> Janina
> 
> _______________________________________________
> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

Janina Sajka <janina@rednote.net> writes:

> If the answer is that the console needs to stay, then we need console
> based a11y.

Yes, console access is still useful and relevant for lots of us.

The whole point of the message that started this thread
is that  We need to be aware of possible future developments in Linux,
so that our community can adapt without being caught off-guard.
I'd really like to know how long we will have the current console code
in the kernel.  For now, the answer is "indefinitely", but there's a
real possibility that the situation could change in coming years.

I guess the next step is to start making a contingency plan.
How will a screen reader be integrated with the coming userspace console
solution?  Should it be included directly in that codebase, or should it
be some sort of third-party add-on?
I think the latter approach is probably the best, because it can be
maintained by the people who care the most about console a11y.  Also, it
allows for multiple interchangeable implementations, independent of the
userspace console server itself.  That means we will need some method of
hooking into the console server for accessibility purposes, in much the
same way as we use the kernel-provided keyboard and VT notifier
mechanism today.  For that, we'll have to come up with some sort of API,
and we can't do that in a vacuum.  At some point, we're going to have to
open a dialog with the folks who are working on the userspace console
server, so that our concerns can be addressed.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Cleverson Casarin Uliana]

Chris writes:
> I think the latter approach is probably the best, because it can be
> maintained by the people who care the most about console a11y.  Also, it
> allows for multiple interchangeable implementations, independent of the
> userspace console server itself.

Is there the possibility for a portable screen reader that works in *bsd 
too, or the differences among systems are too big?

Cleverson

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

Completely agree about evolving a community consensus on the
contingency. I guess we're doing that now in these discussions. When
last did we have so many emails on the Speakup list? Sheesh! <grin>

Here's my concern ...

We need to catch the requirements phase of the replacement console
environment. I'm fine about third party development of the screen
reader. I want users involved in that. But, you can only take advantage
of what the environment allows. We need to make sure our needs are
supported.

Had we had this kind of input into pulse audio, I think it would have
been a different app from the gitgo. We didn't, and we've suffered the
consequence ever since.

Janina

Chris Brannon writes:
> Janina Sajka <janina@rednote.net> writes:
> 
> > If the answer is that the console needs to stay, then we need console
> > based a11y.
> 
> Yes, console access is still useful and relevant for lots of us.
> 
> The whole point of the message that started this thread
> is that  We need to be aware of possible future developments in Linux,
> so that our community can adapt without being caught off-guard.
> I'd really like to know how long we will have the current console code
> in the kernel.  For now, the answer is "indefinitely", but there's a
> real possibility that the situation could change in coming years.
> 
> I guess the next step is to start making a contingency plan.
> How will a screen reader be integrated with the coming userspace console
> solution?  Should it be included directly in that codebase, or should it
> be some sort of third-party add-on?
> I think the latter approach is probably the best, because it can be
> maintained by the people who care the most about console a11y.  Also, it
> allows for multiple interchangeable implementations, independent of the
> userspace console server itself.  That means we will need some method of
> hooking into the console server for accessibility purposes, in much the
> same way as we use the kernel-provided keyboard and VT notifier
> mechanism today.  For that, we'll have to come up with some sort of API,
> and we can't do that in a vacuum.  At some point, we're going to have to
> open a dialog with the folks who are working on the userspace console
> server, so that our concerns can be addressed.
> 
> -- Chris
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

On 10/09/14 07:32, Janina Sajka wrote:
> John G. Heim writes:
>> You can switch to a character user interface and use speakup even after
>> starting the graphical user interface. But as I said, I don't consider that
>> a key part of the linux  accessibility infrastructure.
>
>
> I have to disagree strongly, John.
>
> But, let me phrase my disagreement this way, is the console a key part
> of Linux? Or shall we dump the console entirely in favor of a terminal
> in the gui?

In principle, I agree with you entirely. I'm in favor of 100% equal 
access. It's just that I think there is a much greater issue.

Actually, the way you do things probably isn't threatened. You may have 
to switch to a different user space screen reader. But the linux kernel 
developers have no obligation to avoid telling you that your choice of 
screen reader is no longer supported. They do that kind of thing every day.

I am asserting that doing something that makes it impossible for a blind 
systems admin to get access to the same boot messages that a sighted 
systems admin gets is a completely different matter.  I'm saying that 
there are times when a  sys admin has to have access to those messages 
or he can't do his job. I'm not saying he can't do it as efficiently. 
I'm saying sometimes he can't do it at all without access to those messages.

There are a lot of places to attack my position. Some people have 
implied that you can do your job w/o access to those messages. I agree 
that most of the time you can. But not always. Also, there may be other 
ways to get access to those messages besides speakup and a hardware 
synth. A serial console comes to mind. But I'm not sure of what the 
status of the serial console is going to be if this change occurs.

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

We might be in what's sometimes called violent agreement, here.

I agree we need boot messages. You may recall, back when Bill and I were
putting out the Speakup Modified Fedora that we had the slogan of
"because equal access is the blind computer user's right, from bootup to shutdown."

Heck it's still there on the Speakup Modified page.

Janina

John G. Heim writes:
> 
> 
> On 10/09/14 07:32, Janina Sajka wrote:
> >John G. Heim writes:
> >>You can switch to a character user interface and use speakup even after
> >>starting the graphical user interface. But as I said, I don't consider that
> >>a key part of the linux  accessibility infrastructure.
> >
> >
> >I have to disagree strongly, John.
> >
> >But, let me phrase my disagreement this way, is the console a key part
> >of Linux? Or shall we dump the console entirely in favor of a terminal
> >in the gui?
> 
> In principle, I agree with you entirely. I'm in favor of 100% equal access.
> It's just that I think there is a much greater issue.
> 
> Actually, the way you do things probably isn't threatened. You may have to
> switch to a different user space screen reader. But the linux kernel
> developers have no obligation to avoid telling you that your choice of
> screen reader is no longer supported. They do that kind of thing every day.
> 
> I am asserting that doing something that makes it impossible for a blind
> systems admin to get access to the same boot messages that a sighted systems
> admin gets is a completely different matter.  I'm saying that there are
> times when a  sys admin has to have access to those messages or he can't do
> his job. I'm not saying he can't do it as efficiently. I'm saying sometimes
> he can't do it at all without access to those messages.
> 
> There are a lot of places to attack my position. Some people have implied
> that you can do your job w/o access to those messages. I agree that most of
> the time you can. But not always. Also, there may be other ways to get
> access to those messages besides speakup and a hardware synth. A serial
> console comes to mind. But I'm not sure of what the status of the serial
> console is going to be if this change occurs.
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

"John G. Heim" <jheim@math.wisc.edu> writes:

> Yeah, if you're a linux sysadmin, hardware speech is not some luxury
> you can do without.

Well, if the Linux console moves into user space, this doesn't have mean the
end of hardware speech.
Perhaps the way forward is through initramfs?  As a proof of concept, I
built one that had the Speakup modules, audio libraries, and espeakup.
I had *software* speech running from the initramfs.
It was a bit difficult to build it, because I had to figure out all of
the dependencies and add them.  But it worked.
Now, if you're just doing hardware speech, things are going to be much
less complicated, and it should definitely be possible to have it long
before the root partition is mounted, even if the Linux console code
ends up migrating to userspace.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[covici]

I use an initramfs, and I have speakup built in, but indeed, I do get
messages pretty early, certainly before the real root is alive -- things
are fine as long as the kernel boots up, if that were not to happen,
then I would be sunk without something in the kernel itwself.

Chris Brannon <chris@the-brannons.com> wrote:

> "John G. Heim" <jheim@math.wisc.edu> writes:
> 
> > Yeah, if you're a linux sysadmin, hardware speech is not some luxury
> > you can do without.
> 
> Well, if the Linux console moves into user space, this doesn't have mean the
> end of hardware speech.
> Perhaps the way forward is through initramfs?  As a proof of concept, I
> built one that had the Speakup modules, audio libraries, and espeakup.
> I had *software* speech running from the initramfs.
> It was a bit difficult to build it, because I had to figure out all of
> the dependencies and add them.  But it worked.
> Now, if you're just doing hardware speech, things are going to be much
> less complicated, and it should definitely be possible to have it long
> before the root partition is mounted, even if the Linux console code
> ends up migrating to userspace.
> 
> -- Chris
> _______________________________________________
> 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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Gregory Nowak]

That's awesome Chris. I always thought having software speech in the
initrd would be very neat; the equivalent of having a hardware synth
at boot more or less. I wasn't sure if there is such a thing as a too
big initrd. Your post tells me the answer is no, at least in your
case. The second and harder part is figuring out what exactly needs to
go in the initrd to get software speech, while not putting in the
initrd more than is necessary. Could you please consider doing a brief
write-up on the procedure you used? I would find something like that
to be a helpful and interesting read, and I'm sure others would as
well.

Greg


On Wed, Oct 08, 2014 at 04:04:16PM -0700, Chris Brannon wrote:
> Well, if the Linux console moves into user space, this doesn't have mean the
> end of hardware speech.
> Perhaps the way forward is through initramfs?  As a proof of concept, I
> built one that had the Speakup modules, audio libraries, and espeakup.
> I had *software* speech running from the initramfs.
> It was a bit difficult to build it, because I had to figure out all of
> the dependencies and add them.  But it worked.
> Now, if you're just doing hardware speech, things are going to be much
> less complicated, and it should definitely be possible to have it long
> before the root partition is mounted, even if the Linux console code
> ends up migrating to userspace.
> 
> -- Chris


-- 
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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

Gregory Nowak <greg@gregn.net> writes:

> I wasn't sure if there is such a thing as a too
> big initrd.

As far as I know, the only limit is the size of your RAM.  If there's a
limit, I haven't reached it, and I'm pretty sure I've seen 40 megabyte
initramfs images. Anyway, espeak is pretty small.

> Could you please consider doing a brief
> write-up on the procedure you used?

Sure.  I haven't done this exercise in a while, so I'll do it once more,
whilst taking notes.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

Speakup in an initramfs? I love it.

Let's remember that technology will continue to bmove, and we should
think creatively about how to do equivalents of Speakup in an initramfs
going forward.

What about a full computer on a USB stick? Boot the stick then start the
main machine drive as a vm. Am I crazy? I think not.

I suspect there are other opportunities, too.

Janina

Chris Brannon writes:
> "John G. Heim" <jheim@math.wisc.edu> writes:
> 
> > Yeah, if you're a linux sysadmin, hardware speech is not some luxury
> > you can do without.
> 
> Well, if the Linux console moves into user space, this doesn't have mean the
> end of hardware speech.
> Perhaps the way forward is through initramfs?  As a proof of concept, I
> built one that had the Speakup modules, audio libraries, and espeakup.
> I had *software* speech running from the initramfs.
> It was a bit difficult to build it, because I had to figure out all of
> the dependencies and add them.  But it worked.
> Now, if you're just doing hardware speech, things are going to be much
> less complicated, and it should definitely be possible to have it long
> before the root partition is mounted, even if the Linux console code
> ends up migrating to userspace.
> 
> -- Chris
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Chris Brannon]

Janina Sajka <janina@rednote.net> writes:

> What about a full computer on a USB stick? Boot the stick then start the
> main machine drive as a vm. Am I crazy? I think not.

Not at all.  William Hubbs and I did this a couple of months ago, in
order to figure out why he couldn't boot from the Linux on his hard
drive.  I'm not sure which one of us came up with the idea, but I talked him
through the process of booting his physical hard drive as a VM image
under qemu running in a live CD environment.  The long and the short was
that he was able to read the boot messages, so the problem was diagnosed
and fixed in short order.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

It was for stuff like this that we created the International Association 
of Visually Impaired Technologists. The  #1 problem we sought to address 
is that there's knowledge out there on how to do this kind of thing but 
it resides in the head of individuals scattered about cyberspace.

Would you be willing to write a blog or a wiki entry about this for the 
IAVIT web site?  Maybe we could put out a bootable image with most of 
the work already done.

BTW, grml just released a new version for testing today. I've been 
planning on putting out a fork of grml that has a  kernel patched for 
speakup and hardware synths and a few other niceties for the blind.  But 
there are only so many hours in the day.

On 10/09/14 15:52, Chris Brannon wrote:
> Janina Sajka <janina@rednote.net> writes:
>
>> What about a full computer on a USB stick? Boot the stick then start the
>> main machine drive as a vm. Am I crazy? I think not.
>
> Not at all.  William Hubbs and I did this a couple of months ago, in
> order to figure out why he couldn't boot from the Linux on his hard
> drive.  I'm not sure which one of us came up with the idea, but I talked him
> through the process of booting his physical hard drive as a VM image
> under qemu running in a live CD environment.  The long and the short was
> that he was able to read the boot messages, so the problem was diagnosed
> and fixed in short order.
>
> -- Chris
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>

running VMs from a live environment

[Chris Brannon]

"John G. Heim" <jheim@math.wisc.edu> writes:

> Would you be willing to write a blog or a wiki entry about this for
> the IAVIT web site?  Maybe we could put out a bootable image with most
> of the work already done.

Sure I would.  There really wasn't much to it, so I'll just document it
here.

William grabbed a copy of the Talking Arch CD image, burned it, and
booted it.  Next, we installed the qemu package into the live
environment.  Basically,
pacman -Sy
pacman -S qemu
We were really lucky that it worked, because the packages on the live CD
can get badly out of sync with the packages in the Arch repositories,
especially with respect to shared libraries.
So adding packages to a live environment on the fly isn't really
recommended practice, but if you're brave and desperate, you'll try just about
anything!  If this step had failed, I would have remastered a new image
just for this purpose.  That's pretty easy to do with Talking
Arch.  I'm sure the same applies to Grml.
Anyway, the package got installed to the RAM-based tmpfs.
After that, we executed
qemu -curses -hda /dev/sda -boot c
and listened to some informative boot messages

Here's the problem.  In some situations, qemu -curses doesn't work.
It depends on whether your distribution or installation is set up to use
a standard VGA text console or a frame-buffer based console.  If it's
the latter, then qemu with curses just displays a banner stating that
the system is in graphical mode, and it won't give you any text.
In some cases, I've had to go out of my way to force things not to boot
into a frame buffer console.  At other times, getting the VGA text
console is as easy as passing vga=normal on the kernel command line.
It's also possible to get qemu to redirect a serial port to a listening
TCP/IP or Unix-domain socket.  See the -serial option in the manpage.
So if the system insists on booting into graphical mode, I could always
start a serial console and then talk to it with telnet, netcat, or
socat.

I hope this is enough detail.
Yes, a bootable live environment with the VM packages pre-installed
would be great.  It shouldn't be too hard to get it added to the ones
that people are using.

-- Chris

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Gregory Nowak]

On Thu, Oct 09, 2014 at 04:26:30PM -0500, John G. Heim wrote:
> BTW, grml just released a new version for testing today. I've been
> planning on putting out a fork of grml that has a  kernel patched
> for speakup and hardware synths and a few other niceties for the
> blind.  But there are only so many hours in the day.

As far as I know, grml full already includes speakup, or has that
changed recently? Do you mean putting speakup into grml versions other
than full? I agree having speakup in grml small would be nice.

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: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

Sheesh, how did I forget grml? I have it on a stick sitting in my desk
drawer. And, it came with Speakup already in the iso image.

John G. Heim writes:
> It was for stuff like this that we created the International Association of
> Visually Impaired Technologists. The  #1 problem we sought to address is
> that there's knowledge out there on how to do this kind of thing but it
> resides in the head of individuals scattered about cyberspace.
> 
> Would you be willing to write a blog or a wiki entry about this for the
> IAVIT web site?  Maybe we could put out a bootable image with most of the
> work already done.
> 
> BTW, grml just released a new version for testing today. I've been planning
> on putting out a fork of grml that has a  kernel patched for speakup and
> hardware synths and a few other niceties for the blind.  But there are only
> so many hours in the day.
> 
> On 10/09/14 15:52, Chris Brannon wrote:
> >Janina Sajka <janina@rednote.net> writes:
> >
> >>What about a full computer on a USB stick? Boot the stick then start the
> >>main machine drive as a vm. Am I crazy? I think not.
> >
> >Not at all.  William Hubbs and I did this a couple of months ago, in
> >order to figure out why he couldn't boot from the Linux on his hard
> >drive.  I'm not sure which one of us came up with the idea, but I talked him
> >through the process of booting his physical hard drive as a VM image
> >under qemu running in a live CD environment.  The long and the short was
> >that he was able to read the boot messages, so the problem was diagnosed
> >and fixed in short order.
> >
> >-- Chris
> >_______________________________________________
> >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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Cleverson Casarin Uliana]

Janina writes:
> What about a full computer on a USB stick?

Going a bit off topic, for years I've been dreaming of a mobile device 
with a full qwerty keyboard, that could work as a normal smartphone and 
also give me the same freedom as a regular PC, i.e., that I could 
install any operating system I would on a PC. I think it wouldn't be 
that difficult to build today, one could for example make it using a 
raspberry py or a similar board.

Cheers
Cleverson

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

I've never seen a server without a serial port.



On 10/08/14 14:43, Kyle wrote:
> It does appear to me that something like this will force more of Speakup
> into userspace. However, unlike others, I'm not entirely opposed to the
> idea of Speakup leaving the kernel, and I think it can only be a good
> thing, especially on newer machines, where dedicated serial ports are
> all but obsolete, and software in userspace can take better advantage of
> things like Pulseaudio and libusb, meaning more extensive software and
> hardware speech support. For example, there would no longer be a need
> for kernel modules to control speech synthesizers, and there would no
> longer be a need to have external userspace connectors such as Espeakup,
> as the entire Speakup screen reader could be moved into userspace, and
> anything that interfaces with a speech synthesizer could be either
> internal or could be a library that interfaces with a speech API like
> speech-dispatcher or others. Even better, if Speakup is moved entirely
> into userspace, it could give rise to far better access to consoles on
> *BSD and other Unix operating systems, as the code could be far more
> portable between operating systems when it doesn't have to be tied into
> a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
> ~Kyle
> http://kyle.tk/
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

John G. Heim writes:
> I've never seen a server without a serial port.


And, I would wager none of us ever will, not in our lifetimes.

PS: You can also expect serial headers on commodity network devices like
home routers. That's how OpenWRT fuels itself.

Let's not forget that OpenWRT and its cousins will also need console
access. That community isn't going to give up early access tothe
hardware they're developing on. That's their bread and butter. And,
Linux isn't going to let go of its dominance in that market space.

Janina

> 
> 
> 
> On 10/08/14 14:43, Kyle wrote:
> >It does appear to me that something like this will force more of Speakup
> >into userspace. However, unlike others, I'm not entirely opposed to the
> >idea of Speakup leaving the kernel, and I think it can only be a good
> >thing, especially on newer machines, where dedicated serial ports are
> >all but obsolete, and software in userspace can take better advantage of
> >things like Pulseaudio and libusb, meaning more extensive software and
> >hardware speech support. For example, there would no longer be a need
> >for kernel modules to control speech synthesizers, and there would no
> >longer be a need to have external userspace connectors such as Espeakup,
> >as the entire Speakup screen reader could be moved into userspace, and
> >anything that interfaces with a speech synthesizer could be either
> >internal or could be a library that interfaces with a speech API like
> >speech-dispatcher or others. Even better, if Speakup is moved entirely
> >into userspace, it could give rise to far better access to consoles on
> >*BSD and other Unix operating systems, as the code could be far more
> >portable between operating systems when it doesn't have to be tied into
> >a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
> >~Kyle
> >http://kyle.tk/
> >
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Kyle]

According to Janina Sajka:
# PS: You can also expect serial headers on commodity network devices like
# home routers. That's how OpenWRT fuels itself.

On the other hand, Speakup never has, and never will, run on a home
router, and the fact remains that although it may still be possible to
purchase a newer hardware speech synthesizer, they just don't put serial
cables on them now. The newest ones I've heard anything at all about
connect to USB ports, but have been entirely neglected by Speakup for
years, either due to extreme rigidity of the developers when depending
on dedicated ports, or more likely due to the impossibility of coding
for a changing USB enumeration from within the kernel. Please note that
although on most computers, especially laptops, a dedicated serial port
is past obsolete, no one here is indicating that support for such ports
be dropped from Speakup. WE JUST WANT OPTIONS!

Additionally, on the subject of servers, it is one thing to have a
serial console that one can use if ssh or other remote connectivity
stops working, but Speakup is an entirely different type of software,
and comes with its own share of bugs, which are far easier to deal with
in userspace than in the kernel. Some may respond to the sysadmin story
of not being allowed to work on a server because of Speakup, calling it
a lack of consideration for people with disabilities. I, on the other
hand, recognize that the kernel should be as clean as possible,
especially in a server environment, and the potential for one module to
crash the entire kernel, potentially ruining the whole server, is
something to be avoided at all costs. It's one thing for a screen reader
to have a bug that crashes something in userspace, which is usually the
screen reader, but it's another thing entirely for it to crash the
kernel, which takes all of userspace down with it. This is a very good
reason to keep as much out of the kernel as possible, and why at least
some distributions aimed specifically at servers will not enable the
staging drivers, where the Speakup modules are built. It's not a matter
of keeping the blinks from being sysadmins, it's just a matter of the
rock solid stability that is needed on servers more than on any other
type of machine.

So while you may find serial ports on servers, Speakup adoption on such
machines will be seriously inhibited until or unless it makes its way
out of the kernel and into userspace, where screen readers should be.
And though you may find serial port headers on home routers, Speakup
will never be used on those, as they have no use for it. So apples to
apples, the machines that can get the most benefit from Speakup don't
have the port needed to take advantage of hardware speech, and no module
has been written that will allow it to communicate using the ports on
such machines. Instead of focusing on which machines still have serial
ports, just move Speakup out of the kernel, and improve support for
software speech, USB devices and USB to serial converters from within
userspace. Then from within userspace, the serial communication via a
dedicated port can be repaired and improved also.
~Kyle
http://kyle.tk/
-- 
"Kyle? ... She calls her cake, Kyle?"
Out of This World, season 2 episode 21 - "The Amazing Evie"

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[John G. Heim]

But again, the whole thing means nothing unless you can address the 
point of how a blind systems admin is going to do his job without  a 
screen reader in the kernel. Your logic about getting everything out of 
the kernel that isn't necessary could apply to anything. Yet, there are 
thousands of linux kernel modules. Why? Because people need them. If 
blind people need speakup in the kernel, then it should be fixed or 
replaced with something that doesn't have any bugs. Not done away with.





On 10/09/14 16:23, Kyle wrote:
> According to Janina Sajka:
> # PS: You can also expect serial headers on commodity network devices like
> # home routers. That's how OpenWRT fuels itself.
>
> On the other hand, Speakup never has, and never will, run on a home
> router, and the fact remains that although it may still be possible to
> purchase a newer hardware speech synthesizer, they just don't put serial
> cables on them now. The newest ones I've heard anything at all about
> connect to USB ports, but have been entirely neglected by Speakup for
> years, either due to extreme rigidity of the developers when depending
> on dedicated ports, or more likely due to the impossibility of coding
> for a changing USB enumeration from within the kernel. Please note that
> although on most computers, especially laptops, a dedicated serial port
> is past obsolete, no one here is indicating that support for such ports
> be dropped from Speakup. WE JUST WANT OPTIONS!
>
> Additionally, on the subject of servers, it is one thing to have a
> serial console that one can use if ssh or other remote connectivity
> stops working, but Speakup is an entirely different type of software,
> and comes with its own share of bugs, which are far easier to deal with
> in userspace than in the kernel. Some may respond to the sysadmin story
> of not being allowed to work on a server because of Speakup, calling it
> a lack of consideration for people with disabilities. I, on the other
> hand, recognize that the kernel should be as clean as possible,
> especially in a server environment, and the potential for one module to
> crash the entire kernel, potentially ruining the whole server, is
> something to be avoided at all costs. It's one thing for a screen reader
> to have a bug that crashes something in userspace, which is usually the
> screen reader, but it's another thing entirely for it to crash the
> kernel, which takes all of userspace down with it. This is a very good
> reason to keep as much out of the kernel as possible, and why at least
> some distributions aimed specifically at servers will not enable the
> staging drivers, where the Speakup modules are built. It's not a matter
> of keeping the blinks from being sysadmins, it's just a matter of the
> rock solid stability that is needed on servers more than on any other
> type of machine.
>
> So while you may find serial ports on servers, Speakup adoption on such
> machines will be seriously inhibited until or unless it makes its way
> out of the kernel and into userspace, where screen readers should be.
> And though you may find serial port headers on home routers, Speakup
> will never be used on those, as they have no use for it. So apples to
> apples, the machines that can get the most benefit from Speakup don't
> have the port needed to take advantage of hardware speech, and no module
> has been written that will allow it to communicate using the ports on
> such machines. Instead of focusing on which machines still have serial
> ports, just move Speakup out of the kernel, and improve support for
> software speech, USB devices and USB to serial converters from within
> userspace. Then from within userspace, the serial communication via a
> dedicated port can be repaired and improved also.
> ~Kyle
> http://kyle.tk/
>

Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup

[Janina Sajka]

I wasn't suggesting running Speakup on OpenWRT, though I don't see why
it couldn't be done.

My point is that major sectors of the Linux environment rely on serial
ports, not just us. For this reason they'll continue to be supported,
even if that support remains aimed at engineering types alone.


Kyle writes:
> According to Janina Sajka:
> # PS: You can also expect serial headers on commodity network devices like
> # home routers. That's how OpenWRT fuels itself.
> 
> On the other hand, Speakup never has, and never will, run on a home
> router, and the fact remains that although it may still be possible to
> purchase a newer hardware speech synthesizer, they just don't put serial
> cables on them now. The newest ones I've heard anything at all about
> connect to USB ports, but have been entirely neglected by Speakup for
> years, either due to extreme rigidity of the developers when depending
> on dedicated ports, or more likely due to the impossibility of coding
> for a changing USB enumeration from within the kernel. Please note that
> although on most computers, especially laptops, a dedicated serial port
> is past obsolete, no one here is indicating that support for such ports
> be dropped from Speakup. WE JUST WANT OPTIONS!
> 
> Additionally, on the subject of servers, it is one thing to have a
> serial console that one can use if ssh or other remote connectivity
> stops working, but Speakup is an entirely different type of software,
> and comes with its own share of bugs, which are far easier to deal with
> in userspace than in the kernel. Some may respond to the sysadmin story
> of not being allowed to work on a server because of Speakup, calling it
> a lack of consideration for people with disabilities. I, on the other
> hand, recognize that the kernel should be as clean as possible,
> especially in a server environment, and the potential for one module to
> crash the entire kernel, potentially ruining the whole server, is
> something to be avoided at all costs. It's one thing for a screen reader
> to have a bug that crashes something in userspace, which is usually the
> screen reader, but it's another thing entirely for it to crash the
> kernel, which takes all of userspace down with it. This is a very good
> reason to keep as much out of the kernel as possible, and why at least
> some distributions aimed specifically at servers will not enable the
> staging drivers, where the Speakup modules are built. It's not a matter
> of keeping the blinks from being sysadmins, it's just a matter of the
> rock solid stability that is needed on servers more than on any other
> type of machine.
> 
> So while you may find serial ports on servers, Speakup adoption on such
> machines will be seriously inhibited until or unless it makes its way
> out of the kernel and into userspace, where screen readers should be.
> And though you may find serial port headers on home routers, Speakup
> will never be used on those, as they have no use for it. So apples to
> apples, the machines that can get the most benefit from Speakup don't
> have the port needed to take advantage of hardware speech, and no module
> has been written that will allow it to communicate using the ports on
> such machines. Instead of focusing on which machines still have serial
> ports, just move Speakup out of the kernel, and improve support for
> software speech, USB devices and USB to serial converters from within
> userspace. Then from within userspace, the serial communication via a
> dedicated port can be repaired and improved also.
> ~Kyle
> http://kyle.tk/
> -- 
> "Kyle? ... She calls her cake, Kyle?"
> Out of This World, season 2 episode 21 - "The Amazing Evie"
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Talking with the systemd-consoled people (Was: the push to get rid of CONFIG_VT in the kernel and the future of Speakup)

[Samuel Thibault]

Hello,

It is quite a coincidence that I happen to have talked with some people
working on systemd-consoled the other day at the XDC2014 conference. I
was thus able to discuss the concern about CONFIG_VT "going away" with
them, and there are quite a few reassuring points:

- the CONFIG_VT option is here to stay, even if some production systems
will indeed disable it (such as embedded devices and such); I believe a
lot of kernel hackers and such will keep it enabled, and thus it will be
kept maintained;

- on production systems where CONFIG_VT is not available, sighted users
will not see kernel boot messages etc. until the userland console gets
started (and a userland screen reader thus has the opportunity to get
started too). Those kernels have no text rendering except one thing I'll
discuss below; everything should be available to the userland screen
reader, so it means that blind people have no less access to what the
computer says than sighted people, be it normal work or boot messages.
If boot messages are needed to debug something before systemd-consoled
and screen reader are started, sighted users will need some way to get
them anyway, and such kind of way (CONFIG_VT, serial console, network
console, etc.) is already accessible to blind users.

- the only text rendering done by the kernel is oops messages.  In the
cases where that ends up with a kernel hangup (so-called kernel panic),
speakup can not work any more anyway, be it with CONFIG_VT or not, so
there is no regression here, at least.  Unfortunately that case can't
really be made accessible: writing text to video memory is possible in
that case, interacting with the user to access the screen is not really
(no interrupts, etc.). So a serial console is needed to debug such case.
In the cases where that doesn't end up with a kernel panic, a syslog
notification is enough to get the oops message.

- I could discuss with a developper of systemd-consoled, to explain him
what requirements speakup and such screen readers have, to get the content
of the console: screen content and stream of text.  He understood it
well, and is willing to provide the support.

Samuel