HID Monitor Driver Advice

Mark Bolhuis mark at bolhuis.dev
Fri Apr 16 03:46:04 EDT 2021

On 16/04/2021 07:50, Greg KH wrote:
> 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

Ok, I'll have another look at using uhid.
Thank you for your help.


More information about the Kernelnewbies mailing list