Skip to content

Split into three directories for stable/testing/userhacks

Filing this so it doesn't get lost, this is a result of a meeting with @bentiss.

udev-hid-bpf serves two functions: allow users to fix their devices where its broken (e.g. !35 (merged)) and allow users to reconfigure their devices to do something specific to their use-case (e.g. change a button to some other button). Let's call those "quirks" and "userhacks".

Userhacks never go upstream into the kernel and there is a smaller chance that one hack will be useful to another user without modifications. Quirks OTOH should go upstream to make it easier for everyone to use them - once they're upstream they technically no longer need to be in udev-hid-bpf (but it doesn't hurt to have them here).

We talked about this yesterday and what we came up with was to split the structure into three directories (names may change):

  • testing/: quirks currently in development but not yet merged in the upstream kernel
  • stable/: once a testing quirk has been accepted upstream1, it moves here
  • userhacks/: for any user-specific hack, regardless of development status

This will need cargo options to be able to {un}select the trees to install.

The eventual goal is: a distribution-packaged udev-hid-bpf will ship stable/, a local install will install testing/ (because we assume that stable/ is already provided by the distribution). userhacks/ installed on-demand by the user.

A user who needs to develop a new quirk will start in testing/ and once the quirk is good enough (i.e. no bugs found in production use for a short while) it can be submitted upstream and thus start the waitlist for stable/.

Userhacks are and remain just what they are, a grab-bag of miscellaneous BPF scripts that a user would have to purposely install.

  1. which exact kernel tree is TBD but for now we're thinking for-next or something, i.e. any upstream tree that has a likely chance of going into the next kernel release ↩