On Thu, Apr 15, 2021 at 08:27:58PM +0100, Mark Bolhuis wrote: > On 15/04/2021 16:44, Greg KH wrote: > > Why do you need a kernel driver at all? Why not just use the userspace > > hid access and control stuff that way from an application? > > > If you write your own driver, you can do that from within the driver I > > think. But again, what's wrong with userspace? > > > > thanks, > > > > greg k-h > > A couple reasons. These might be misplaced since I'm very new to kernel > programming. > > I would like to create very simple user space scripts and programs on top of > it. I'd like to change settings with nothing more than an `echo 200 > > brightness`. Something has to keep track of an internal state, which I'd > rather not happen in userspace apps, so I decided on a driver. That's nice, but creating random user/kernel apis for a single device like this is generally not a good idea. Also we do not like to have kernel drivers for things that can be done in userspace. Single-use drivers like this that can be done in userspace, should be done in userspace. We have lots of ways to write userspace USB drivers, look at the uhid stuff, and also there is libusb to do this on all operating systems. > I'd like to eventually use linux/backlight.h to control brightness which, > correct me if I'm wrong, has to be used from a kernel driver. Or is this an > unsuitable use case? If you want to tie it into the backlight api, then yes, a kernel driver is the way to go, as that is what drivers are for (to provide a unified user/kernel api). But if you want to do other things like it sounds like you do beyond just backlight interfaces, then you might want to just do it all in userspace. good luck! greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies