You can easily get round the "multiple task" issue by running a daemon or similar over pinctrl to handle the multi access aspect.Yes, that does show what a nightmare GPIO handling has been. I see that as being because Linux was initially intended to be a 'software platform' rather than for an 'embedded controller platform'.Maybe also see the excellent GPIO history document https://pip.raspberrypi.com/categories/ ... ctices.pdf
For traditional multi-user Linux systems there simply wasn't GPIO any users would have had access to, it was therefore never a consideration.
Even though it has been accepted that GPIO access is needed by some Linux users, things are not great. It seems to me the move to 'libgpiod' has been driven by those who still see Linux as a software platform and have little idea of what embedded users actually want or need. Things like being able to read the same input in two or more tasks, having multiple tasks control the same output, are things they won't accept or allow even though entirely valid in some circumstances. The very fact we need to have 'pinctrl' is a clear indication that what 'libgpiod' itself delivers is not enough.
And along the way it's been an utter mess because there has been no single library or utility to do it on a Pi, no single recommended practice, so people have produced their own solutions and users picked whatever they fancied, with mixed outcomes.
I was hoping, given GPIO access is such an import part of a Pi SBC, Raspberry Pi would have been a driving force towards providing better GPIO interaction under Linux, might have taken the reins to ensure it deliver what was needed, but it seems not.
Even now, AIUI, Raspberry Pi ship a pre-installed 'RPi.GPIO' which doesn't work fully on some platforms.
And replacing 'raspi-gpio' with a new 'pinctrl', rather than updating 'raspi-gpio', only adds to the mess.
Statistics: Posted by jamesh — Fri Jan 16, 2026 4:35 pm