LCDproc development and user support list

Text archives Help

[Lcdproc] ppdev support

Chronological Thread 
  • From: bsdfan AT (Markus Dolze)
  • Subject: [Lcdproc] ppdev support
  • Date: Fri Mar 31 19:40:02 2006


I too have some comments on this:

A while ago I tried to rewrite the hd44780-winamp with something similar
to ppdev (ppbus on FreeBSD). I posted the result to this list earlier.

From that experience I would suggest:

- Keep the existing port.h either for architures that do not have
ppdev/ppbus support or for drivers not beein rewritten to use a generic
API (which should be no problem for drivers contained in lcdproc code).

However, the biggest task will be to change the style the driver
communicates it settings to the "port layer", because all drivers manage
the port number to use on their own right now.

- To keep the driver simple, there should be only one interface to
port.[ch], and these files should decide what to use. But if someone
really wants to use inb/outb (because the display is connected to some
strange device not available as a parallel port to the OS) he should
have the possibility to do so.

- If it can not be handled dynamically via the config file if a specific
driver uses ppdev/ppbus or inb/outb it should be a compile time option
set be the compiling user. Not just some "autodetect" mechanism, perhaps
a "with-" option to configure.

Some ideas:
/* new api not conditional for all new drivers*/
/* keep existing stuff for old drivers */
#ifdef xyz

some_generic_api_calls() {
if (driver wants ppdev/ppbus)
#elseif HAVE_PPBUS
/* fall back */

Just my thoughts...

Guillaume Filion wrote:
> Hi Andrés,
> Andrés Trapanotto a écrit :
>> Guillaume Filion wrote:
> 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);
> -----

Archive powered by MHonArc 2.6.18.

Top of page