Hi Sanford, On Wed, 3 May 2017 08:48:42 -0400, Sanford Rockowitz <rockowitz@minsoft.com> wrote: > I responded to your email by replying to the bug. Not sure if that was > the right way. On the chance you didn't see my reply I'm forwarding the > message to you directly. Thanks — unfortunately the Debian BTS doesn’t forward replies, so I didn’t see your original reply. (The emails *you* receive should be correctly setup with the appropriate Reply-To though, so replying with the defaults should work.) > I installed the ddcci driver in my SuSE environment that uses the > nouveau and i2c-dev drivers. Directory /sys/bus/ddcci is created, but > directory /sys/bus/ddcci/devices is empty. As I read the code ddcci > requires i2c-dev, which isn't present with a proprietary video driver > such as nvidia or fglrx, so there's no point trying to use it in those > environments. Yes, that’s correct. In Debian we tend to only support the free drivers though (with best-effort on the proprietary NVIDIA drivers which are packaged in non-free). The fglrx driver can’t be used any more so that’s a non-issue... I’m using the ddcci module on Intel GPUs and it works very well there. > I'd very much appreciate your help as co-maintainer and sponsor. This > is my first attempt to submit a package to debian. ddcutil has been > packaged on OBS and Launchpad for some time now, but I spent hours this > morning lost in the proverbial "maze of twisty little passages, all > alike", trying to figure out how to submit the package. I'm sure there's > a lot of cruddy details to be fixed up. Can you point me to whichever repo you consider to have the current packaging? I’ll take a look. Would you like to take care of the packaging, and have me review it, or would you like me to take a more hands-on approach and fix things up myself? (Assuming things need fixing of course.) > The ddcci driver is an interesting project. It hides the gory details > of building and sending DDC packets. But there also seems to be a lot > of missing functionality: e.g. EDID reads on slave address x50, only a > few DDC commands are supported. The ddccii driver implementation of > the capabilities inquiry returns an error if any write/read sub-exchange > fails. In my experience with marginal monitors, you need retry logic > for both the individual sub-exchanges and the entire meta exchange, what > ddcutil calls multi-part-exchanges - otherwise you just don't get lucky. All that is good to know. AFAICT the ddcci module is just a first stab currently, I’m sure the author would welcome help too ;-). The killer feature for me is that it integrates with the backlight support, so users can control their monitors’ backlights using their desktop environment’s features (e.g. the brightness slider in GNOME), including automatic features with light sensors. > Because of the early experimentation, the layer that reads and writes > I2C packets is designed to be swapped, so it should be possible to use > ddcci as an alternative strategy. However, ddcutil would still need to > use the i2c-dev interface for things the ddcci driver does not do, and > I'd prefer not to add a dependency on a driver that can't be relied on > to always be there. > > Given all these issues, I think the best relationship between ddcutil > and the ddcci driver would be to use ddcutil as a testing framework for > the driver. That sounds like an excellent plan (and I guess your follow-up email is the result, right?). Regards, Stephen
Attachment:
pgp4k3EhhmqBn.pgp
Description: OpenPGP digital signature