Parallel Interface

[wallyqt]

high_flyer,

you are right, its confusing because i didn't understand it myself not entirely.
I want to use the kernel-driver of parapin which i load during boot.
After the driver is once loaded i do not want to use root anymore.

In command-line apps it works perfect, but i have problems to close the
device properly in a kde-qt-app.

i think i should use Qiodevice.h and not mixing old and new stuff together,
but i am not a good programmer. So i ask in this forum.

As far as i understand you code sample - it needs root previleges.
But i want to use the parapin stuff also in a larger application which not should run as root.

Maybe i do some fundamnetal error

cheers wally

[high_flyer]

I want to use the kernel-driver of parapin which i load during boot.

No, you want to use the user space module
Only the system is allowed to access the kernel space module.
Read the parapin documentation.

The problem with QParaport is that it is written for Qt3.
And I haven't had a look at this code for a very long time, so I don't know how easy it should be to port it to Qt4. (I forgot about this during the last post)
But I think it should be just a matter of changing the header deceleration.

As far as i understand you code sample - it needs root privileges.

The *code* doesn't require root privileges.
Under linux, you can set access privileges using the chmod command.
read the chmod command man pages for usage. (its simple)

i think i should use Qiodevice.h and not mixing old and new stuff together,

QIOdevice could be good if you'd want to implement the driver your self.
But if you use the ready made parapin driver, all you can do is either wrap it (as I did with QParaport) or use it directly.
It has nothing to do with mixing new and old.

[wallyqt]

high_flyer

Thanks for your patience and explanation.

Any concrete idea what i could do to find the problem
with close(device) function in the code above.

Gnu debugger and system messages do not have
any interesting outputs on this problem.

cheers wally

[high_flyer]

yes - use the user space module.
You should not access kernel space from user space.

[high_flyer]

read the parapin user documentation in the link I posted before on this thread.
Specifically look for the section:
"Parapin Basics
Userspace version and kernel version "

[wallyqt]

high_flyer

for me the parapin documentation sounds as follows:
There is a C library version and a Kernel Module version with a device driver.

Quotes from parapin documentation:

C library version:
Programs using Parapin must be running as root when they are initialized.

Kernel-Module version:
Before the parapindriver device interface may be used, an entry in /dev must be created that corresponds to the device driver module loaded in to the kernel

Once parapindriver is successfully loaded, and a corresponding /dev entry is in place, initialization and shutdown of the parallel port are easy. To initialize the parapin system, just call open(2) on the /dev entry as you would any other device file:

int device;
device = open("/dev/<device-name>", 0);

if (device < 0) {
fprintf(stderr, "device open failed\n");
exit(-1);
}

To shutdown the parapin system you simply have to call close(2):

close(device);


I want to use the last one and excepting the "close(device) everything is ok.


cheers wally

[high_flyer]

Ok, I see what you mean.
It has been quite long since I used this, so I guess I need to read the docs again

Did you do what is says in the docs about initializing the driver?

int pin_init_kernel(int lpt, void (*irq_func)(int, void *, struct pt_regs *));
AND :
void pin_release();

[wallyqt]

high_flyer

No, because afaik this is the initialization for the C-library version.
During boot my system do the following (of course as root) :


DEVNAME="ppdrv_device"
depmod
modprobe kparapin
modprobe parapindriver devname=${DEVNAME}
mknod /dev/${DEVNAME} u `grep $DEVNAME /proc/devices | cut -d " " -f 1` 0
# Change mode and ownership here if necessary
chmod 777 /dev/${DEVNAME}
chown root /dev/${DEVNAME}
chgrp root /dev/${DEVNAME}

After this is done i acces the parapellport (as user) by opening the device:

pardevice = open("/dev/ppdrv_device", 0);
if (pardevice < 0) {
fprintf(stderr, "pardevice open failed\n");
exit(-1);

from this point on i can simply acces the parallelport with the ioctl command, e.g.:

ioctl(pardevice, PPDRV_IOC_PINMODE_OUT, LP_PIN02);
ioctl(pardevice, PPDRV_IOC_PINSET, LP_PIN02 | LP_PIN03)

I preferred this because i added some parts to the KSIMUS Application.
Its a Electronics simulator by Rasmus Diekenbrock.
I want to avoid the need of root access during the simulator is accessing
the parallelport. It works perfect in KSIMUS (also the close(device) command
which is the reason i wrote here.

In a simple new Kdevelop project, just for open the device,
setting some pins and close the device, this mini application
doesn't work as expected.

When i call "close(device" all of the widgets ( 3 pushbuttons for open/set/close)
disappear and thats it. I have to kill the process.

I wrote here in QT-Centre because i think its not a problem of parapin.
Parapin works perfect e.g. in the ksimus enveronment.

I am sure i am making some coding or logical errors in my code.
( maybe the close(device) command from unistd.h is not welcome.

Also some hint is desireable how to trace what is going on in the app
after calling close(device) and the "crash"

"gdb" and the system messages do not contain strange infos on this.

cheers wally

[high_flyer]

No, because afaik this is the initialization for the C-library version.

read again:

The Kernel Module Version

Initialization and shutdown in the kernel flavor of Parapin is done using the following two functions:

int pin_init_kernel(int lpt,
void (*irq_func)(int, void *, struct pt_regs *));
void pin_release();

The first function is not as intimidating as it looks. Its first argument, lpt, is the parallel port number that you want to control. The number references the kernel's table of detected parallel ports; 0 is the first parallel port and is a safe guess as a default.

The second argument, irq_func, is a pointer to a callback function to be used for servicing interrupts generated by the parallel port. This argument may be NULL if the driver does not need to handle interrupts. Details about interrupt handling are discussed in Section 9.

pin_init_kernel will return 0 on success, or a number less than 0 on error. The return value will be a standard errno value such as -ENODEV, suitable for passing up to higher layers. If Parapin initialization fails, the driver must not call Parapin's other functions. As described earlier, this requirement is not enforced for efficiency reasons.

When a driver is finished controlling the parallel port using Parapin, it must call pin_release. The state of the parallel port's interrupt-enable bit will be restored to the state it was in at the time pin_init_kernel was originally called.

Parapin's pin_init_kernel and pin_release functions work with the Linux kernel's standard parport facility; as noted above, the parport module must be loaded along with any module that uses Parapin. When initialized, Parapin will register itself as a user of the parallel port, and claim exclusive access to that port. This means no other processes will be allowed to use the parallel port until pin_release is called.

[wallyqt]

high_flyer

int pin_init_kernel(int lpt,
void (*irq_func)(int, void *, struct pt_regs *));
void pin_release();

All this stuff, especially "pin_init_kernel" is contend of "kparapin" and "parapindriver",
which i successfully compiled and "moddprobe" inserted seperately before.

All this is running. I can open the device, setting and clear all pins.
In a command line application and in ksimus i can even close it without any trouble.

Everything is nice except the close(device) command in a primitiv kde application
i tried to build.
Just this my problem.

cheers wally

[high_flyer]

hmm...
did you check the standard error after open()?

[wallyqt]

hmm...
did you check the standard error after open()?

pardevice = open("/dev/ppdrv_device", O_RDWR);
if (pardevice < 0) {
fprintf(stderr, "pardevice open failed\n");
return -1;
}

Yes, if there would be a problem, i would not be able to set and clear pins.
At least i assume so.

cheers wally

[wallyqt]

i just put a Messagebox behind the critical close(device) instruction
and achieved a nice crash with backtrace-log.
Maybe this could clear the situation:

int kparappWidget::pushButtonClose_clicked()
{
close(pardevice);
QMessageBox::about(this, tr("About Application"),
tr("The <b>Application</b> example demonstrates how to "
"write modern GUI applications using Qt, with a menu bar, "
"toolbars, and a status bar."));

return 0;
}

Backtrace log after crash:

System configuration startup check disabled.

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb6cf36d0 (LWP 21378)]
[KCrash handler]
#9 0xb6e21228 in main_arena () from /lib/libc.so.6
#10 0xb7461440 in QObject::QObject () from /usr/lib/qt3/lib/libqt-mt.so.3
#11 0xb749741d in QWidget::QWidget () from /usr/lib/qt3/lib/libqt-mt.so.3
#12 0xb75e7852 in QDialog::QDialog () from /usr/lib/qt3/lib/libqt-mt.so.3
#13 0xb7612c70 in QMessageBox::QMessageBox ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#14 0xb7612d59 in QMessageBox::about () from /usr/lib/qt3/lib/libqt-mt.so.3
#15 0x0804ec16 in kparappWidget::pushButtonClose_clicked (this=0x80eb560)
at /home/op/sda-2/Programming/kdevelop-work/kparapp/src/kparappwidget.cpp:82
#16 0x0804f23a in kparappWidgetBase::qt_invoke (this=0x80eb560, _id=48,
_o=0xbfc780a8) at ./src/kparappwidgetbase.moc:104
#17 0x0804e999 in kparappWidget::qt_invoke (this=0x80eb560, _id=48,
_o=0xbfc780a8) at ./src/kparappwidget.moc:108
#18 0xb7460f1d in QObject::activate_signal ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#19 0xb7461b5d in QObject::activate_signal ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#20 0xb77a3b5c in QButton::clicked () from /usr/lib/qt3/lib/libqt-mt.so.3
#21 0xb74f4bfd in QButton::mouseReleaseEvent ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#22 0xb7499880 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#23 0xb74019c7 in QApplication::internalNotify ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#24 0xb7402909 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#25 0xb7b7dd32 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#26 0xb73a0f57 in QETWidget::translateMouseEvent ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#27 0xb73a00ff in QApplication::x11ProcessEvent ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#28 0xb73b098a in QEventLoop::processEvents ()
from /usr/lib/qt3/lib/libqt-mt.so.3
#29 0xb74187f0 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#30 0xb7418686 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#31 0xb740157f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#32 0x0804dec2 in main (argc=134547724, argv=0xb6e212e2)
at /home/op/sda-2/Programming/kdevelop-work/kparapp/src/main.cpp:69


cheers wally

[high_flyer]

Is this a Qt3 application?
And is the message executed?

[wallyqt]

No, you want to use the user space module
Only the system is allowed to access the kernel space module.
.

yes - use the user space module.
.

I think using the above code i do so hm ?
(now i am completely confused)

cheers wally