Dear all, I'm having some headaches with the serial port hardware (in fact, they've been nagging away in the background for several years, really): I'm using a Tieman CombiBraille display on a serial port with a 16550A UART (i.e. a reasonably modern one with a 16-byte FIFO buffer). The trouble is, I get one problem when the FIFO is enabled, and another when I disable it to avoid the first! This Braille display has an in-built speech chip, and, for some reason, it misbehaves horribly when I'm using the FIFO: the speech gets garbled, it doesn't always speak straight away, some bits get left out etc. Strangely enough, the Braille output is absolutely fine! This is strange to me, because (a) BRLTTY does the same thing whether the FIFO is in use or not, (b) the Kernel and the computer's UART, which are doing different things when the FIFO is enabled or disabled, don't know or care which bits are Braille data and which are speech, and (c) the CombiBraille shouldn't be able to tell whether the computer is using a FIFO, as the data still arrives one bit at a time! I can only guess that the computer's UART is doing something subtly different when the FIFO is enabled (perhaps some delays in transmission) which, for some reason, is upsetting the CombiBraille. My solution to this used to be to turn off the FIFO (with `setserial /dev/ttyS1 uart 16450'). However, when the system has a lot of interrupts to handle (e.g. high-speed read or write access on an ATAPI CD-R drive), there are a lot of overruns in the serial input, leaving the Braille display virtually unusable: so much for multi-tasking... Possible solutions: a) Hack the serial driver to use the FIFO for input but ignore it for output (as if the UART is a cross between a 16550A and a 16450); I don't understand enough about the low-level stuff to know if this is possible - it would mean delving deep into drivers/char/serial.c in the kernel, I would imagine. b) Raise the priority of serial interrupts, and leave the FIFO off. I don't know how to go about doing this, or what the dangers might be... Any thoughts, suggestions, advice etc. would be much appreciated! Cheers, Nikhil. _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list