[Wine] Need help to get LCDHype flying with Parallel-Port

[Martin Gregorie]

On Mon, 2010-01-25 at 08:59 -0600, lsmod wrote:
> My problem is that i am not a C-Programmer.
> I already understand that the I/O communication is not implemented in wine in NT+ emulations.
> 
> The programmer of LCDHype is programming in C and he also would write a driver dll (or direct access in LCDHype), when he knows what he must do.
> But this is not so easy here, because this "driver" has not to work like in windows and it is not the same like working in linux.
> What i mean is the question in which way the program is "captured" in wine?
> 
> How this driver must be written that it has the needed access to the parallel port?
> We don't have an idea how to bridge between the windows application through wine to the linux kernel?
> 
Linux traditionally names its parallel ports /dev/lp0, /dev/lp1, ...
WINE's equivalent would be to put symbolic links in .wine/

You could try writing the driver to write to LPTn: and putting a symlink
in .wine/dosdevices: 

	ln -s /dev/lp1 LPT2: 

but beware that by default all parallel ports are owned by root.
Read/write access to them is restricted to root and members of the lp
group. This means that either you'll need to include the user where
you're running LCDHype in the lp group or you'll need to extend your
parport's access rights at boot time. There are two choices here: either
by adding a chmod command to /etc/rc.d/rc.local "chmod uga+rw /dev/lp1"
or by adding a local rule to /etc/udev/rules.d to extend its access
permissions.

If none of this works there is a less obvious way:

- write the .dll to send commands and accept responses over a socket.

- write a Linux C server that talks to your device over the parport
  and uses a socket to accept commands and return responses to the .dll.
  This should be a pretty simple program to write since it only needs to
  deal with a single socket connection at a time. It goes without saying
  that, unless the parport is supplied via the .dll, it will need a way
  to configure the port it is to use, but that's also easy enough.
 
- If you treat the server as a daemon (start it at boot time and run it
  as a root process) or run it under the 'super daemon' xinetd it will
  work with the parport's default access permissions: otherwise my
  previous remarks about access permissions are relevant to this
  approach.

 
Martin