Re: [PLUG] Parallel port with Debian 12

On Wed, Jan 15, 2025 at 08:28 N. Albert via plug <plug@lists.phillylinux.org> wrote:

On 1/14/2025 7:57 AM, Rich Freeman wrote:
> On Mon, Jan 13, 2025 at 8:55 PM N. Albert via plug
> <plug@lists.phillylinux.org> wrote:
>> On 1/13/2025 8:36 PM, Michael Lazin via plug wrote:
>>
>>> I don't think you can write to the parallel port with bash
>>> directly.
>> Hmm, from some research I did initially, it seemed like it should be
>> possible
> So, it has been eons since I've used this sort of hardware on linux,
> but I suspect it depends on your printer. Really old printers
> probably would just accept ascii text they receive and print it,
> unless preceded by escape codes and such. More modern printers may
> not still have this sort of legacy compatibility and may expect
> everything to be encoded in some sort of command language. Granted,
> if the printer actually HAS a parallel port it is probably for legacy
> purposes, but if it is just really old it might just be from the days
> when everything used Windows but USB wasn't ubiquitous. Bottom line
> is that it might depend. If you've been able to print this way on
> this particular printer in the past though I'd say it seems likely to
> work. I'm also not sure if CUPS can create a device node and then
> just translate via the printer driver.

Yup, that's how I'm printing to it under Windows. I'm not using any
drivers either. I did look at the programmer's manual for it at the time
(it's a Star Micronics TSP600 Thermal Printer) and that indicated I
should be able to write raw text directly to the printer (there are also
some special codes that can be used, which I don't need). When I send a
job using smbclient, I can use raw text / newlines to format it the way
I want (not that there is much formatting control). All my jobs are a
single line at a time anyways.

I realize it can be made with CUPS but I don't need any of its features,
it doesn't have the best security reputation of late, and I wanted to be
able to write directly to the device file from the shell or the address
in a C program. It would be like using a web browser when I just need
netcat.

> As far as your specific issue I can think of a few things that could
> go wrong, but that would be getting really into the weeds and I
> haven't dealt with a parallel printer in decades so I'm not sure you'd
> benefit from a lot of speculation. Questions that come to mind are
> whether the kernel driver is enabled, and whether the udev rule is
> sticking a device node where you think it ought to.
>
>> the ability to write raw bytes directly to the ... device address (e.g. 0x378)
> That isn't something done trivially. First, it is normally the role
> of a kernel module and you'd need to run as root to use instructions
> like OUT.

I tried everything as root, so permissions definitely weren't the issue.

> Second, that IO address isn't the printer - it is probably
> just a base address of a series of addresses that control the parallel
> port at a low level and actually sending data to it probably requires
> a bunch of initialization/etc.

I omitted it in my example, but I was also calling ioperm before like
most of the examples have. I dug around and found the test program I
cobbled together back then:

root@debian:/usr/src/pp# cat pp.c
#include <stdio.h>
#include <unistd.h>
#include <sys/io.h>

#define baseport 0x378

int main(int argc, char *argv[])
{
         if (ioperm(baseport, 3, 1)) {
                 perror("ioperm");
                 return -1;
         }
         outb('t', baseport);
         outb('e', baseport);
         outb('s', baseport);
         outb('\n', baseport);
         return 0;
}
root@debian:/usr/src/pp# ./pp
root@debian:/usr/src/pp# echo $?
0
root@debian:/usr/src/pp#

A bit sloppy, this was just going to be a proof of concept, but it only
proved it wasn't working :(
Program runs successfully, but nothing happens. Similar experience when
redirecting text to the appropriate parallel port device file.

> I'd have to go dig up the old docs on
> how those interfaces work. It isn't actually that hard (that sort of
> hardware is 1970s technology and very simple), but it isn't like you
> can just write a string in python to an IO port. Once initialized you
> probably could just loop through a string and send one byte at a time.
>
> Really though you should just figure out how to get the kernel to do its job.

Yup, that's kind of where I left of. I think both the C program and
writing to the device file should work if the kernel has everything
loaded right.

> You might try running "udevadm info -t" and looking for parport
> somewhere in the output. That might give you some clues as to whether
> udev knows about the device and where it put the device node. Your
> kenrel seems to know about it from dmesg mentioning it, so I'm
> guessing it isn't a missing kernel driver, but again I haven't messed
> with those ports in ages so maybe I'm missing something there.

I definitely get a lot of stuff when doing that (and this is new for me,
I hadn't tried it before). Output below.

I think there is definitely stuff loaded (maybe some of the drivers). My
best guess is that *something* is missing, and I'm not quite sure what
that is. I only say that because the lspci output I shared before was
empty, and examples I found online showed it being non-empty.

root@debian:/usr/src/pp# udevadm info -t | cat | grep parport
├─/bus/parport
│ ┆ P: /bus/parport
│ ┆ M: parport
│ ┆ E: DEVPATH=/bus/parport
│   ┆ P: /bus/parport/drivers
│   ┆ E: DEVPATH=/bus/parport/drivers
│   │ ┆ P: /bus/parport/drivers/daisy_drv
│   │ ┆ E: DEVPATH=/bus/parport/drivers/daisy_drv
│     ┆ P: /bus/parport/drivers/ppdev
│     ┆ E: DEVPATH=/bus/parport/drivers/ppdev
│   ├─parport_pc
│   │ ┆ P: /bus/platform/drivers/parport_pc
│   │ ┆ M: parport_pc
│   │ ┆ E: DEVPATH=/bus/platform/drivers/parport_pc
├─/devices/parport0
│ ┆ P: /devices/parport0
│ ┆ M: parport0
│ ┆ U: parport
│ ┆ T: parport
│ ┆ E: DEVPATH=/devices/parport0
│ ┆ E: SUBSYSTEM=parport
│ ┆ E: DEVTYPE=parport
├─/devices/platform/parport_pc.888
│ ┆ P: /devices/platform/parport_pc.888
│ ┆ M: parport_pc.888
│ ┆ V: parport_pc
│ ┆ E: DEVPATH=/devices/platform/parport_pc.888
│ ┆ E: DRIVER=parport_pc
│ ┆ E: MODALIAS=platform:parport_pc
│ ┆ E: ID_PATH=platform-parport_pc.888
│ ┆ E: ID_PATH_TAG=platform-parport_pc_888
│ └─ppdev/parport0
│   ┆ P: /devices/platform/parport_pc.888/ppdev/parport0
│   ┆ M: parport0
│   ┆ N: parport0
│   ┆ E: DEVPATH=/devices/platform/parport_pc.888/ppdev/parport0
│   ┆ E: DEVNAME=/dev/parport0
├─/module/parport
│ ┆ P: /module/parport
│ ┆ M: parport
│ ┆ E: DEVPATH=/module/parport
├─/module/parport_pc
│ ┆ P: /module/parport_pc
│ ┆ M: parport_pc
│ ┆ E: DEVPATH=/module/parport_pc
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug