[quoted lines by Greg KH on 2012/04/05 at 19:33 -0700] >Ok, what platform are you talking about? Specifics please. We design for an arbitrary platform using generic higher level layers such that each new platform requires very little work to incorporate. >Who is "us"? brltty [http://mielke.cc/brltty/] >That's a wonderful goal. But note, that Linux already supports this >just fine (or it should, if not, please let us know and we will fix up >our braille interface that comes with the kernel.) That, interestingly enough, is news to me. I'm not sure what you mean by 'Linux already supports braille in the kernel". It most certainly does not. Now, yes, On Linux we do use /dev/vcsa devices to read the screen, although, even there, Unicode, rather than font positions, would be a huge imrovement (we currently back translate font positions read from the /dev/vcsa devices to Unicode characters). Maybe somewhere in the kernel there's support for a specific braille device - I don't know. We do it all at user level so that our code can be portable, with only minimal dependence on the actual host platform's specific ways of doing things. >Circumventing the standard apis that the Linux kernel provides for this >type of thing is not something that you will get much help from from us >here, as we already spent the time and energy to implement this once, >correctly. Before I get you too upset by saying that we don't use it, perhaps you could tell me exxactly what you're referring to. Maybe what you're calling braille support isn't at all what I'm referring to. For braille, Linux users currently use brltty + Orca - Orca is for the X environment and talks to brltty through an API. The fact is that I chose to ask on this mailing list because I ()hopefully not mistakenly) assumed I would be among friends and expert consultants. If your only interest is to try to get us to increase the amount of our platform-dependent code by orders of magnitude just so that official Linux APIs will be used as much as possible, then you clearly don't understand either our needs or ourselves, and I was indeed mistaken. >And if some platforms do not support your device, that's sad, but why >not contact the developers of those platforms yourself? There's nothing >we can do about their code or interfaces here, right? Do you really think it's the right approach for us to simply spend vast quantities of our personal time going after each individual platform for each individual device when we could just spend a couple of hours coding it once and knowing that it'll just work on all platforms? Do you really think we have the resources to test each individual device on each individual platform each time we release a new version of our software, especially given that braille devices costs thousands of dollars each? It's for reasons like these that we work to keep our drivers simple and that we strive for a minimum of platform-dependent code. We make sure that our drivers are entirely portable, and that our platform-dependent code is simple, stable, and trustworthy. Then, if we test a given braille device on one platform, we just know it'll work on all of them. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: dave@xxxxxxxxx | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
