[Lcdproc] use lpt hd44780 on usb lpt addapter ?

[Stefan Herdler]

Peter Marschall wrote:
> On Sunday, 4. February 2007 21:47, Stefan Herdler wrote:
>   
>> NA NABOO wrote:
>>     
>>> /dev/usb/lp0 instead of 0x378 ?
>>>       
>> LCDProc controls the parallel-port directly via direct IO calls. So the
>> port address (like 0x378) of the parallel-port is needed.
>>
>> Last year there was a attempt to switch to /dev/parportX and ioctl() but
>> it had been canceled. Afaik problems with the multi-platform stuff but I
>> don't know it exactly.
>>     
>
> I admit, one of the main issues of the ppdev patch was that
> instead of using functions with parameters, it defined variables
> in a struct and used them later in the called function.
>   
I've just glanced through a view of the mails. At that time I was to 
busy to take a closer look.
> I.e.
>   port->control = 3
>   set_control(porthandle);
>
> and in set_control() something like:
>   ioctl(porthandle, port->control)
>
> IMHO it is in those cases cleaner to have
>   set_control(porthandle, 3);
> as it does makes everything explicit and does not use implicit parameter 
> passing using structs or objects.
>   
I agree, it is the clearer way, I think. Specially for LCDproc beginners 
who just want to write a driver.
> BTW the current ioport functions (whgich are an abstraction as well) use the 
> latter form.
>
> But the idea of rewriting that part is not dead, since in the long run, it is 
> the clean way to go: multi architecture support, ...
> Unfortunately for me the rewrite is of fairly low priority, as I do not have
> a display connected to the parallel port.
>
> So, any help is welcome.
>   
I use the serial connections for all my displays (quiet common for 
driver called serialVFD, I think ;-) ).
The only parallel connected display I have for testing purposes. 
Therefore the parallel connection doesn't have priority me too, but I 
will adapt the driver if any changes are coming.

Here are the points where I'm not happy with current IO-call implementation:
- LCDproc has to be run as root
- Higher CPU-Load (up to 15% on a 2GHz CPU with my NEC-VFD) compared to 
the serial connection (about 1%).
The timing delays are not the most efficient way, I think. In my 
VFD-parallel-wiring the BUSY is connected, so the VFD should act like a 
Printer. I expect a kernel driver with interrupt support would bring the 
CPU-Load down to the level of a serial connection.
- USB-Parallel adapters can't be used.
My VFD-parallel-wirings should be compatible.

Regards
Stefan