LG ultrafine capabilities error

I have two models of the LG ultrafine monitor

model 1: lg ultrafine 4k model 22MD4KA using usbc displayport-alt mode model 2: lg ultrafine 5k model 27MD5KL using usbc/thunderbolt3

on the lg5k 27MD5KL everything seems to be detected and working fine

however, ddcutil is having critical errors on the lg4k 22MD4KA, the error i'm having is:

Capabilities for display on bus /dev/i2c-10 Extended delay as recovery from DDC Null Response... (app_get_capabilities_string) !!! Unable to get capabilities for monitor on [i2c: fd=3, busno=10] (app_get_capabilities_string ) Unexpected status code: DDCRC_NULL_RESPONSE(-3002): received DDC null response

when issuing the same command on the lg5k monitor Capabilities for display on bus /dev/i2c-11 Unparsed capabilities string: (prot(monitor)type(LCD)model(RTK)cmds(01 02 03 07 0C E3 F3)vcp(02 04 05 06 08 0B 0C 10 12 14(01 02 04 05 06 08 0B) 16 18 1A 52 60(01 03 04 0F 10 11 12) 87 AC AE B2 B6 C6 C8 CA CC(01 02 03 04 06 0A 0D) D6(01 04 05) DF FD FF)mswhql(1)asset_eep(40)mccs_ver(2.2))

i've attached some logs: interrogate.txt environmentVerbose.txt

thank you

ive looked at how ddc is communicated under macos, this is an excerpt of the write function for intel macs from a program called lunar


bool DDCWrite(io_service_t framebuffer, struct DDCWriteCommand* write, uint8_t sleepFactor)
{
    IOI2CRequest request;
    UInt8 data[256];

    bzero(&request, sizeof(request));

    request.commFlags = 0;

    request.sendAddress = 0x6E;
    request.sendTransactionType = kIOI2CSimpleTransactionType;
    request.sendBuffer = (vm_address_t)&data[0];
    request.sendBytes = 7;

    data[0] = 0x51;
    data[1] = 0x84;
    data[2] = 0x03;
    data[3] = write->control_id;
    data[4] = (write->new_value) >> 8;
    data[5] = write->new_value & 255;
    data[6] = 0x6E ^ data[0] ^ data[1] ^ data[2] ^ data[3] ^ data[4] ^ data[5];

    request.replyTransactionType = kIOI2CNoTransactionType;
    request.replyBytes = 0;

    bool result = FramebufferI2CRequest(framebuffer, &request, sleepFactor);
    return result;
}

is this any different than how ddcutil communicates with monitors?

@24fpsDaVinci Hopefully this late reply is still of use to you.

The capabilities command is the most problematic for DDC communication, since it strings together multiple I2C write/read sequences, each of which must succeed. The DDC Null Response has various meanings in different contexts, in this it is probably the monitor responding that it can't process a request. The trace messages are output by ddcutil to make immediately clear what is happening.

The ddc, excp, and stats may help clarify the errors. which are buried in layers of retry. It may simply be an incompatibility of the monitor/gpu/driver combination. I would also suggest using the --sleep-multiplier option, e.g. sleep-multiplier 2.0 to increase the time ddcutil waits after transmitting a request packet before it attempts to read the response.

The lunar function definition you provided is essentially what ddcutil does to write a request packet. The sleepFactor paramenter provides for a sleep time adjustment. Without examining lunar in detail, I can't way whether this is simply a way to modify the sleep time for a particular request as per the DDC/CI spec, or it is used to tune execution. ddcutil sets a sleep time based on the DDC/CI spec, then applies the -sleep-multiplier factor to increase or decrease the sleep time.

rockowitz / ddcutil

LG ultrafine capabilities error #213