Hi, > Can you comment some more on how this driver can be > used and whether it's complete or what is still missing? After a quicklook, it seems complete *and* fully compatible with R5 parallel ports driver API. The public parallel_driver.h header, being identical to Be's one, could needs some copyright care before being added to headers/os/drivers folder, though. > I assume applications open() the device and then use ioctl()? > Or is there already some code in the API kits that can make use of this > (i.e. does the ioctl() interface follow some established Haiku standard)? Beside Parallel Port print transport add-on, nothing interface with /dev/parallel/* devices yet. For hotplug printer detection and model identification, the ioctl() interface would be usefull, though, as it's not a feature supported by this transport add-on (list_transport_ports() simply report every parallel port supported, not the printers detected on it...), contrary to the USB transport one, which does it in a nice way. > Also I can't tell how severe the other items in the TODO are and > whether they limit usability of the driver or not. Except for ieee1284 full compliance maybe, I don't see stoppers. > The code has some consistent violations of the coding style... :-) If others > agree we could apply it as is nevertheless, since it's pretty much a closed > component. +1 Then I'll hunt down for my old parallel Canon BJ-220 ;-) If anyone could point at some code detecting printer presence and model over a parallel port, please share it on a new Trac ticket... Bye, Philippe.