search

rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
978 stars 40 forks source link

FreeBSD support #118

Open h-2 opened 4 years ago

h-2 commented 4 years ago

Has someone worked on FreeBSD support or thought about this? Can you estimate how difficult it would be to port this application? i.e. how much of the code depends on Linux-kernel specifics and how much would be shared code (mesa, Xorg, Wayland, Nvidia-driver, ...)?

Thank you!

rockowitz commented 4 years ago

I'm not aware of anyone working on a BSD port.

I don't have much experience with BSD, but here's what comes to mind.

1) ddcutil has a configure option to build without USB support. I2C communication is sufficient.

2) The environment and usbenvironment commands do not need to be implemented.  They exist to help users figure out changes that need to make to get ddcutil to work, and to help me with remote diagnosis.  To do so, these commands use low level interfaces with abandon, and violate layering.   For example, it is the only place where ddcutil mucks around in X11 or /sys.

3) ddcutil performs I2C communication solely using the the dev-i2c userspace library.  This provides the /dev/i2c devices which are read from and written to primarily using read() and write(), and secondarily using ioctls.   ddcutil does not access video drivers directly.  I2C communication is encapsulated in the I2C layer (source directory i2c).  Higher layers refer to devices and /dev/i2cN, etc.  ddcutil also uses the udev interface, but this is just to provide more sophisticated display detection, e.g. ddcutil ignores smbus I2C devices, which improves performance.  If userspace access to I2C devices is unavailable, a driver would have to be written. This is the heart of the conversion.

4) ddcutil freely makes use of Linux-specific APIs and libc API extensions.   There should be BSD equivalents.

5) ddcutil makes extensive use of glib.  GLib is designed to be portable, so this should not be an issue.

Regards, Sanford

On 4/16/20 9:15 AM, Hannes Hauswedell wrote:

Has someone worked on FreeBSD support or thought about this? Can you estimate how difficult it would be to port this application? i.e. how much of the code depends on Linux-kernel specifics and how much would be shared code (mesa, Xorg, Wayland, Nvidia-driver, ...)?

Thank you!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/118, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3Q3ZSI3MRPUVAF5KELRM4AI7ANCNFSM4MJU4XTQ.

h-2 commented 4 years ago

Thank you for the long answer. I have tried to find out more regarding FreeBSD's state of i2c support / exposure, but I don't know yet what to look for exactly and my other sources of information have not been very helpful.

This is the FreeBSD kernel-source directory for i2c: https://github.com/freebsd/freebsd/tree/master/sys/modules/i2c Do you see anything there that goes in the right direction?

There are also the following two packages

i2c-tools-4.1                  Heterogeneous set of I2C tools
iichid-0.0.1                   Generic FreeBSD HID layer for I2C and USB devices

I have tried stupid loading of all modules and seeing if new devices pop up in dmesg or /dev/ but without luck so far.

I have no experience with device drivers, but if you think that most of what I need is in there somewhere and just needs to be rewired correctly, I could maybe start looking into that since I might have some spare time soon.

rockowitz commented 4 years ago

Take a look at package i2c-tools.  On Linux it uses libi2c, the userspace i2c shared library that provides the /dev/i2c devices.   Both packages are maintained by John Delvare, who is one of the key I2C developers.

