Device Capability Database¶

A selected collection of machine-readable device descriptions lets software use shared capability names to adapt commands and output to different device types.

Version: v1 · 2026-10-17 · History
Domain-specific #: 14119
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Operating Systems, Device Interoperability → Computer Science & Software Engineering
Aliases: Device capability description database

Core Idea¶

A device capability database is a machine-readable collection of descriptions for device types. Software receives a selector for a terminal or configured printer, reads the corresponding description through a shared vocabulary of capability names, and adapts its commands or output from the stored values. The scheme separates device-specific facts from the main application logic. The ncurses manual calls terminfo a terminal capability database.^[1] CUPS describes PostScript Printer Description (PPD) files as per-printer capability records.^[2] These terminal and legacy printer forms instantiate the same general scheme.

The description need not reside in one central table. Terminfo uses a database of terminal descriptions.^[1] A CUPS printer queue can select a per-printer PPD file.^[3] Both supply keyed, machine-readable device facts to a consuming program. A terminal type or printer model is supplied by the surrounding configuration; the description store does not automatically identify connected hardware.^[4]^[3]

This decoupling has a limit. A record can express only capabilities understood by its format and client. CUPS documentation explicitly separates PPD-defined commands from advanced features that need filters or supporting files.^[5] Adding a description can extend an existing client when the new device fits that contract; it is not a promise that every device works by adding data alone.

Structural Signature¶

Device-type selector. A terminal name or configured printer queue directs the client to the relevant description. Terminfo applications can use TERM or an explicit -T terminal type; CUPS setup can specify a model or PPD file.^[4]^[3] Supplying the wrong selector applies the wrong device facts.
Shared capability vocabulary. Common names let one client ask corresponding questions across devices. Terminfo distinguishes Boolean, numeric and string capabilities, including cursor-address control strings; PPDs name printer options and commands.^[1]^[2] A feature outside those names cannot be invoked through the existing contract without an extension. A known name absent from a selected record is a different case: the client can receive an explicit missing value and choose a fallback or report lack of support.^[6]^[7]
Device description collection. Stored entries or selected files hold per-type values and commands. Terminfo is a database of terminal descriptions; CUPS PPD files describe printer features and are selected for queues.^[1]^[2]^[3] This external description is what distinguishes the artifact from a client made solely of device-specific branches.
Lookup and interpretation client. A library or print system reads the chosen record and interprets its fields. tput retrieves terminfo capabilities; CUPS scheduler and filters use PPD-defined options in preparing printer output.^[4]^[5] A passive file with no consuming software does not itself adapt a program. For known names missing from a record, tiget* has absent/canceled return values and CUPS ppdFindOption can return NULL; those are lookup outcomes rather than new device capabilities.^[6]^[7]
Adapted device operation. The client uses retrieved values to issue a terminal control sequence or produce printer-specific commands/output. tput can emit terminal operations, and CUPS can place PPD-defined commands in the print path.^[4]^[5] If the program ignores the description, the database has no operative effect.

The selector, vocabulary, description and consuming client are central. The adapted operation is the result. Neither a universal hardware-detection mechanism nor universal data-only extensibility is part of the identity.

What It Is Not¶

Not automatic device detection. A terminal type is supplied through TERM or tput -T; a CUPS printer queue can be configured with a selected PPD. The description is consulted after selection.^[4]^[3]
Not a device driver by itself. The record describes capabilities, while program code still queries it and performs or generates the operation. CUPS also allows optional filters for device-specific transformations the PPD cannot express.^[5]
Not one required storage layout. A terminfo database and a set of selected per-printer PPD files fill the same description role without sharing one physical table format.^[1]^[2]
Not a guarantee that every requested name is present. ncurses reports an absent or canceled Boolean, numeric or string capability through the respective tiget* return value; the legacy CUPS ppdFindOption lookup returns NULL if a requested option is missing.^[6]^[7] This is missing-key handling, distinct from a feature the vocabulary cannot express.
Not an unlimited plug-in promise. New commands or device behavior may exceed the existing vocabulary, interpretation code or filter pipeline. The terminfo manual discusses preparing descriptions for unusual terminals and notes possible deficiencies; CUPS distinguishes PPD commands from advanced filter work.^[1]^[5]
Not a current recommendation to deploy PPD drivers. OpenPrinting says CUPS printer-driver support was deprecated beginning with CUPS 2.3 and explains driverless IPP and Printer Applications as alternatives. PPD remains a valid documented example of the architecture.^[8]

