Loada Misc Stuff & Ramblings

Tue Jun 17 23:32:19 MST 2003

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, good peeps,

Thought I'd just drop in misc stuff about everything I've read about and 
want to ask about as well as keeping you updated.

First, I wonder, should we have a domain to our name?  I have recently 
found cause to open all projects under my hat which spark particular 
interest, and I think this is one of them, by designating them as official 
works of time spent in better ways <grin> EG by completing my degree and 
therefore by giving them domains.  You can always get a list of these from 
www.sabahattin-gucukoglu.com.  I reckon this is a candidate for a domain, 
and like the others I would be happy to write a simple set of web pages 
introducing us to the world.  (Note I am a Gopher advocate - I would 
prefer it if noone here objects.)

Secondly, I have finally extracted all text strings from PDI's Keynote SA 
SSIL driver.  I regret that finding the ranges for certain values will be 
quite difficult.  The driver was written in C, and debugless optimised.  I 
am however putting a good deal of effort into extracting as much as I can 
in the way of values from wherever else the information may show up.  Note 
that this is not simply checking screen readers and their drivers - many 
restrict the ranges in use.  For a first test, I could use some help.  The 
syntax for changing the rate of the synthesiser is: [rn] where n is a 
decimal value estimated to have a range of -100 to 200 (-100 = fastest).  
A commonly used range appears to be -90 to 180, however.  Can someone with 
timing better than I please tell me what they think the true range is - EG 
does 200 appear slower than 180, or -100 appear faster than -90?  As each 
test succeeds I will note the results and publish the final paper, with 
your reading and consent.  Whether it helps the LinuxOnBN project is a 
different matter because we have reason to believe that the synthesiser is 
done in sound hardware; nevertheless, it could be useful to someone, 
especially the authors of speaking screen readers (including BrlTTY).

Now, about the braille display and external vs internal use of it, and the 
issue of getting the info from PDI.  The only info I've seen on PDI's 
offering help about the display (a logical move since the display is 
produced by Humanware) was a message forwarded by Greg here from PDI to 
Blinux, stating the virtues and added marketting hipe of their utter 
delight of supporting Linux, etc, etc, etc.  In short, we know nothing 
about exactly how the BrlTTY team got the information they did, unless 
someone goes back and reviews the thread and finds more.  We would have to 
ask them.  Any volunteers?

Here is some more line of thinking.  As someone here has said, we may need 
more internal information about how to get the display to do its job.  
However, I am inclined to think that, like the synthesizer, the 
abstraction as an API interface is likely to be internal also, which I 
assume based on my relative knowledge of Windows CE and the knowledge that 
there is some assembly code done in the BN.  Even coded in C, it seems 
unlikely that anyone would do inline assembly for each and every request 
to a braille display to display a particular character.  If we did, 
though, it would be a considerably benefitial thing to abstract it 
ourselves to an internal serial interface; then we wouldn't need to 
rewrite every feature of BrlTTY including translation.  In short: remote 
synthesizer support in the BN is nothing more than sending the text from 
the physical serial line to the speech API, I think the braille display 
works in the same way.  Finally, the qwerty models of the braille display 
only send over the serial line the dots pressed in the home key set in 
terminal mode; they emulate their braille keyboard equivalents without 
taking simple steps to convert (or even simply send) qwerty input first.  
This means that there is a definite requirement on our part to take steps 
to handle keyboard input and abstract it all if necessary for BrlTTY to be 
able to use it.  I recently found out that ANSI/ASCII is the character 
exchanged over the serial line; BrlTTY and the BN both depend on those for 
its operation.  This seems logical, and tends to coroborate the 
methodology used in internal communication with the braille display during 
Keysoft's operation as compared to the synthesizer.

Greg, could you tell us if your kernel image accepts keyboard input with a 
braille keyboard (in American code)?  If you can tap out in braille a 
command and get it to execute, clearly the keyboard works in hardware.  Of 
course, if you have a qwerty you cannot conduct this experiment.  If this 
were true, we automagically vanquish the hefty keyboard handling 
requirements.  I fear that it is not, though.

How did you get the BN to start the kernel at all?  Is it all there on the 
site mentioned?

That's everything for now, methinks...

Cheers,
Seb

- -- 

Thought for the day:
    Concerto (n): a fight between a piano and a pianist.

Latest PGP Public key?  Click:
<mailto:PGPPublicKey at sabahattin-gucukoglu.com>
and send that message as is.

Sabahattin Gucukoglu
Faraday, 11,003
Loughborough University
Loughborough, Leicestershire
LE11 3TU
United Kingdom

Phone: +44 (0)870 406-9784
Mobile: +44 (0)7986 053399
http://www.sabahattin-gucukoglu.com/
<S.Gucukoglu-01 at student.lboro.ac.uk> for academic or other university 
matters;
<mail at Sabahattin-Gucukoglu.com> otherwise for either E-mail or MSN 
Messenger - cheers.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 -- QDPGP 2.70 
Comment: Previous public key for ID <Sabahattin_Gucukoglu at mailandnews.co.uk> revoked due to invalidated primary address.

iQA/AwUBPvAAFiNEOmEWtR2TEQIWJACg2mI/O5FvKyP9S55UDp9p0XN6GM4AoKpS
h5+jbzcIzWmHRF88FBbqC4/T
=gDoA
-----END PGP SIGNATURE-----