HID Monitor Driver Advice

HID Monitor Driver Advice

[mark]

Hi all

My name is Mark and I'm currently writing a device driver for Eizo EV 
FlexScan monitors, so that I can control them over usb. This driver is 
built by reverse engineering the hid reports sent by the propriety and 
windows only software.
It can be found here: https://github.com/markbolhuis/openeizo

I have some questions about this that hopefully somebody can answer.

1) What would be the recommended way to interface this with userspace? 
My plan is to expose a device file for each unique setting that the 
monitor has such as brightness control, input selection and so on... 
However I'm not sure this is a suitable way of doing this since the 
monitors have many options that are very similar. For example contiguous 
numerical values only differ by their usage and value min and max, 
meaning that if I have a file per setting there will be a lot of 
repetition. There are already 40+ unique attributes/settings that may 
need a file.

2) To properly initialize the driver I will have to fetch a second 
report descriptor from the monitor. This isn't a standard hid report 
descriptor. It seems that Eizo are simply using the format instead of 
inventing their own. Is there a way for the hid subsystem to parse 
arbitrary report descriptors and expose them as a structure for generic 
use? I couldn't find much that would help with this. hid_parse_report @ 
inlcude/linux/hid.h:895 seems to be the closest to what I need but it's 
tied to a device.

3) I contacted Eizo and politely asked if they could provide an hid 
specification for the vendor defined usages however they weren't able to 
help. This forced me to reverse engineer. Is there anything that I 
should be aware of if I want to submit code that based on reverse 
engineering? I didn't reverse engineer the windows driver itself, just 
sniffed the packets with usbmon.

4) How would I find people who have compatible monitors to test it out 
and/or help reverse engineer? I only have one monitor so I'm writing 
against that, with no guarantee that it will work for others.

Thank you for reading
Mark Bolhuis

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: HID Monitor Driver Advice

[Greg KH]

On Thu, Apr 15, 2021 at 04:35:45PM +0100, mark@bolhuis.dev wrote:
> Hi all
> 
> My name is Mark and I'm currently writing a device driver for Eizo EV
> FlexScan monitors, so that I can control them over usb. This driver is built
> by reverse engineering the hid reports sent by the propriety and windows
> only software.
> It can be found here: https://github.com/markbolhuis/openeizo
> 
> I have some questions about this that hopefully somebody can answer.
> 
> 1) What would be the recommended way to interface this with userspace? My
> plan is to expose a device file for each unique setting that the monitor has
> such as brightness control, input selection and so on... However I'm not
> sure this is a suitable way of doing this since the monitors have many
> options that are very similar. For example contiguous numerical values only
> differ by their usage and value min and max, meaning that if I have a file
> per setting there will be a lot of repetition. There are already 40+ unique
> attributes/settings that may need a file.

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?

> 2) To properly initialize the driver I will have to fetch a second report
> descriptor from the monitor. This isn't a standard hid report descriptor. It
> seems that Eizo are simply using the format instead of inventing their own.
> Is there a way for the hid subsystem to parse arbitrary report descriptors
> and expose them as a structure for generic use? I couldn't find much that
> would help with this. hid_parse_report @ inlcude/linux/hid.h:895 seems to be
> the closest to what I need but it's tied to a device.

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: HID Monitor Driver Advice

[Mark Bolhuis]

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.

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?

I assume you are referring to uhid? I've got no issue using it but my 
initial impressions led me to think it wouldn't have been as elegant. 
Again I could be wrong. I'll do some more research on it.

Thanks
Mark





_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: HID Monitor Driver Advice

[Greg KH]

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@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: HID Monitor Driver Advice

[Mark Bolhuis]

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.

Mark

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies