-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FreeBSD support #118
Comments
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
<#118>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3Q3ZSI3MRPUVAF5KELRM4AI7ANCNFSM4MJU4XTQ>.
|
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: There are also the following two packages
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. |
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
<#118 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3UVYTSWJBQADXWU6PLRNDFF3ANCNFSM4MJU4XTQ>.
|
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:
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. |
Thank you so much for looking into this! Interestingly I do not even have |
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). |
Here is the issue in the FreeBSD tracker: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251844
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.
Andriy stated that they used to provide this, but don't anymore. |
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!
The text was updated successfully, but these errors were encountered: