[BRLTTY] Getting my braille driver for the FCHAD working.

Sun Oct 14 10:32:22 EDT 2012

Sorry Dave, not sure how the name mix up happened :O

Perhaps I will set it to 1,1 and keep a global variable 
"initializationStatus", and ignore any writeWindow requests from brltty 
untill initializationStatus becomes true.

Somehow I'm not seeing the logMessages either in standard error with -e or 
in the log files.  I don't think I'm causing any harm using printf to debug.
  None of the messages produced by my driver are meant for anyone but 
myself.  Those lines of code will all disappear in production code!

As for the global variables and what my professor might say.  My professor 
almost certainly doesn't know the difference between global and local scope.
  I'm at the pedagogic faculty studying education. I've never taken a 
computer programming course in my life!  The thesis is on how people adapt 
to unfamiliar electronic devices.

  I would normally use a closure to package the pointer to brl with the 
handleFrame function when passing it to checkForFrameAndReact.  If it makes 
you feel better, I will pass checkForFrameAndReact a "void * 
callerParameter" which can be forwarded on to handleFrame. Which will then 
take that pointer and package it in a struct along with the other 
information, to callHandler at which point my frame handlers can then unpack
that struct.  Which isn't being made any easier by C's lack of tuples.  But 
at this point, why are we using C at all?  If we want good design and 
maintainability at the price of performance then we should use a higher 
level language.  Once you start repacking values into structs to make 
scoping more obvious you lose the performance advantages of using a low 
level language.  And you still haven't gained the clean clarity of a high 
level one.  It is true that I could have put a giant nested switch statement
in handleFrame rather than using my internal event handling framework.  That
would have prevented the need for the packaging of the info buffer and brl 
pointers by way of not calling my functions through callHandler but rather 
directly.  I was interested in writing an event handling framework in a low 
level language for reasons of edification.  Furthermore, this method allows 
me to have multiple handlers for the same frame type and keep them in 
different places, allowing me better separation between research code(I need
to log how the device is being used by my research subjects) and driver 
code.  Anyways, if you *really* wanted to make it easy to re-allocate the 
block brl points to, you could have simply made brl a pointer to a pointer 
instead of just a pointer.  So let me be on this point, please!

Anyways...

Is there a standard way to snoop the serial connection with brltty?  I have 
an application called serlook which allows serial communications inspection,
but it doesn't seem to be able to host any kind of dummy device for brltty. 
 Can brltty act as a dummy device? How do you inspect serial communications 
when writing drivers?

Timothy

---------- Původní zpráva ----------
Od: Dave Mielke <dave at mielke.cc>
Datum: 12. 10. 2012
Předmět: Re: [BRLTTY] Getting my braille driver for the FCHAD working.
"[quoted lines by timothyhobbs at seznam.cz on 2012/10/11 at 22:19 +0200]

>Dear Mike,

Dave. :-) You're not the only one who calls me Mike, by the way.

>Setting the length to 0 is useful because it allows me to be in a state of
>consistency on my side.  I wait for an initialization packet from the 
device
>and before I receive that initialization packet the size of the buffer is 
>undefined.  

After brltty's core receives a successful return from the driver's construct
() 
method, it assumes that it can begin to write data. As such, it already 
needs 
to know the size of the buffer it needs to allocate and work with. That's 
why 
setting the size to 0 is a bad idea.

That being said, the core is, of course, a bit more robust than that. It 
checks 
for this case, and assumes a size, but that's just to deal with incorrect 
driver coding. The driver should set the correct size. If it can't, then it 
should set a nonzero size which it's prepared to deal with on writes.

>Within my protocol the size of the buffer could theoretically
>change at any time.  Is brltty capable of handling this?  

Yes. The readCommand() method may change the size at any time. If it does 
change the size, it must also set brl->resizeRequired to 1.

>After having read your message, I realized that the reason my messages were
>not being displayed was quite simple.  I must include a \n at the end of 
the
>message for the message to be flushed onto the screen.

Please don't use standard output or standard error. They aren't guaranteed 
to 
work unless you've specified the -e [--standard-error] option. It'd be far 
better if you were to use logMessage() et al (see brltty's log.h).

>I tried changing my printf s to the format:
>
>  logMessage(LOG_INFO,"Line 457\n");

Don't use \n when calling brltty's logging functions.

>No messages were displayed on my screen. Could you please enlighten me as 
to
>the proper syntax/runtime flags I must use in order to see these log
>messages?

Logging is to the system log (usually /var/log/messagews) by default, and to

standard error (your screen if you haven't redirected it) if you specify the
-e 
(or --standard-error) option. You can also specify -L/path/to/file (that -L 
is 
uppercase) if you wish the logs to be concurrently written to a specific 
file.

>Regarding the saving of the brl pointer, I have now fixed that, in that I 
>reset thisBrl in every function that takes * brl as an argument gets run. 
>However keeping that as a global makes the code much easier to read than if
>I were to pass it as an argument all over the place.  

That, ultimately, is an argument I'd give you a failing grade for were I 
your 
professor. Global variables never make code easier to read, and, more often 
than not, are the sources of really difficult-to-analyze problems. I'm 
surprised that no professor has called you on this, given that you're up at 
some level which requires a thesis to be written.

>I do take your advice very seriously and read your messages multiple times.

>However, Samuel had also responded to my message and told me "It is 
>essentially constant throughout the runtime of brltty."  

I'm quite sure Samuel agrees with me on the use of global variables. He was 
just answering your precise question - that's all. He also, very wisely, 
used 
the word "essentially", which was still a caution not to do so.

>So I worked under the assumption that he was correct.

He was correct. When he said "essentially", he was warning you that it can 
change. Also, he probalby just didn't want to get into advising you on how 
to 
write quality, robust, easy-to-maintain, less error-rone code.

>Regarding the EOF, thanks for pointing that out!  I have now fixed it.  I
>now return 1 every time.  I'm not sure what brltty supposes to do in the
>case of a failure.

The driver fails to start, and the core retries later.

-- 
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 at mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html
(http://Mielke.cc/now.html)
http://FamilyRadio.com/(http://FamilyRadio.com/) | http://Mielke.cc/bible/
(http://Mielke.cc/bible/)
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
(http://mielke.cc/mailman/listinfo/brltty)"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mielke.cc/pipermail/brltty/attachments/20121014/c8bbd085/attachment.html>