Windows 11 does not like integers in media-source-supported field

[ValdikSS]

Describe the bug

Windows 11 version 22H2 build 22621.2861 silently fails to add Mopria auto-discovered printer if it reports a number (a digit as a string) in media-source-supported field.
If you try to add such a printer using modern control panel, it will show endless "connecting…" message, and if you add it using old control panel, it would be added "successfully", but under "unrecognized" device type, and you won't be able to print on it.

Changing media-source-supported by editing .ppd file to any real text string, such as auto, fixes the issue.

I briefly read IPP specifications and it doesn't seem that it contradicts anything in the spec, and CUPS doesn't seem to blame. But is it something worth auto-patching in CUPS?
Reported to MS using Feedback Hub.

Failing ppd snippet (from Canon LBP-1120):

*OpenUI *InputSlot/Paper Source: PickOne
*DefaultInputSlot: 0
*InputSlot 0/Auto : ""
*CloseUI: *InputSlot

$ ipptool -tv 'ipp://uowprint.local:631/printers/LBP1120' get-printer-attributes.test | grep 'media-source-supported '
        media-source-supported (keyword) = 0

To Reproduce
Steps to reproduce the behavior:

1. Add shared printer with PPD file contains the snippet above
2. In Windows 11, go to "Printers & scanners" → "Add device"
3. Wait until the shared printer appears, press "Add device"
4. The printer would silently fail to install

Alternative steps, with more visuals:

1. Add shared printer with PPD file contains the snippet above
2. In Windows 11, go to "Devices and Printers" in the old control panel (icon in explorer in the left sidebar, right under "video") → "Add a printer"
3. Wait until the shared printer appears, press "Next"
4. The printer will install, but will appear only as "unrecognized" device type

System Information:

• CUPS version: tested on 2.4.2 as a server

Working PPD snippet:

*OpenUI *InputSlot/Paper Source: PickOne
*DefaultInputSlot: auto
*InputSlot auto/Auto : ""
*CloseUI: *InputSlot

$ ipptool -tv 'ipp://uowprint.local:631/printers/LBP1120' get-printer-attributes.test | grep 'media-source-supported '
        media-source-supported (keyword) = auto

[michaelrsweet]

Technically IPP keywords are supposed to start with a letter, so Microsoft isn't wrong to not allow numeric keywords like this (although I would like to see a real error message, obviously...)

We should be able to update the PPD cache/mapping code to avoid strictly numeric source names, but also if there is just a single InputSlot then we can just list "auto" or "main" for the mapping as well.

[ValdikSS]

@michaelrsweet, FYI, the same issue happens when 1284DeviceID is missing MFG or MDL, which is the case for example for some foo2zjs models: https://salsa.debian.org/printing-team/foo2zjs/-/blob/debian/main/PPD/Xerox-Phaser_3010.ppd?ref_type=heads#L64

Is it worth patching in cups in your opinion, or should I just fix all the PPDs there?

https://learn.microsoft.com/en-us/windows-hardware/drivers/print/deviceinfo#ieee1284deviceid

The minimum necessary keys (case-sensitive) are MANUFACTURER and MODEL. (These keys might be abbreviated as MFG and MDL respectively.)

[michaelrsweet]

@ValdikSS Better to fix the PPDs since there isn't a reliable way for CUPS to "fix" the 1284 device ID in the PPD file.

[ValdikSS]

@michaelrsweet it seems that foomatic-ppdfile from foomatic-db-engine does not use manufacturer and model fields for 1284DeviceID, requiring manufacturer and model to be supplied in <autodetect> profile.

For now I've patched the .xml files in foo2zjs.

Worth fixing foomatic-db as well: OpenPrinting/foomatic-db-engine#10