Skip to content
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

RFC: Provide libwacom's information as static set of stable-api json files? #714

Open
whot opened this issue Jun 7, 2024 · 0 comments
Open
Labels
enhancement Feature requests and other improvements

Comments

@whot
Copy link
Member

whot commented Jun 7, 2024

This is an RFC around an idea we had around a year or so ago but so far nothing has come out of it.

libwacom is a static database and the only dynamic part of it is libwacom_new_from_path() which looks up a device. Everything else is const.

libwacom is a C library and while this makes it easy to wrap in language bindings it also introduces a run-time dependency on a library (that uses glib) just to look up some static information.

Arguably we could ship what libwacom does as a single (or set of) json files1. Something like

{
  "version": "1.0.0",
  "tablets": [
     {
        "name": "blah blah",
        "model": "foo",
        "matches": [{ "bus": "usb", "vid": "056A", "pid": "123" }],
        ...
     }
  ],
  "styli": [
     ...
  ]
}

Notably, the content of the json is not the content of the .tablet files but matches the output of the C API. Our .tablet files remain an implementation detail.

The JSON format would have to be stable, same as the C API, the semver version field can help denote which fields one can expect, and clients are required to ignore unknown fields. Either way this would make using libwacom's data files from other languages easier than writing FFI bindings.

The main thing we'd lose is the ability to dynamically add files in /etc/libwacom but that can be worked around by having the json-generating tool pick those up and dump the combined output into /etc/libwacom/libwacom-database.json.

I'm not 100% sure there's a use-case for this - our (few) users already have the code for handling libwacom and there isn't a huge queue of new users. It's unlikely existing users would switch and we'd have to maintain the C library anyway.

Footnotes

  1. or some other easy-to-process file format

@whot whot added the enhancement Feature requests and other improvements label Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests and other improvements
Projects
None yet
Development

No branches or pull requests

1 participant