Hello together, i want to run LCDHype in Linux under wine, because there is no adequate other program that supports graphically LCD-Displays. I already opened a discussion in the forum of LCDHype (sorry - is in german language): http://lcdhype.condense.de/index.php?showtopic=4963 I already found an older version (V 0.6) of LCDHype that installs and the frontend is up and running. But now i am at the point where i need to get the Parallel-Port running. Many LCD-Displays are connected directly to LPT1 also my KS108. The developer of LCDHype is also interested to get this running and he helps as much as possible. Normally LCDHYpe is using the free SPPort95NT Driver to get direct access to the Parport. But this driver fails to load in wine and that does not surprise me. Now is the question how we can get direct access to the Parport in Wine? I already found and tested the hints from here: http://wiki.jswindle.com/index.php/Wine_Registry#Parallel_Port But it's not understandable where the difference between /dev/parport0 and /dev/lp0 should be? Our last try was to test the access with a small Testprogram written by ViRuSTriNiTy in C. But i didn't have success and now we don't know how to progress?
vitamin
2010-Jan-22 16:06 UTC
[Wine] Re: Need help to get LCDHype flying with Parallel-Port
lsmod wrote:> Now is the question how we can get direct access to the Parport in Wine? > I already found and tested the hints from here: > http://wiki.jswindle.com/index.php/Wine_Registry#Parallel_Port > But it's not understandable where the difference between /dev/parport0 and /dev/lp0 should be?Those instructions look complete to me. If done correctly (and if that part still works under Wine) your program should be able to access in/out ports assigned to the parallel port. As for devices - just make sure your user have full access to them: Code: sudo chmod a+rw /dev/parport0 sudo chmod a+rw /dev/lp0
Thank you for the explanation. I already created these symlinks in .wine/dosdevices. But are they necessary? The keys in the registry are pointing direct to the port 378h and the Testprogramm also attempts to write direct to this address. In my tests there where no error message and i have done this tests with my personal user and not as root. I am running Debian Lenny (stable) and here the group lp exists. Now i added my user to this group. In the next step i will try to measure if write attempts will cause toggling the signals on the data bits. Have i understand correct that your proposal with the daemon and socket is for running the application in NT+ emulation?
Martin Gregorie wrote:> You are doing something else: bypassing the Linux drivers by attempting > to talk direct to the hardware. While this may be acceptable with older > Windows versions its not a good idea with Linux.What is a good idea to solve the problem in Linux? At this time i have no idea how the parport is implemented in the Linux-Kernel. But i am optimistic that the kernel will not allow something that is not good for him. [Wink] Martin Gregorie wrote:> It shouldn't matter because AFAIK Wine supports Windows sockets for all > Windows emulations. Sockets is a reliable way of communicating between > Windows programs and Linux native programs.Of course this is a universal solution to cover all the problems. But a separate Linux-daemon is needed and it would be better if we could avoid this, because someone must write him in C. But i will search if maybe someone already has written one. Karsten
1) When the application will run in "Windows ME" emulation it would be the easiest way to do this. But i have seen more problems than in the "Windows 2000" emulation. 2) I asked to change the testprogram, so i hope we can test this. 3) Every workaround is really far away from the original application and should be the last option. The goal was to use the existing engine and drivers to access an graphic LCD-display. If there is much to do in Linux stuff, it would be better to develope in the real linux project. http://ssl.bulix.org/projects/lcd4linux/ Another question: Normally there is shown important system information on an LCD-Display. This information is normally grabbed via the Windows "performance helper api". In Linux nearly all of this information can be grabbed via shell commands from the system. Is it possible to submit a shell command in wine and fetch the output? Karsten
O.K. Most of the interesting things should be found in the /proc. But sometimes it is easier to use a program like sensors for collecting and formatting the informations. For the shell you mean this wiki: http://wiki.winehq.org/Shell32 ? It is not so easy to understand the difference between the kernel drivers for the parallel port. At least all kernel-drivers seem to access the parport driver. With lsmod i can see that the kerneldriver parport is used by ppdev, lp, parport_pc Additional i had found some links that helps understanding the stuff: http://www.mjmwired.net/kernel/Documentation/parport.txt 152 modes Parallel port's hardware modes, comma-separated, 153 meaning: 154 155 PCSPP PC-style SPP registers are available. 156 TRISTATE Port is bidirectional. 157 COMPAT Hardware acceleration for printers is 158 available and will be used. 159 EPP Hardware acceleration for EPP protocol 160 is available and will be used. 161 ECP Hardware acceleration for ECP protocol 162 is available and will be used. 163 DMA DMA is available and will be used. http://www.mjmwired.net/kernel/Documentation/parport-lowlevel.txt 155 PARPORT_MODE_TRISTATE The data drivers may be turned off. 156 This allows the data lines to be used 157 for reverse (peripheral to host) 158 transfers. http://parapin.sourceforge.net/ Parapin makes it easy to write C code under Linux that controls individual pins on a PC parallel port. This kind of control is very useful for electronics projects that use the PC's parallel port as a generic digital I/O interface. http://gramlich.net/projects/parallel_server/index.html The state of this project that it is totally and completely dead!
Thanks. Currently the question is how to access /dev/lp0 directly in the test-program? The Test-program is based on this article: http://logix4u.net/Legacy_Ports/Parallel_Port/A_tutorial_on_Parallel_port_Interfacing.html So the access to the parport is coded through the _inp() and _outp() functions. It is not clear what the libraries are doing here? We are working now in the grey area between Windows and Linux and this is very special. You don't find many informations about such topics ...
Martin Gregorie wrote:> Read this: > http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html > > Download InpOut32.dll and try using it with one of the test programs > referenced from it. If that works, you're home and dry. Just change > LCDHype and its dll to work with InpOut32.dllThat sounds good. I hope ViRuSTriNiTy will make a testprogram with it. Martin Gregorie wrote:> I think they are very simple functions that make direct access to parallel ports for DOS/Windows systems.Of course. But the question was how to access /dev/lp0 in wine with an Windows compiler? I think the only way is to patch the libraries. Martin Gregorie wrote:> Actually, there's rather a lot available and its rather easy to find.I also find this - but i am always skeptical to rely on this, when i see that this information is very old and for kernel 2.4. Too many things have changed. Specially the interfacing with udev in kernel 2.6 Karsten
Sorry - up to now i didn't study the kernel parallel port stuff. But i will try to get more knowledge how this works. As i have understund, the interface must be set into the right mode (ECC, EPP, ...). Then it can be accessed over different functions - correct? What i also cannot understand is why the InpOut32.dll will help? Should it help in NT+ or Win* emulation? As you have written the NT+ should never work, because the functionality of kernel interfacing is not implemented. In the time between i tried out some other simple things. I tried out to pass data direct to /dev/lp0 with the simple shell-command Code: echo "A" > /dev/lp0 This works with no error if an LCD-Display is connected to the parport. When no display is connected the command hangs. I think the reason is that there is no busy-signal on the line. After that i remember another old problem trying to use the parport in wine and tested this again: http://forum.winehq.org/viewtopic.php?p=39025 I would say that there is generally no access to the parport in wine now. Karsten