As a general rule, it usually only makes sense to use system-files for files in /etc because that is one of the only directories that is shared between the snap’s mount namespace and the hosts (there are a few others of course but they are much rarer in practice I think). Other directories will come from the base snap and will be read-only even if you use system-files to try to give your snap write access.
I think layouts is probably the right thing to do for this app + directory combination.
Layouts can only help within a snap’s environment. They cannot be used to expose elements within a snap to the host environment.
What happening is that when a camera is connected via usb, the udev looks at /usr/share/uvcdynctl/data/199e on the host filesystem for extra camera controls, and not at $SNAP/usr/share/uvcdynctrl/data/199e
If I could make sure that the files in $SNAP…199e get placed in the HOST…199e the cameras would load up perfectly.
Which udev is that ? the udev on an Arch or manajro system, the one on a fedora or Opensuse install ?
Even if you inject the file there, how would the hosts udev know where to look ? Loading files, creating symlinks etc. is usually done by a udev rule in /lib/udev/rules.d.
If the upstream udev does not ship such a rule dumping your file there will have no effect …
Do not forget that snaps are universally installable on any linux system that supports snapd …
Typically a udev rule just calls some userspace app or script to initialize a device … i’d try to find out what the particular rule is that processes files from your 199e dir and simply mimic that behaviour from the snap without touching the host system or injecting unmanaged files on peoples machines …
With the following, on boot the extensions get loaded and all is good. Thanks for everyone help, it definitely pointed me in the right direction and taught me a whole pile on advanced snapcrafting