* HID Monitor Driver Advice @ 2021-04-15 15:35 mark 2021-04-15 15:44 ` Greg KH 0 siblings, 1 reply; 5+ messages in thread From: mark @ 2021-04-15 15:35 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HID Monitor Driver Advice 2021-04-15 15:35 HID Monitor Driver Advice mark @ 2021-04-15 15:44 ` Greg KH 2021-04-15 19:27 ` Mark Bolhuis 0 siblings, 1 reply; 5+ messages in thread From: Greg KH @ 2021-04-15 15:44 UTC (permalink / raw) To: mark; +Cc: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HID Monitor Driver Advice 2021-04-15 15:44 ` Greg KH @ 2021-04-15 19:27 ` Mark Bolhuis 2021-04-16 6:50 ` Greg KH 0 siblings, 1 reply; 5+ messages in thread From: Mark Bolhuis @ 2021-04-15 19:27 UTC (permalink / raw) To: Greg KH; +Cc: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HID Monitor Driver Advice 2021-04-15 19:27 ` Mark Bolhuis @ 2021-04-16 6:50 ` Greg KH 2021-04-16 7:46 ` Mark Bolhuis 0 siblings, 1 reply; 5+ messages in thread From: Greg KH @ 2021-04-16 6:50 UTC (permalink / raw) To: Mark Bolhuis; +Cc: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HID Monitor Driver Advice 2021-04-16 6:50 ` Greg KH @ 2021-04-16 7:46 ` Mark Bolhuis 0 siblings, 0 replies; 5+ messages in thread From: Mark Bolhuis @ 2021-04-16 7:46 UTC (permalink / raw) To: Greg KH; +Cc: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-04-16 7:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-15 15:35 HID Monitor Driver Advice mark 2021-04-15 15:44 ` Greg KH 2021-04-15 19:27 ` Mark Bolhuis 2021-04-16 6:50 ` Greg KH 2021-04-16 7:46 ` Mark Bolhuis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).