LCDproc development and user support list

Text archives Help


[Lcdproc] ppdev support


Chronological Thread 
  • From: gfk AT logidac.com (Guillaume Filion)
  • Subject: [Lcdproc] ppdev support
  • Date: Fri Mar 31 14:17:02 2006

Hi Andrés,

Andrés Trapanotto a écrit :
> Guillaume Filion wrote:
>> But anyway, Andrés has already made a compatibility layer, right?
>
> Yes :)
> I've to finish it, but It's ok for me to sontinue supporting both ways
> to access the hardware.
> Anyway I thing that we should (at least) re-define the input-output
> functions to support both schemes... So, please check my patch while I'm
> finishing pp_port() to support every old functions in the new scheme...

I've looked at it, and it's pretty good. It's certainly something that
I'd like to see committed in the project (after the next release). What
I'm not sure about is the necessity of redefining the port.h API.

In the same order of ideas, here are some comments about your comments
in port.c:

> ppdev support:
> - If the drivers is writted to work with ppdev, it has to have a
> pp_driver where the ppdev data and descriptors will be stored. I can
> be part of private_data :) Then, the driver have to use pp_* functions
> to open/close/write/read the parallel port
> [...]
> - The idea is that drivers can be modified to use ppdev, and then
> port_* functions can be removed.

I don't think that this is the way to go. A driver should not expect a
specific way of accessing the parallel port, it should always use a
generic API. I'm not against changing the API if it's necessary, but
there should always be a generic API between the driver and the parallel
port.

> - If the driver isn't [written] to work [with] ppdev, you can compile
> the project using USE_PPDEV and it will use ppdev anyway :)

That's the spirit behind port.h. The configure script would do some
tests and determine what is the best way to access the parallel port, be
it ppdev, inb/outb or some other funky way. The driver should not make
any decision regarding this, it should always use the generic API.

Regarding changes to the API. I'm not familiar with ppdev, but by
looking at your code, I see that the port number is not used at all by
ppdev, so that may need to be adjusted. I see in port.c that you tried
using a switch(port) but it looks like it didn't work.

Also, it may be a good idea to change
port_out(port,val) and port_in(port)
to
port_ctrl_out(val), port_data_out(val) and port_status_in()
or something similar.

It would simplify your port.c by removing the need for the
switch(port&0x03). And it would also make it easier to read the driver
code, here's an example from hd44780-winamp.c (function
lcdwinamp_HD44780_senddata):
-- before --
// 40 nS setup time for RS valid to EN high, so set RS
port_out (p->port + 2, portControl ^ OUTMASK);

// Output the actual data
port_out (p->port, ch);
-- after --
// 40 nS setup time for RS valid to EN high, so set RS
port_ctrl_out (portControl ^ OUTMASK);

// Output the actual data
port_data_out (ch);
-----

I'm throwing ideas in the air right now. I'm not sure if they make a lot
of sense. From your point of view, what changes would you like to see in
the existing port.h API?

Regards and keep up the good work! :-)
GFK's
--
Guillaume Filion, ing. jr
Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/
PGP Key and more: http://guillaume.filion.org/




Archive powered by MHonArc 2.6.18.

Top of page