Hello.
I am the lead developer for gentoo linux's accessibility team[1], and I
am on the development team for the speakup screen reader [2].
I received these addresses from Samuel, and Chris and Kirk are the other
developers on the speakup team.
Currently, speakup is using direct hardware access to communicate with
serial ports. Doing so, however, has limitations since we are hard
coding port addresses and IRQ numbers. For example, we have a user
right now who is wanting to use a PCI Express serial card for his
synthesizer, but the port and IRQ are not standard, so speakup is unable
to use it. He says that the kernel does recognize the card however.
What I would like to discuss is how we can access ttys from kernel
space. If we could do this, it would definitely make things much easier
for us in speakup.
For reference, our git repository is at
http://linux-speakup.org/speakup.git. We are looking to write another
.c file similar to serialio.c but using ttys or some other way to access
the serial ports which works better than hard coading ports and IRQs.
We found another example of attempting this on the web [3], but this
doesn't work any longer according to the thread.
We need to be able to access the ttys as early as possible in the boot
sequence. Any help, suggestions, or guidance you could give us would be
greatly appreciated.
Thanks much,
William
[1] http://www.gentoo.org/proj/en/desktop/accessibility
[2] http://linux-speakup.org
[3]
http://www.linuxquestions.org/questions/programming-9/accessing-tty-in-kernel-space-596538/
> Currently, speakup is using direct hardware access to communicate with
> serial ports. Doing so, however, has limitations since we are hard
> coding port addresses and IRQ numbers. For example, we have a user
I pointed this out several years ago
> What I would like to discuss is how we can access ttys from kernel
> space. If we could do this, it would definitely make things much easier
> for us in speakup.
Basically - use a line discipline, that lets you sit on top of a tty and
interact with the hardware
> We need to be able to access the ttys as early as possible in the boot
> sequence. Any help, suggestions, or guidance you could give us would be
> greatly appreciated.
We may need to make some special provision for that aspect - we already
do so for the early serial console support. The ldisc is the start point
then there may be some bits that need to be extended around it.
A bigger problem is going to be the fact non USB serial is vanishing bit
by bit. We do have a USB console but it's truely crazy stuff and
extending it scares me 8)
William Hubbs, le Mon 25 Jan 2010 20:02:03 -0600, a ?crit :
> What I would like to discuss is how we can access ttys from kernel
> space. If we could do this, it would definitely make things much easier
> for us in speakup.
The same would be useful for better kernel-level braille device support.
Samuel
Alan Cox, le Tue 26 Jan 2010 02:13:06 +0000, a ?crit :
> > What I would like to discuss is how we can access ttys from kernel
> > space. If we could do this, it would definitely make things much easier
> > for us in speakup.
>
> Basically - use a line discipline, that lets you sit on top of a tty and
> interact with the hardware
The problem is that to my knowledge, to setup a line discipline, you
need to already have a daemon opening /dev/ttySomething and set up the
line discipline. You could as well just move all the speakup code into
the daemon. The point of speakup is to have feedback even when it is
not possible to run such daemon.
Is there another way to set up a line discipline from the kernel itself
without the need from userland intervention, even before any / is
mounted?
> > We need to be able to access the ttys as early as possible in the boot
> > sequence. Any help, suggestions, or guidance you could give us would be
> > greatly appreciated.
>
> We may need to make some special provision for that aspect - we already
> do so for the early serial console support.
Maybe the early serial console support layer could be extended a bit so
speakup can use it first during the boot? For now it's quite tied to
just printing the printk logs. drivers/accessibility/braille_console.c
does manage do make something else, but it happens that the
serial_core.c's uart_console_write puts additional \rs before \ns, which
can be a problem.
Also, for proper speech flow, speakup would need to be able to read
characters from the device.
> The ldisc is the start point then there may be some bits that need to
> be extended around it.
To me it seems like the only missing bit is how to setup the line
discipline from the kernel itself (i.e. how to "open" the device?) as
soon as it becomes safe to rely on the tty layer.
> A bigger problem is going to be the fact non USB serial is vanishing bit
> by bit.
Actually that's precisely why the speakup community is pressing for
proper tty support, in order to get PCI & USB support :)
> We do have a USB console but it's truely crazy stuff and extending it
> scares me 8)
Ideally that'll needed :/
Samuel
> Is there another way to set up a line discipline from the kernel itself
> without the need from userland intervention, even before any / is
> mounted?
There is no fundamental reason you can't do that once the tty object
itself exists. Currently there is no path for doing it in the kernel.
> Maybe the early serial console support layer could be extended a bit so
> speakup can use it first during the boot? For now it's quite tied to
> just printing the printk logs. drivers/accessibility/braille_console.c
> does manage do make something else, but it happens that the
> serial_core.c's uart_console_write puts additional \rs before \ns, which
> can be a problem.
>
> Also, for proper speech flow, speakup would need to be able to read
> characters from the device.
Some debugger folk want that too.
I've been trying to get to the point where each tty consists of a
tty_struct which is the instance of an opened tty device, and a tty_port
which is a common struct instance for each physical port. That then has
some operations attached to it.
However at the moment most of the operation paths are not pushed into
tty_port, not every device yet has a tty_port and many of the paths that
need pushing into tty_port reference material that is in struct tty but
probably also needs moving.
So there is an awful lot of work to be done.
I guess the quick 'get it working' hack for the moment would be to add a
'raw' flag to the console output routines and use those (where raw=1
would mean 'don't tamper with the formatting')
Alan
Alan Cox, le Tue 26 Jan 2010 13:39:58 +0000, a ?crit :
> > Is there another way to set up a line discipline from the kernel itself
> > without the need from userland intervention, even before any / is
> > mounted?
>
> There is no fundamental reason you can't do that once the tty object
> itself exists.
I know.
> Currently there is no path for doing it in the kernel.
That's my concern :)
Thanks,
Samuel