On Tue, May 7, 2024 at 4:21 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > Hi Bart, > > I realise you want to keep libgpiod minimal, but in my latest survey of the > problems that new or potential users are finding with libgpiod the most > common one was that it is way too complicated to do simple things. > They just want to request an input or output line and play with it. > They think that should be an easy thing to do, and will completely write > off libgpiod because it is not - the learning curve is too steep. > And they have a point. > > I've raised this before, but I think libgpiod is in need of a small (and I > emphasize small) set of helper functions to simplify basic use cases, > like just requesting a single input or output line. Maybe functions to > control setting bias, edge detection and debounce on inputs (using > reconfigure after the initial request). > The functions would be separated from the existing functions by naming, > e.g. gpiod_helper_XXX, or some such, so there would be no confusion with > the existing. > > Any chance your position has changed since last I asked? > Ugh... I really don't want the core libgpiod to grow... This sounds like the old ctxless stuff that was awkward and I removed it in v2. Do you think that users actually use it (core C libgpiod)? I would think they stick to python and C++? Would providing the GLib bindings help in this case? We could extend that no problem. Or maybe a separate helper library linked against libgpiod but also existing kind of adjacent to it? Bart