[Wine] Need help to get LCDHype flying with Parallel-Port
martin at gregorie.org
Mon Jan 25 09:39:57 CST 2010
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
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
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
More information about the wine-users