[quoted lines by Kenny Hitt on 2005/02/25 at 11:48 -0600] >Since Brltty isn't in the kernel, it might already work on Solaris. Yes, it does, although, strictly speaking, not as well as on Linux when the console is in text mode. When the console is in graphics mode, however, the access is the same since both platfrms rely on Gnopernicus. The reason for the difference when the console is in text mode is that Solaris doesn't offer a way for a user-space application to directly read the screen content in the same way that Linux's /dev/vcsa devices do. Now that Solaris is open source, though, this may be something which can be more easily resolved. Given Sun's commitment to the open source community, I wouldn't be surprised if they'd accept a well-written kernel patch which provides the needed capability. It may even be that, once brought to their attention, a Sun engineer might take up the challenge. In the mean time, of course, BRLTTY can still be used when the Solaris console is in text mode by using it in conjunction with a patched version of the screen program. A patch for screen can be found in BRLTTY's source tree (in the Patches subdirectory) which causes it to maintain an image of the screen in a shared memory segment. BRLTTY can then be built with its shared memory (shm) screen driver. Solaris 10 already includes this combination, i.e. the patched version of screen and BRLTTY built with its shm screen driver. >Developers of Yasr and Brltty >please don't take my next statement the wrong way, but writing kernel >patches is more challenging than writing user space screen readers. As already noted, for BRLTTY to work at its best, it, too, relies on kernel-resident capabilities which aren't part of all Unix flavours. If those capabilities aren't provided by some given platform then it'll still work (when used in conjunction with screen), but not nearly as well. Kernel patches, therefore, may still be necessary. >Programs running in user space can do things that just aren't a good >idea in the kernel. One example is any task that takes a large amount >of time. Time used by a screen reader in kernel space is time lost to >the whole system, while time used by a user space screen reader only >effects the performance of the screen reader. That's not true. The processor's time is always devided up amongst all of the various tasks which need to be done, whether they're in the kernel or in user-space. It's just that tasks which run within the kernel can't be easily preempted so it's typically as though they're implicitly running at maximum priority. This, in turn, can cause the rest of the system to have much less of an interactive feel. This being said, most Unix flavours nowadays offer kernel threads. It's now quite possible, therefore, for tasks requiring large amounts of time to be implemented right within the kernel without destroying the interactive nature of the system in any way. Those tasks just need to be implemented as kernel threads rather than as in-line code. There's really only one reason why it's far better to implement an application in user-space, and that reason is big. There are no standards insofar as what any provider's kernel programming environment is like whereas all providers do try (some much more than others) to offer Posix-based user-space environments. >From the perspective of an application writer, therefore, it's far easier to be platform-independent in user-space. Put another way, it's incredibly expensive for a kernel-based application (like Speakup) to be provided on multiple platforms since very little of its code may actually be reusable. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: dave@xxxxxxxxx | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ _______________________________________________ Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list