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

[Dave Mielke]

[quoted lines by timothyhobbs at seznam.cz on 2012/10/14 at 16:32 +0200]

>Somehow I'm not seeing the logMessages either in standard error with -e or
>in the log files.  

The most likely reason is that you're using a log level lower than the default. 
Add the -ldebug option and you should see all your logs.

>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.  

yOu may think what you wish. I'm telling you that you shouldn't do it, but you 
don't need to listen. If you know best, then, by all means, do as you wish.

>Those lines of code will all disappear in production code!

:-) :-) :-) Fo you know how many times code only meant for debugging is 
accidentally left in, even by the best of programmers? I guess not.

It's also a truism that those who do whatever they do in a sloppy way when it 
doesn't count usually carry on those bad habits when it does count. It's far 
better in any endeavour of life to just do things right as soon as you discover 
what that right way is. Making excuses for bad practices, once they're known to 
be bad practices, isn't ever wise.

>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!  

Then why not take the opportunity, now, to learn a few things rather than to 
just insist that your ways are okay?

>The thesis is on how people adapt to unfamiliar electronic devices.

That actually sounds quite interesting.

>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.  

Am I understanding you correctly that you're implementing a generic, general 
purpose, full blown, event handler within your driver? Assuming that this is 
correct, it's entirely counter to the way any driver should be written. The 
purpose of a driver is to be as simple an interface as possible between common 
code and the hardware, with all the needed complexity residing within the 
common code. No driver, I don't care what it's for, should ever contain the 
kind of complexity you're describing. I'll give you two reasons. The first is 
that all general purpose capabilities should be available for all of the code 
to use, and the other is that errors within complex code are found faster and 
fixed better if that complex code is in a place where it's used more frequently 
and by more users.

>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.  

I don't disagree with you in principle, but I do disagree with you in 
perspective.

First of all, whoever said that performance is the issue? Would it shock you to 
hear me say that performance isn't the issue? Well ... it isn't.

Do you think that brltty is just a fun toy which runs on high-level operating 
systems like Linux and Windows? Are you aware that it also runs on DOS, and 
that work is underway to enable it to run within the Grub bootr loader? There's 
no way that necessarily limited environments such as those would be able to 
adequately support the kinds of high-level languages which you have in mind.

Are you aware that brltty isn't a university project? All of us who work on it 
do this as a strictly volunteer effort, and most of us have families, jobs, 
etc. Why would we waste our precious time rewriting something that works, just 
ecaause it's a theoretically good idea?

Aside from being a pointless way to be spending our time, that kind of work 
would also come with the need for a great deal of retesting of code which is 
known to be reliable, as well as the need to retest with all of the various 
models of braille devices, each of which is extremely expensive and/or 
extremely difficult to gain free access to. Additionally, we'd no longer have 
any time to devote to useful work such as supporting more types of braille 
devices, more host platforms, etc.

>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 myself happen to prefer tables to switch statements, too. That being said, 
it's never good to use a bad coding practice in one area in order to make using 
a good coding practice in another area easier. Why not just do the whole thing 
right? You'll have far fewer problems in the end, that way. If you haven't 
figured out how to do this yet then you haven't done enough thinking yet. 
Another truism is that if the code is good then the probability is that much 
more time went into designing it than into writing it.

>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. 

Your goals may all be good, but it's a fallacy to use a good goal to justify a 
bad practice.

>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.  

Why should we needlessly complicate our design for something that doesn't need 
to be done?

Have you considered the fact that changing something of that nature would 
involve retesting large parts of brltty's core and all of its braille device 
drivers?

It seems to me that you think we have nothing better to do with our time than 
to change everything each time a new theory raises its head. The reality is 
that we don't. We've maintained a high quality product. Can you give me just 
one good reason to put that at risk just because theorists don't think we've 
done everything the best possible way? I myself much prefer high quality in the 
product and contentment amongst its users to theorist passification.

>So let me be on this point, please!

If your goal is to eventually have your driver added to brltty then I recommend 
that you listen to me. :-) You could, of course, stir up a rebellion amongst 
the other brltty developers, or, perhaps, stage a coups, take over the whole 
thing, and run it your way.

>Is there a standard way to snoop the serial connection with brltty?  

That depends on what you mean by "snoop". The basic answer, though, is yes, but 
only if you do your I/O the way I originally suggested that you do it, which is 
to use brltty's generic I/O functions. That's where we put all such generic I/O 
concepts. You may recall my statement, above, that generic capabilities should 
always be put where they offer the broadest benefit.

>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. 

Why not set up a virtual machine, run brltty on that virtual machine, and 
monitor the serial I/O to/from that virtual machine. Now that's a truly 
theoretical way to resolve your problem. :-) Oh - I forgot - you probably have 
other, much more important, things to do with your time than to pursue such 
needlessly theoretical concepts.

>Can brltty act as a dummy device? 

No. It's not a device.

>How do you inspect serial communications when writing drivers?

By instructing the generic I/O functions to log what I want to look at.

-- 
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://FamilyRadio.com/                   | http://Mielke.cc/bible/