[Lcdproc] CwLnx display corruption - possible cause and fix

[Dave Platt]

> So the init part of the driver just sends the command to set the display to 
> the speed that LCDd wants it to be, a single operation rather than two.
> 
> Your sending the opposite of the config then the config shouldn't be 
> reliable in all cases if the commands are mis-interpreted when sent at the 
> wrong (for the hardware) speed. You're making the false assumption that the 
> hardware is not matching the config when it may well be.
> 
> As the set/reset method *is* reliable it indicates that speed change 
> commands sent at the "wrong" speed are interpreted correctly so you may as 
> well just send the one the config calls for... Indeed they pretty much have 
> to be interpreted correctly otherwise how does any application set up the 
> device how it wants it? Catch 22...
> 
> It is never safe to assume the state of any hardware, if a particular state 
> is required it must be explicitly configured.

I agree with you - there is a definite Catch 22 involved with this device.
As far as I can tell, this is just something that's built into the device
design.  Or, at least, if there is a way out of the Catch 22, it's not
explicitly documented in the data sheet.

The initialization architecture which was in the driver when I started working
with it, *did* do the "wrong thing" right out of the box... that is,
if you run it right after power-up (when the device is configured at
19200), the first thing it does is send commands at 9600 bits/second.

You may be right, in that it's possible that the device might be
capable of recognizing a change-speed command sent at the "wrong speed"
(e.g. at 9600 when it's configured at 19200) under some circumstances.
Perhaps that's one of the effects of sending a long-space - it may
"prime" the device to be able to recognize a change-speed command
sent at the wrong baud rate.  Once again, this isn't documented at
all in the data sheet - long-space/break/framing-error isn't mentioned
anywhere.

I'll try this out in the next day or so... I'll have the driver
configure the Linux port for the correct speed, send a long-space,
send the correct speed-change command to the device, drain, delay,
and then long-space again.  If a prolonged test cycle shows that
this works as well as the "wrong speed" approach my current patch
uses, then I'll update my patch.  Doing the set-speed operation at
the "right speed" is certainly cleaner, if it actually works
reliably.