There an Linux compatibility layer on BSD, so assuming that libi2c works on BSD (https://www.freebsd.org/doc/handbook/linuxemu-lbc-install.html), porting should be relatively straightforward.   That's the 50,000 foot view.   The devil is always in the details.

Also, have you checked that /dev/i2c devices exist on your BSD system?

On 4/17/20 5:49 PM, Hannes Hauswedell wrote:

Thank you for the long answer. I have tried to find out more regarding FreeBSD's state of i2c support / exposure, but I don't know yet what to look for exactly and my other sources of information have not been very helpful.

This is the FreeBSD kernel-source directory for i2c: https://github.com/freebsd/freebsd/tree/master/sys/modules/i2c Do you see anything there that goes in the right direction?

There are also the following two packages

|i2c-tools-4.1 Heterogeneous set of I2C tools iichid-0.0.1 Generic FreeBSD HID layer for I2C and USB devices |

I have tried stupid loading of all modules and seeing if new devices pop up in dmesg or /dev/ but without luck so far.

I have no experience with device drivers, but if you think that most of what I need is in there somewhere and just needs to be rewired correctly, I could maybe start looking into that since I might have some spare time soon.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/118#issuecomment-615479307, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UVYTSWJBQADXWU6PLRNDFF3ANCNFSM4MJU4XTQ.

rockowitz commented 3 years ago

A stripped down version of ddcutil, in branch 1.0.0-dev, builds on FreeBSD. .configure option --enable-targetbsd sets the appropriate iftests in the code.

However, no /dev/iic devices exist either for the video card or smbus. I believe I'm loading all the relevant kernel modules. Here's partial output from kldstat: 

Id Refs Address                Size Name
 1   76 0xffffffff80200000  2448d90 kernel
 2    1 0xffffffff82649000     3a38 iicsmb.ko
 3    3 0xffffffff8264d000     2f18 smbus.ko
 4    5 0xffffffff82650000     6da0 iicbus.ko
 5    1 0xffffffff82657000     4d50 iicbb.ko
 6    1 0xffffffff8265c000     3910 iic.ko
       ...
 8    1 0xffffffff82664000     2e70 smb.ko
 9    1 0xffffffff82821000     494c linprocfs.ko
10    4 0xffffffff82826000     3178 linux_common.ko
11    1 0xffffffff8282a000     1eae linsysfs.ko
       ...
13    1 0xffffffff82835000   250464 amdgpu.ko
       ...
15    5 0xffffffff82afd000    10eb0 linuxkpi.ko
        ...
19    1 0xffffffff82b32000      670 iicdev.ko
        ...
23    1 0xffffffff82b3a000    3df60 linux.ko
24    1 0xffffffff82b78000    35b20 linux64.ko

The situation is the same if a Nvidia card is installed and the nvidia.ko module is loaded.

Interestingly, if I install a Hauppauge WinTV card and load its driver, /dev/iic devices for the card do appear.

I'm sure there's something trivial that this BSD newbie is missing. I'm hoping someone familiar with FreeBSD can clue me in on what to do. @rastermann, since Enlightenment builds for FreeBSD, perhaps someone on your team who is familiar with FreeBSD can help.

h-2 commented 3 years ago

Thank you so much for looking into this!

Interestingly I do not even have iicdev.ko on my system. In any case, I will open an issue in the FreeBSD bug tracker for this and see if someone can help.

cemeyer commented 3 years ago

A looked into this a couple weeks ago. Support for I2C ioctls depends on the GPU driver.

The Nvidia GPU driver comes in two pieces: a binary blob, which is actually bit-for-bit identical with the Linux driver; and a set of platform-abstraction source code which is compiled to make the complete driver. The Linux platform-abstraction code exposes the DDC/I2C interface to userspace; the FreeBSD one does not. This is a shortcoming in the Nvidia driver, but one that we could theoretically address by porting over logic from the Linux driver.

As far as other GPU drivers (Intel, AMD), I don't know if they expose I2C ioctls to userspace or not.

There was a little bit of discussion of this topic at the November 2020 Devsummit, possibly during the 14.0 Planning session on Friday (but I'm not sure).

rockowitz commented 3 years ago

@cemeyer Thank you for the detailed note. I see that "DDC monitor control support (ddccontrol)" is listed in the "Want" section of the notes from the 14.0 Planning session. @h-2 Thanks for planning to post a bug report.

Obviously, the FreeBSD port is on hold until the driver support is there.

h-2 commented 3 years ago

Here is the issue in the FreeBSD tracker: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251844

This is a shortcoming in the Nvidia driver, but one that we could theoretically address by porting over logic from the Linux driver.

As I already mentioned over at the FreeBSD tracker, I would be very willing to test such things but likely lack the experience to contribute initial code myself.

As far as other GPU drivers (Intel, AMD), I don't know if they expose I2C ioctls to userspace or not.

Andriy stated that they used to provide this, but don't anymore.