-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
papplDevice Improvements for Default Schemes #259
Comments
OK, so I have reservations about this... By far the most common usage of quirks is to force unidirectional mode, which is unnecessary for a real printer application since the driver only reads when it needs to. I'm not sure "delay-close" matters, either. I'm not sure what to do for for "blacklist" and "no-reattach". But the bigger issue is that I don't want PAPPL to have to track/support quirks forever like CUPS has, and in the age of snaps and flatpaks and other containers, even having a common PAPPL "repository" of quirks won't work because the instances are all isolated and might not even have access to a common /etc directory for configuration. |
I think PAPPL's USB backend should support quirks, the same types as CUPS supports and ideally the same syntax of quirks files as CUPS uses. Due to the fact that we use sandboxed packaging (Snap or OCI containers, Flatpak does not work with daemons) more and more often we will not have a central quirk database, but the typical native Printer Application in the future will only support a handful of printers or the printers of one manufacturer. Here the developer of the Printer Application could easily set up a table of the few quirky printers which are supported by this Printer Application. The big database of all known quirks is only needed for the big retro-fitting Printer Applications (like the Ghostscript Printer Application) which will use CUPS-2.x- and/or driver-supplied backends (contained and hidden in the Snap or OCI container) and so have all the quirks on board (pappl-retrofit supports using CUPS 2.x backends). |
@tillkamppeter Looking at the current quirks file, there are 117 unique entries; here is the breakdown:
'soft-reset' applies to the old Prolific USB to parallel converter and to certain Samsung printers (and it looks like at some point we gave up trying to isolate to specific models and always do a soft reset...) If this turns out to be an issue I guess I could add a soft reset on device close, but so far I've had 0 reports of this issue and doing a soft reset typically resets the printer as well which isn't what we want...
Short of blacklisting the subset of Canon inkjet printers that won't work with PAPPL anyways, I don't see a need to support USB quirks in PAPPL. |
@michaelrsweet At the start I meant quirk support by providing PAPPL API, which would read files from specified directories and return a list of quirks defined in directories plus the quirk behavior implementation in pappl/printer-usb.c - the database itself would be in a specific printer application (it does not make sense to carry it with PAPPL). But I guess you would not like to have the quirky behavior in PAPPL USB implementation (which I understand), correct? However that complicates backward support of old printers via retrofitting printer applications - we have the proper drivers, setup and IPP system via printer applications, but some older printers won't work properly as it does with CUPS 2.x. Does PAPPL support a plug-in backends, so retrofitting printer apps could f.e. provide its own USB backend implementation and still use PAPPL, or is it like "Use PAPPL USB backend or implement the printer application without PAPPL at all"? |
@zdohnal Correct, I would prefer to not encumber PAPPL with USB quirks if we can avoid it. PAPPL does support adding custom schemes, which Till uses in the pappl-retrofit library to support/use the original CUPS backends. But there isn't a way to suppress the built-in "usb", "socket", and "file" schemes so that users of these applications are unable to specify them. Conceptually I could update the |
Thank you for looking into it!
Aha, we only detach it - hopefully nobody is using it till now.
I'm planning to package all printer application into Fedora 39 since cups-filters 2.0b and friends are in Fedora 38 already and announce testing round for printer applications during Fedora 39, so hopefully we will get useful feedback on which quirks are still needed. CentOS Stream and RHEL are another stories - this I will handle later unfortunately. |
@michaelrsweet For me this does not look correct. When I create a custom backend (scheme) without having touched (for example listed) the backends/devices before, the built-in schemes of PAPPL are not available. If I want both my own scheme and the built-in schemes I have to list the standard schemes via https://github.com/OpenPrinting/pappl-retrofit/blob/master/pappl-retrofit/pappl-retrofit.c#L4354 |
What we need is direct control about what schemes are used. If one just adds a custom scheme, the built-in scheme and the custom scheme should be active. Then there should be an API function to enable and disable schemes, so that one can easily disable unwished schemes, or even, depending on the situation enable the desired set of schemes. The possibility of overloading built-in schemes with ones own, equally-named schemes could also be interesting. Even if one does not create a custom scheme disabling built-in ones would be useful, as the class of printers where the Printer Application is designed for could be for example only USB printers. |
[Changing the scope/title of this bug] @tillkamppeter OK, so looking at the code it isn't adding the default schemes. Specific changes I'm proposing:
This should allow pappl-retrofit to replace the existing USB scheme handlers with the wrapper around the CUPS USB backend, for example. Thoughts? |
This would mean the following:
Am I right with all this? |
@tillkamppeter Yes, correct. You could also remove all schemes with I think most printer applications won't use these APIs, but clearly it would be helpful for the retrofitting applications... |
Is your feature request related to a problem? Please describe.
The CUPS 2.x USB backend provides quirk support - quirks can help in some cases when the device has a known issue which we can workaround, or it can reject the device in case its USB support is utterly broken.
Describe the solution you'd like
Provide a quirk support where files can be read from /usr/share/pappl/quirks/* and from /etc/pappl/quirks/* with higher priority, where printer application maintainers and admins can put quirk files regarding their devices.
Describe alternatives you've considered
This might be solved on printer application level as well, but a generic support in PAPPL would be great.
The text was updated successfully, but these errors were encountered: