Re:Emulate legacy printer drivers for CUPS with QEMU
by dehrmann on Friday May 29, 2020 @12:39PM
(#23352173)
Reminds me of ndiswrapper. Linux doesn't support your network card? Use the Windows drivers! The time I used it, even with the adapter layer, it was more stable than the native Linux drivers.
Re:Emulate legacy printer drivers for CUPS with QEMU
by cbhl on Friday May 29, 2020 @01:34PM
(#23352939)
And ndiswrapper ran binary drivers. Literally ran the machine code and provided hooks to make the driver work.
Of course, that meant you couldn't plug a Windows-only USB Wifi stick into an ARM machine (say, a Raspberry Pi 1) and use ndiswrapper. Luckily, Broadcom added Wi-Fi to the newer Pis...
Re:Emulate legacy printer drivers for CUPS with QEMU
by tyingq on Friday May 29, 2020 @09:28AM
(#23349731)
That's an interesting approach. For these "win printers" that need host-side processing, another solution is this generic HBPL cups driver: https://github.com/mikerr/foo2zjs
Re:Emulate legacy printer drivers for CUPS with QEMU
by asveikau on Friday May 29, 2020 @11:39AM
(#23351260)
Wait. Their "legacy driver I need qemu to run" is foo2zjs? The gpl thing that I remember being in a bunch of Linux distro package repos? The one that I have run on arm just fine?
Re:Emulate legacy printer drivers for CUPS with QEMU
by Tade0 on Friday May 29, 2020 @09:29AM
(#23349736)
A few years ago my father had a similar problem so I "emulated" the drivers by firing up a VirtualBox machine with Windows XP, which had them, because the printer was from that era.
Re:Emulate legacy printer drivers for CUPS with QEMU
by asveikau on Friday May 29, 2020 @10:53AM
(#23350595)
I run lpd on a raspberry pi to share my printer. I used to share it to Windows hosts with samba but then I realized Windows supports lpd printers. (As does Mac and anything Unix-like.)
I am probably 20 years late in saying this, but I honestly don't know why cups is a thing. lpd works fine and has always struck me as simpler. It's smaller with fewer dependencies. This config is way more complicated than mine. Any time people talk about Unix printing they always assume you mean cups.
Re:Emulate legacy printer drivers for CUPS with QEMU
by kstrauser on Friday May 29, 2020 @05:34PM
(#23355815)
LPD was awesome for sending a file, as-is, to a pre-configured printer. CUPS is awesome for changing things on the fly, like color vs. black-and-white or two-sided printing, or for giving clients enough information about the printer that they can automatically configure the correct driver.
Re:Emulate legacy printer drivers for CUPS with QEMU
by hedora on Friday May 29, 2020 @11:23AM
(#23351018)
I don’t think LPD supported auto discovery or printer-specific configuration dialogs.
Cups is a bit too complicated for my taste though. Some settings live in the print dialog, others at localhost:631 (which password does it want, again?), and some are only accessible in /etc.
Re:Emulate legacy printer drivers for CUPS with QEMU
by bluGill on Friday May 29, 2020 @01:59PM
(#23353312)
If you only have one printer CUPS doesn't do much. If you have hundreds of printers it starts to make sense.
Though they system we have at work where you print and then go to whatever printer and sign in makes more sense. The printout isn't there when you arrive, but at least it isn't on some printer in a different city.
Re:Emulate legacy printer drivers for CUPS with QEMU
by b3lvedere on Friday May 29, 2020 @10:14AM
(#23350181)
Did something similar with an old Dymo LabelWriter 320 which does not work on Windows 10. So i connected it to a Raspberry Pi, installed Cups, compiled the Dymo drivers and now i have a small print server.
Re:Emulate legacy printer drivers for CUPS with QEMU
by fithisux on Friday May 29, 2020 @09:42AM
(#23349864)
It would be better if companies released documentation. Governments should have done their job. Doing. the "emulator" thing is a short term solution. Continuing the emulator thing is like agreeing that governments can get away by not doing their job.
Re:Emulate legacy printer drivers for CUPS with QEMU
by Wowfunhappy on Friday May 29, 2020 @10:51AM
(#23350569)
Even if the documentation was public, there's no guarantee anyone would take the time to get drivers working on ARM in modern Linux.
I actually think emulation is a good long-term solution for legacy applications. My NES rom of Super Mario Brothers is probably the most cross-platform and future-proof piece of software on my computer, because every platform has an NES emulator! You write (or port) an emulator once per platform, and suddenly the whole NES library opens up.
Re:Emulate legacy printer drivers for CUPS with QEMU
by boudin on Friday May 29, 2020 @09:50AM
(#23349941)
Or having to opensource drivers and firmwares for the hardware they decide to stop maintaining.
This is such a waste of hardware, especially for things that don't age much like printers.
Re:Emulate legacy printer drivers for CUPS with QEMU
by myself248 on Friday May 29, 2020 @09:38AM
(#23349830)
I wonder if this overall concept can be done for Synaptics touchpad drivers. Just wrap them in an emulator so I can use the vendor's drivers that work well.
Re:Emulate legacy printer drivers for CUPS with QEMU
by riedel on Friday May 29, 2020 @04:12PM
(#23354919)
qemu was the only way I could my fathers printer working on his new arm chromebook by installing cups on the Linux subsystem . It is really ridiculous how many Linux supported printers only support x86 .
Of course, that meant you couldn't plug a Windows-only USB Wifi stick into an ARM machine (say, a Raspberry Pi 1) and use ndiswrapper. Luckily, Broadcom added Wi-Fi to the newer Pis...
Are there any other manufacturers still bothering with USB wifi devices other than Realtek and Mediatek?
What about GPU drivers? Should I try that way to run AMD Catalyst Windows driver instead of Mesa under Linux for ATI Radeon Xpress 1250?
Which definitely contains 32-bit x86 code.
https://github.com/mikerr/foo2zjs
Still in debian. https://packages.debian.org/buster/printer-driver-foo2zjs
I didn't understand it too.
Worked like a charm.
I am probably 20 years late in saying this, but I honestly don't know why cups is a thing. lpd works fine and has always struck me as simpler. It's smaller with fewer dependencies. This config is way more complicated than mine. Any time people talk about Unix printing they always assume you mean cups.
Cups is a bit too complicated for my taste though. Some settings live in the print dialog, others at localhost:631 (which password does it want, again?), and some are only accessible in /etc.
Though they system we have at work where you print and then go to whatever printer and sign in makes more sense. The printout isn't there when you arrive, but at least it isn't on some printer in a different city.
I actually think emulation is a good long-term solution for legacy applications. My NES rom of Super Mario Brothers is probably the most cross-platform and future-proof piece of software on my computer, because every platform has an NES emulator! You write (or port) an emulator once per platform, and suddenly the whole NES library opens up.
[1] https://en.m.wikipedia.org/wiki/NDISwrapper