2

currently I access the parallel port this way:

ioperm(data->baseaddr,5,1);
outb(0x00,data->controlport);
inb(data->statusport);

The big disadvantage: it requires root-privileges and works with real parallel port hardware only (means USB-2-LPT converters are not supported).

So: is there an other way tho read/write data from/to parallel port?

Thanks!

Elmi
  • 5,899
  • 15
  • 72
  • 143
  • Overall, what are you trying to do? I can guess, but it would be good if you explained what it is, since there may be more than one possible solution here. – Mats Petersson Dec 17 '14 at 08:46
  • @Mats Petersson: send control data to a connected device. This device is a (really very exotic) XY-table expecting ASCII motion commands at parallel port. – Elmi Dec 17 '14 at 09:51
  • Most USB to parallel adapters are specifically designed for use with printers. They are not compatible with all parallel devices. –  Dec 17 '14 at 09:54
  • 1
    this link: is a page that describes the two methods of accessing the parallel port under Linux. the usual name for the port is: /dev/parport0 – user3629249 Dec 17 '14 at 11:02

1 Answers1

1

As you mentioned, the user must have privileges to access the parallel port in order for the executable to run successfully. Normally, only root users have privileges to access the ports, so the program must be run with root privileges. However, It should be possible to enable non-root users to run the executable by doing the following:

1) Make root the owner of the executable. One way to do this is to compile the program as root.

2) Give non-users the right to execute the program, but such that the program is run with root rights when run by non-root users. You can set the program to be run with the owner's rights (i.e. root's rights) using the following command (as root): chmod +s /name/of/executable

mti2935
  • 11,465
  • 3
  • 29
  • 33
  • 1
    The solution mentioned above requires root-privileges because it performs direct hardware accesses. Hacking around with the permissions of the executable would not be a suitable solution since it opens the same security holes. So the solution mentioned in comments above with access to a device in "/dev/" is what I'm looking for. – Elmi Dec 18 '14 at 07:35