Re: gentoo dropping speakup support

[Michael Whapples <mwhapples@aim.com>]

Doug your talking a lot of sense, and when I mentioned about speakup and
how it accesses serial ports I think I was thinking back to some of your
comments.

You have within this thread mentioned should be speakup be a combination
of kernel code and user space code, I think I may have mentioned this
before and would also support this type of idea. As an example, I think
the jupiter speech system is this combination approach, how does it
compare to speakup for ease of being maintained to work with newer
kernels, I know that there has been some times in the past when speakup
has had to be altered specifically for newer kernels (sometimes breaking
it for the older kernels).

Another thought about this idea of making the core of speakup not be
interface specific (which I think would be a good idea), is that I think
on the list someone asked about a headless install, and there was a
reply that if by headless this would also mean no video card, then
speakup wouldn't work, I don't know if it could be done another way, but
this seems a bit specific (thinking, may be speakup would have a driver
to access video memory, but also could have another dummy graphics
driver should the machine not have a video card).

Having all the boot messages, while it is useful, and speakup is about
the only way I know how to get the messages at the time (all, from the
earliest possible moment), the question should be asked, on a properly
configured system, how many problems might realistically occur before
such a stage as USB console can work, and eventually the serial ports
that speakup can currently use will soon be gone if the trend of
hardware manufacturers is anything to go by.

I don't know how many are actually working on speakup, but I think it is
only a few and speakup is probably not the only thing for them. I have
to admit as I understand things we are going to have to make hard
decissions and put what effort in the best direction, may it need to be
a complete rewrite, etc.

From
Michael Whapples
On Mon, 2007-06-18 at 01:18 -0500, Doug Sutherland wrote:
> Speakup does use modules, and it can be statically compiled 
> into kernel instead. That's not a problem. The serial ports, 
> however only support real serial ports, not usb-serial, which 
> is becoming a problem.
> 
> As I said a few months ago, the whole usb mess can be 
> statically compiled, including the usb core, the host controller, 
> and even usb-serial devices audio devices, and synth drivers, 
> like the dtlk for example, so in theory it should be possible to 
> boot and get speech output, with changes to speakup.
> 
> As it is now, the code refers to the standard serial port 
> addresses and irqs, and the communication code is RS232 
> specific. 
> 
> So this what I mean about abstraction. An abstract interface 
> does not implement anything, it only defines. The implementation 
> can be anything as long as it follows the interface. So basically 
> there needs to be a layer of code in between the serial port code
> and the code that writes to it, one interface with several 
> implementations, RS232 serial, USB serial, and potential for any 
> other kind of implementation. And my argument was that the 
> same could be done on the user side, pressing a certain key does 
> some thing, currently assumed to be standard keyboard, but 
> would be nice if abstract interface where the keyboard is one type 
> of controller, other devices could trigger same. I'm mostly thinking 
> about mobile pervasive systems, where you might want to read a 
> message or email, not type, and your device is in your pocket. So 
> you have a little controller sort of like a game pad where you can
> move between messages and read them etc, or get phone numbers 
> from a list. If the interface to the synth is generic then there are all 
> kinds of  possibilities.
> 
> I will be working on this kind of thing with speech, and I am 
> still contemplating whether or not it needs to be kernel space. 
> On an embedded device you really don't need to see all the 
> boot messages, because it will load kernel from flash and will
> always work. If I find a way to adapt this code to work on 
> arm then I might use it, but I actually think I could do the same
> thing entirely in user space. Boot is much simpler than PC and
> very fixed in nature, ie once done it shouldn't change, no need
> to support gazillions of types of hardware etc. I like the idea
> of being able to hear the console output, but then I might end
> up just using usb-serial console and having a microcontroller
> providing a terminal function, in other words both the speech
> and keyboard functions. If done that way it would possibly 
> miss a very small amount of boot messages, but not many. 
> It would be the same as using a terminal program with your
> PC connected to another PC with usb serial dongle and 
> watching the other machine boot. 
> 
>   -- Doug