request for assistance: accessing ttys from kernel space
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/
Quoted 3 lines
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
Quoted 3 lines
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
Quoted 3 lines
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)
Quoted 6 lines · Alan Cox, le Tue 26 Jan 2010 02:13:06 +0000, a écrit :
Quoted 3 lines
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?
Quoted 6 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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 :)
Quoted 2 lines
We do have a USB console but it's truely crazy stuff and extending it scares me 8)
Ideally that'll needed :/
Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
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.
Quoted 9 lines
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.cdoes manage do make something else, but it happens that the serial_core.c'suart_console_writeputs 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
Quoted 6 lines · Alan Cox, le Tue 26 Jan 2010 13:39:58 +0000, a écrit :
Quoted 3 lines
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.
Quoted 1 line
Currently there is no path for doing it in the kernel.
That's my concern :)
Thanks,
Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · 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