From: "Doug Sutherland" <doug@proficio.ca>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Subject: Re: gentoo dropping speakup support
Date: Sun, 17 Jun 2007 22:48:52 -0500 [thread overview]
Message-ID: <00a601c7b15b$9749b980$ab00a8c0@tenstac> (raw)
In-Reply-To: <74411A17-AC9D-4C60-BB01-9695456D3126@softcon.com>
I still wonder about the usb console in relation to speakup.
The kernel already has support to direct console to usb
rather than serial port, and has had this capability for a
long time, yet we still can't use usb serial adapters with
speakup because the code assumes hardware serial
port. My understanding is that with usb serial console
you may miss a bit of the initial boot messages, but I
wonder how it might work if speakup was in user space
and we could use usb serial adapters. We'd miss a few
of the initial boot messages but enable more widespread
use of speakup. One way or another this usb problem
needs to be sorted out. I have heard it mentioned by
someone, I forget who, that a hybrid solution might
be the answer, some kernel space and some user.
It could be argued that a lot of what happens with
speakup is application code, and if the line was drawn
between actual hardware drivers and application code
then there would be better chance of getting speakup
into the official kernel. And this, of course, would be
the best thing to happen. If it was all in the kernel with
no patches required then there would be none of this
discussion about gentoo or ubuntu not supporting it.
But presumably the whole thing would have to be
re-written. I can think of another reason to do this
hybrid idea, to enable getting speakup beyond x86
and into ARM for example. There is no ISA bus
there and interrupts are completely different. If it
was well engineered as hybrid, with a "port" being
generically abstracted in the application code, then
it would not matter if the actual port was ISA or
PCI card or USB or firewire, or some other thing
that hasn't been invented yet.
I have an interim suggestion though. Couldn't one
make a small root filesystem that loads speakup
like as a rescue CD, but not a CD, on the hard
drive, for those situations where the regular distro
isn't speaking for whatever reason? If you always
had a small partition like this bootable with speech
then you could at least boot that and then fix your
full fledged distro if need be. Also wondering if
anyone has tried using chroot in this sort of way,
booting minimal system with speech and then
chrooting into the full system.
-- Doug
next prev parent reply other threads:[~ UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
William Hubbs
` Zachary Kline
` Sina Bahram
` Gaijin
` Tom Moore
` Michael Whapples
` Deedra Waters
` Travis Siegel
` Zachary Kline
` C.M. Brannon
` Doug Sutherland [this message]
` Deedra Waters
` Travis Siegel
` Gaijin
` Doug Sutherland
` Luke Yelavich
` Jim Grimsby Jr.
` Doug Sutherland
` Gaijin
` Doug Sutherland
` Michael Whapples
` Lorenzo Taylor
` Samuel Thibault
` Travis Siegel
` Gaijin
` John covici
` Luke Yelavich
Keith Hinton
` James Homuth
` Gaijin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00a601c7b15b$9749b980$ab00a8c0@tenstac' \
--to=doug@proficio.ca \
--cc=speakup@braille.uwo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).