Scope of Application¶

This abstraction belongs to software systems that must operate more than one device type through a stable client interface. In text terminals, terminfo stores type names and capabilities so curses applications and commands such as tput can request functions without embedding every terminal’s escape string.^[1]^[4] In legacy print systems, PPDs describe printer features and commands while CUPS selects the relevant description and converts generic print data for the configured device.^[2]^[5]^[3]

The common scheme requires a stored description selected for a known device type. Hard-coded branches can also adapt output, but they do not instantiate the external-description artifact. A custom CUPS filter may contain device-specific code and may also coexist with a PPD; the filter by itself is not the description collection.^[5] The identity does not extend automatically to every mechanism for device discovery or live capability negotiation.

Clarity¶

The term “device independent” can obscure where dependence went. Terminfo gives the terminal a name, stores control details under common capability codes, and lets applications ask for the selected values.^[1]^[4] The application still depends on the available vocabulary and on an accurate terminal-type selector. Likewise, a PPD gives CUPS printer-specific options and commands, but a selected PPD can be insufficient for features needing additional filters.^[2]^[5]

The useful question is therefore concrete: Which facts live in the description, which are encoded in the client or filter, and who selects the record? Answering it prevents a database entry from being credited with hardware detection or behavior implemented elsewhere.

Manages Complexity¶

A shared program can address many devices through common names, shifting variant details into separately maintained descriptions. Terminfo entries put different Boolean, numeric and string values under one capability vocabulary.^[1] PPDs similarly collect per-printer options and commands that CUPS can apply through the print pipeline.^[2]^[5] The client can remain stable when a new device’s needed behavior is fully expressible with the existing names and interpretation machinery.

That compression is conditional. A new physical capability may require a new code, parameter convention or filter, and an inaccurate record can make a shared client issue the wrong command. OpenPrinting notes that PPDs cannot express the full range of modern printer capabilities or dynamic state, one reason that architecture was deprecated.^[8] The database reduces repeated device branches; it does not eliminate the need to maintain the vocabulary and its executors.

Abstract Reasoning¶

Terminfo documents prepared terminal descriptions and named capability strings.^[1] CUPS documents printer features that may require filters beyond PPD-defined commands.^[5] To assess an instance, trace five steps: supplied device type → selected description → named capability → client interpretation → actual command or adapted output. If a proposed extension changes only the description, check whether the existing client already understands the name, value and operation. Otherwise the change crosses from data maintenance into software change.

Terminfo selection uses TERM or -T,^[4] and CUPS queue setup selects a printer model or PPD.^[3] A record may faithfully describe one device but be applied to another when the selector is wrong. Description accuracy and selector accuracy are separate obligations.

Knowledge Transfer¶

Terminfo documents terminal names and capability fields,^[1] while CUPS PPDs document printer features and options.^[2] The computing pattern transfers from terminal control to printer output: each has a supplied device selector, shared vocabulary, selected external description and client that adapts behavior from retrieved values. The field names and operations do not transfer unchanged; cursor_address and printer media or option commands belong to different device domains. What transfers is the device-description contract, not a universal command set.

At a more general level, this device description collection is a Lookup Table: it stores addressable associations for supplied device and capability keys, then a client interprets the returned value. Indirection describes the mediating layer from another angle. A generic configuration file or table does not thereby supply a device capability vocabulary, selected description and adapted operation.

Examples¶

Terminfo for terminal control. The ncurses manual calls terminfo a terminal capability database and lists terminal names, Boolean and numeric values, and string control capabilities such as cursor addressing.^[1] tput uses that database to expose terminal-specific capabilities to shell scripts, selecting a terminal type through TERM or -T.^[4] Mapped back: TERM/-T fills the device-type selector; named terminfo codes fill the shared capability vocabulary; compiled terminal records form the device description collection; tput or curses is the lookup and interpretation client; its returned or emitted terminal-specific string is the adapted device operation. The record does not discover which physical terminal is attached.

PPD descriptions in legacy CUPS printing. CUPS documentation describes PPD files as per-printer capability records with options and commands. The print system combines a selected PPD with its scheduler and, when needed, filters to convert generic jobs into printer-specific output.^[2]^[5] CUPS queue configuration accepts a model or PPD file selection.^[3] Mapped back: the configured queue and chosen PPD fill the device-type selector; PPD option keywords fill the shared capability vocabulary; a set of per-printer PPD files is the device description collection; CUPS scheduler and filters are the lookup and interpretation client; PPD-defined commands and converted print data are the adapted device operation. PPD drivers are a documented legacy architecture, and a PPD alone may not implement advanced printer behavior.^[8]^[5]

Structural Tensions¶

Stable vocabulary versus device variation. Shared capability names allow one program to address many devices without embedding every control sequence, but new hardware can expose a feature the existing names or executors cannot express. Terminfo’s manual allows entries to be prepared for new terminal types while warning that unusual terminals can expose description or program deficiencies.^[1] CUPS distinguishes PPD-defined commands from advanced work that requires filters, and OpenPrinting says PPDs cannot express the full range of modern printer capabilities.^[5]^[8] Keeping the vocabulary fixed preserves client reuse but can leave features unsupported; extending it or adding code increases the maintenance surface. Diagnostic: Can this device’s needed operation be represented and executed with the existing names and client, or is new interpretation code required?

Structural–Framed Character¶

The ncurses terminfo manual documents a terminal-description database,^[1] and CUPS documents selected PPD descriptions for printers.^[2] Recognizing the same selector → description → named capability → interpreted operation relation in those unlike systems places the entry toward the structural end of the structural–framed spectrum within computing. Evaluative weight enters when maintainers choose which capabilities deserve common names or when to retire an older scheme; it does not define the relation. Human practice supplies the vocabulary and maintains the records, while lookup and resulting behavior are testable once those conventions are set.

The entry arose in concrete software institutions: ncurses maintains terminal descriptions and CUPS specifies PPD-based print drivers.^[1]^[5] Those institutions explain the formats; TERM, PPD keywords and CUPS queue settings do not travel as universal vocabulary. Moving from terminals to printers is recognition of the same operational relation with different device facts, whereas calling an unrelated configuration table a device capability database would merely import the language unless it also controls device output. Its character: a computing-bound structural artifact whose record and interface conventions frame its operation without reducing it to one implementation.

Structural Core vs. Domain Accent¶

The core is select a prepared description by key, retrieve named values, and use those values to choose behavior. That skeletal relation is the prepared-keyed-retrieval structure of its Lookup Table parent; Indirection highlights the intervening layer. The domain accent is stronger: the keys identify device types; the values describe supported device operations and parameters; and a client translates them into device-specific output. Without that device-control contract, a general table of values is not this artifact.

The named abstraction remains domain-specific because its capabilities and failure modes require computing devices, control vocabularies and consuming software. A non-computing analogy to “capabilities” would need evidence of the same selector, external description, named operation and executable adaptation before it could count as a literal transfer. The test for a wider structural abstraction would be a documented case outside device-control software that preserves selection, an external named-capability description and operative adaptation rather than borrowing the words. The present terminal and printer cases establish breadth within computing, not that wider reach.

This entry is a kind of Lookup Table.

Indirection is a relevant Prime: a client uses a stable name or interface to obtain device-dependent behavior through another layer. The device capability database supplies one concrete software realization of that move. System Configuration is also related because supplied type and option settings determine operation; configuration alone need not include a collection of device descriptions. Indirection concerns the mediating layer itself; System Configuration concerns chosen settings, which can exist without a collection of device descriptions.

Lookup Table is the broader domain-specific genus: every device capability database here has prepared addressable associations for device and capability keys. It adds a device-control vocabulary and a client that acts on the retrieved result. Lookup tables of numerical samples or Boolean truth values remain in the parent without representing devices. Software Interface concerns how components communicate; the description is the data a client interprets through an interface. Neither every driver nor every interface is this database.

Relationships to Other Abstractions¶

Current abstraction Device Capability Database Domain-specific

Parents (1) — more general patterns this builds on

Device Capability Database is a kind of Lookup Table Domain-specific

A Device Capability Database is a Lookup Table whose stored keyed associations describe device capabilities and commands that a client uses to adapt output.

Hierarchy path (1) — routes to 1 parentless root

Device Capability Database → Lookup Table

Neighborhood in Abstraction Space¶

Device Capability Database sits in a sparse region of the domain-specific corpus (100^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2721 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With¶

The original Terminfo member: terminfo is one terminal implementation. The general identity also covers a selected collection of printer descriptions with different capabilities and output paths.^[1]^[2]
A device driver: a driver or filter may contain executable device behavior. A description record can guide such code but does not itself execute or automatically identify hardware.^[5]
A hardware discovery mechanism: TERM, -T, or printer-queue configuration provides the selector in these examples; none of the cited description stores alone discovers the physical device.^[4]^[3]
A code-only adapter: hard-coded branches can switch among devices, but if no selected external description supplies the device-dependent facts, the database-mediated artifact is absent.
A universal device feature schema: terminfo and PPDs use different vocabularies, and CUPS PPD expressivity has documented limits.^[1]^[8]

References¶

[1] Zeyd M. Ben-Halim, Eric S. Raymond, and Thomas E. Dickey, “terminfo(5) terminal capability database,” ncurses 6.6 manual, patch 20260919, https://invisible-island.net/ncurses/man/terminfo.5.html (original implementer reference, full HTML inspected; DESCRIPTION, Entry and Capabilities Syntax, Standard Capabilities, and Preparing Descriptions). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q

[2] OpenPrinting/CUPS, “CUPS PPD Extensions,” https://www.cups.org/doc/spec-ppd.html (official format specification, full HTML inspected; introduction and option-command examples). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k

[3] OpenPrinting/CUPS, “lpadmin(8),” https://www.cups.org/doc/man-lpadmin.html (official command reference, full HTML inspected; -m model and -P ppd-file printer queue selection options). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i

[4] ncurses project, “tput(1) initialize a terminal, exercise its capabilities, or query terminfo database,” ncurses 6.6 manual, https://www.invisible-island.net/ncurses/man/tput.1.html (original implementer reference, full HTML inspected; DESCRIPTION, -T option, TERM environment, and EXAMPLES). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j

[5] OpenPrinting/CUPS, “Developing PostScript Printer Drivers,” https://www.cups.org/doc/postscript-driver.html (official implementer guide, full HTML inspected; Printer Driver Basics and Creating New PPD Files). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o

[6] ncurses project, “curs_terminfo(3x) curses interfaces to terminfo database,” ncurses 6.6 manual, https://invisible-island.net/ncurses/man/curs_terminfo.3x.html (original implementer reference, full HTML inspected; Terminal Capability Functions gives type-error versus absent/canceled return values for tigetflag, tigetnum, and tigetstr). registry ↩a ↩b ↩c

[7] OpenPrinting/CUPS, “PPD API (Deprecated),” https://www.cups.org/doc/api-ppd.html (official legacy API reference, full HTML inspected; ppdFindOption returns a pointer or NULL when an option is not found). registry ↩a ↩b ↩c

[8] OpenPrinting, “Printer Applications and Printer Drivers,” https://openprinting.github.io/cups/drivers.html (original project documentation, full HTML inspected; deprecation statement, PPD expressivity limits, and replacement architecture discussion). registry ↩a ↩b ↩c ↩d ↩e