Why a "userspace library" and not a "kernel module" ?

[supcik]

What was the motivation for making a userspace library and not a kernel module (with device tree interface) ? Did you evaluate this option ? And if yes, what are the drawbacks of having a kernel module instead of a userspace library ?

For me, the main advantage of having a kernel module would be to allow non-root application to use ws281x hardware and also to simplify the access from other languages (such as ruby, javascript or even go).

Thank you in advance for your reply.

[penfold42]

If to gets upstreamed, and your distribution includes it, great (and it would be!)

If not, 90+% of people wouldn’t be able to use it.

If you use SPI instead of PWM, you shouldn’t need root.

[jgarff]

I've done lots of kernel modules over the years, mostly for custom logic, but I mainly did a userspace driver here for a couple reasons: 1 - It was easier, I'm lazy, and this started as a simple weekend project. 2 - I woudn't have to fight to get it into the mainline tree. 3 - I've been meaning to make it a kernel module but for 1 and 2. I still wouldn't mind redoing it as a kernel module though. I has definite advantages. We wouldn't need to use the video memory hack for getting around the cache in the kernel. We could use interrupts and block on a signal/select for completion in userspace, no more polling. It would probably also help in choosing a free DMA channel. And as you mentioned though we wouldn't need root, but we'd still need a userspace library to link against. Jeremy

…

On Sun, Dec 24, 2017 at 4:26 AM penfold42 ***@***.***> wrote: If to gets upstreamed, and your distribution includes it, great (and it would be!) If not, 90+% of people wouldn’t be able to use it. If you use SPI instead of PWM, you shouldn’t need root. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIPem5rMnPvTP34JGKAzrF1TOEQsaVe3ks5tDjS6gaJpZM4RL44J> .

[supcik]

Thank you for your quick and detailed reply. I was rather thinking about a DKMS module and not necessarily having it in the mainline tree.

Let me know if you plan redoing it as a kernel module and if you want some help.

Thank you again and feel free to close this issue if you want.

Best regards,

-- Jacques.

[supcik]

I am still looking for a clean way (for me) to make your code easily usable from non-root applications and without requiring your C library to be linked to the application. The motivation here is to allow "pure" python or "pure" go application to use your code.

I understand the limits and the shortcomings of a kernel module, so I will probably start some experiments with a bus system; perhaps D-Bus, but more likely grpc (https://grpc.io/). The daemon will still be written in C++ and will run as root, but the applications will communicate using a higher level bus system.

Feel free to discuss, encourage, or criticize this idea.

[penfold42]

Can you use SPI instead of PWM ?

You only need to fix permissions on the /dev entry to allow non root to spidev0.0

[PandorasFox]

If you use SPI instead of PWM, you shouldn’t need root.

With this being merged, shouldn't it be possible to use PWM without root, too? It seems that rootless PWM should work in 4.9.67 and newer.

[penfold42]

Maybe - where is the underlying functionality documented ?

If it’s simplistic “go set pwn to 0x42” then no - it’s of no use.

This code uses DMA to pump data to the pwm function

[PandorasFox]

Yeah, I was just about to edit my comment to say that I see that right now you're using DMA.

I'll go double-check the docs tomorrow morning, but I believe that it's exposed through sysfs, so you should be able to just write to /sys/class/pwm. It should be able to function somewhat similarly to how SPI does currently, I think.

I'll be poking at writing this myself for one of my projects, so I'll see what I can do.

[penfold42]

This ? https://github.com/torvalds/linux/blob/master/Documentation/pwm.txt
It’s simplistic

What would be more interesting is abusing the Alsa sound subsystem to send the data - it’s just a long sample at the end of the day...

[PandorasFox]

Yeah, the rootless pwm interface is too simplistic for what I want, unfortunately (unless I can figure out some way to rapidly change the duty cycles to write bits out, but that's unlikely).

I guess SPI is more in-line with what I need at the end of the day, anyways.

[PandorasFox]

If you use SPI instead of PWM, you shouldn’t need root.

Coming back to that: I've only gotten it to work without root if I change this line to /dev/gpiomem instead of /dev/mem.

PWM definitely still needs to read from /dev/mem, though.

Should I just add a third arg (int or const char*, shouldn't really matter?) to let calls specify what they're trying to map to, and then make a pull for that? It seems that it's currently not possible to do SPI without root, without that change.

[penfold42]

I didn’t do the SPI implementation here but I did suggest it based on work I did for Hyperion.

There should be no need to hit the hardware at all with SPI - just access to /dev/spidev0.0.

Maybe there’s a code path that’s needlessly still being hit as part of the pwm setup

[PandorasFox]

Yeah, there's this call here. It definitely seems like it'll cross that no matter what.

I'll double check if that call is actually needed at all (I suspect it is, but also since it's just a GPIO device, it should only ever need gpiomem)

(Apologies to everyone else for just kinda hijacking this issue)

[ffleandro]

I have successfully used this library through SPI without root access, simply by changing the access of /dev/mem to /dev/gpiomem.

[Gadgetoid]

Making this library function as a kernel module could help get ws2812 support into the GPIO Zero project- which has had at least one user request support for ws2812 pixels. That might give you some powerful allies in the struggle to push your code upstream at least as far as the Raspbian fork.

I know a ws2812 kernel module exists, since it was authored by Gordon Hollingworth to run the LEDs on the Five Ninjas Slice. It is nowhere even close to as comprehensive as this project, however, and it remains lost in obscurity.