On Mon, 13 May 2024 12:13:31 +0200, Kent Gibson <warthog618@xxxxxxxxx> said: > >> > /** >> > * @brief Set the bias of requested input line. >> > * @param olr The request to reconfigure. >> > * @param bias The new bias to apply to requested input line. >> > * @return 0 on success, -1 on failure. >> > */ >> > int gpiod_olr_set_bias(struct gpiod_line_request * olr, >> > enum gpiod_line_bias bias); >> >> For this to work, you'd most likely need a new struct wrapping the request >> and also storing the line config. Otherwise - how'd you keep the state of all >> the other line settings? >> > > Yeah, I realised that when I went to implement it :(. > > What I implemented was to read the line info and build the config from that. > So no impact on core. > Not the most efficient, but for this use case I wan't fussed. > I think those simplified requests should wrap the config structures, otherwise we'd have to readback the config from the kernel which would become quite complex for anything including more than one line. >> We'd keep the clear distinction between the low-level, core C library wrapping >> the kernel uAPI and the user-friendly C API. Though the user-friendly API in my >> book could be the GLib library but I understand not everyone wants to use GLib >> nor is familiar with GObject. >> > > Sorry, still haven't had a chance to look at the GLib API. > But if it involves any additional overhead or learning curve then it > wont be well received. > Yes, unfortunately GLib & GObject are quite different from most of the regular C programming. Bart