setvcp settings revert after ~1 second

[xflakes]

Hi!
I've run into a strange problem using ddutil. It correctly detects my display (over DisplayPort) and I can set the brightness as I want. However, after ~1 second it goes back to the previous brightness setting.
I'm not sure what information to provide, but here's the output of ddcutil detect:

Display 1
   I2C bus:             /dev/i2c-8
   Supports DDC:        true
   EDID synopsis:
      Mfg id:           GSM
      Model:            LG Ultra HD
      Serial number:    Unspecified
      Manufacture year: 2015
      EDID version:     1.4
   VCP version:         2.1

Any ideas what might be causing this? I'm happy to provide further information on my setup if needed.
Cheers!

[rockowitz]

Just noticed that the reply sent from my email program on 9/20 does not appear in the github issue tracker, so I'm reposting. Well that's a strange one.   From what you describe, ddcutil is correctly setting the new value, then the value is lost.   A couple things to try: 1) What happens if you add the --noverify option to the setvcp command?   Normally, ddcutil reads the value from the monitor after setting it to verify that the value has been properly set. 2) Do you see this behavior for other VCP feature codes, or just brightness? Sanford

…

On 09/20/2017 03:12 PM, Flo wrote: Hi! I've run into a strange problem using ddutil. It correctly detects my display (over DisplayPort) and I can set the brightness as I want. However, after ~1 second it goes back to the previous brightness setting. I'm not sure what information to provide, but here's the output of |ddcutil detect|: |Display 1 I2C bus: /dev/i2c-8 Supports DDC: true EDID synopsis: Mfg id: GSM Model: LG Ultra HD Serial number: Unspecified Manufacture year: 2015 EDID version: 1.4 VCP version: 2.1 | Any ideas what might be causing this? I'm happy to provide further information on my setup if needed. Cheers! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbsDmslIfiMQ9T3lJtdDMC7fTXf_3ks5skWOHgaJpZM4PeVwh>.

[xflakes]

Hi!
I just retried it, i missed the error message saying:
(ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=8], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response Verification failed for feature 10
With --noverify, there's no output, but same behaviour.

I've also tried changing contrast, doesn't work either (same flickering). Switching inputs works.
I'm beginning to think it's a problem with the Display. Not sure if it even 'officially' supports ddc.

Cheers!

[rockowitz]

Flo, DDC Null Response is an ugly, ambiguous corner of DDC/CI implementations.   As I read the spec it's supposed to be used to indicate like monitor internal error or not ready. Unfortunately, a few monitors also use it to indicate unsupported VCP code.   That ddc_write_read() succeeded after 1 retry indicates there's your monitor's use of DDC Null Response is per the spec, but also that there's something amiss in the monitor's DDC/CI implementation. As to whether the monitor supports DDC/CI, those that do typically (but not always) have a switch in the On Screen Display to enable/disable DDC/CI. Please run the following command and submit the output as a file attachment (it may take a while to execute):   ddcutil interrogate This will better help me understand your configuration. Sanford

…

On 10/18/2017 12:14 PM, Flo wrote: Hi! I just retried it, i missed the error message saying: |(ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=8], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response Verification failed for feature 10| With |--noverify|, there's no output, but same behaviour. I've also tried changing contrast, doesn't work either (same flickering). Switching inputs works. I'm beginning to think it's a problem with the Display. Not sure if it even 'officially' supports ddc. Cheers! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbg71AnlvlljbThFEkPZd4b-dFODMks5stiPRgaJpZM4PeVwh>.

[rhtenhove]

Hi Sanford,
I have the same issue with an LG monitor:

Display 1
   I2C bus:             /dev/i2c-5
   Supports DDC:        true
   EDID synopsis:
      Mfg id:           GSM
      Model:            27MU67
      Serial number:    Unspecified
      Manufacture year: 2015
      EDID version:     1.4
   VCP version:         2.1

It is connected using Thunderbolt 3 -> StarTech Mini Displayport adapter -> LG monitor.

This also happens on another system connected via DisplayPort on an AMD graphics card on Windows using ClickMonitorDDC, using a different port on the same monitor. The issue is clearly with the display, but perhaps the interrogate output attached may shed some light for you as to why this happens.

Thanks!
ddcutil-interrogate.log

[rockowitz]

Thanks for sending the report. As the same behavior occurs on Windows with ClickMonitorDDC the issue, as you say, is clearly with the monitor. This is, for me at least, a useful data point when responding to other less detailed bug reports. I'd suggest using enTech's softMCCS <https://www.entechtaiwan.com/lib/softmccs.shtm> utility on Windows to test the monitor. enTech manufactures DDC chip sets, and softMCCS is intended for testing DDC/CI spec compliance. It may have further diagnostics. I do have one off the wall thing you could try. The DDC/CI "Save Current Settings" operation "saves the current monitor settings to the display's nonvolatile storage'. Conceivably, this operation is needed by your display to make the settings stick. The undocumented command "ddcutil scs" will execute this operation. Try putting it in a script with a ddcutil command to change a VCP value so that it is executed within the 1 second window. Though not directly relevant to the problem of reverted settings, I noted the following in the interrogate output. 1) The display exhibits what I call "overeager student syndrome". Instead of setting the "Unsupported VCP code" flag for unsupported features, it returns a junk value. 2) /var/log/syslog is reporting errors in function drm_dp_i2c_do_msg(). If you send the full /var/log/syslog to me I might be able to say more, but my guess is that this is a problem in the i915 driver. 3) The "dkms status" command is reporting that your DKMS generated modules are out of sync. Regards, Sanford

…

On 07/16/2018 05:12 AM, rhtenhove wrote: Hi Sanford, I have the same issue with an LG monitor: |Display 1 I2C bus: /dev/i2c-5 Supports DDC: true EDID synopsis: Mfg id: GSM Model: 27MU67 Serial number: Unspecified Manufacture year: 2015 EDID version: 1.4 VCP version: 2.1 | It is connected using Thunderbolt 3 -> StarTech Mini Displayport adapter -> LG monitor. This also happens on another system connected via DisplayPort on an AMD graphics card on Windows using ClickMonitorDDC, using a different port on the same monitor. The issue is clearly with the display, but perhaps the interrogate output attached may shed some light for you as to why this happens. Thanks! ddcutil-interrogate.log <https://github.com/rockowitz/ddcutil/files/2197042/ddcutil-interrogate.log> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbogSxEtWINYqu8dW9wSLrlFbiXglks5uHFj2gaJpZM4PeVwh>.

[rhtenhove]

Hi, thanks for your swift and extensive response!

I've ran a script, and even tried to run the scs command multiple times directly after the setvcp command:

ddcutil -b 12 setvcp 10 + 10 --noverify & \
while true; do
ddcutil -b 12 scs --noverify
sleep 0.3
done

To no avail.

I failed to mention 2 things:

• brightness revert happens after ~0.2 seconds after the value has visually changed. Trying scs any faster than 0.3 in the script makes the communication fail.
• I am able to change contrast without any issues, same goes for other commands such as color temperature and input select

I've also attached my SoftMCCS output, if that may be of any interest. I did not find any mention of SaveCurrentSettings in that report, which as I understand is feature code 0x0c.
By the way, trying to change brightness using SoftMCCS has the same effect.

GSM5AFD softMCCS test report.txt

I will go into your 2) and 3) remarks later on.

Thanks again!

Regards,
Ruben

[rockowitz]

Reuben, Given that the same behavior occurs on Windows and that it's specific to feature code x10 (brightness), this is clearly a monitor-specific issue. I wonder if there's a "feature" somewhere that causes the monitor to revert the brightness setting. I looked through the user manual and didn't see anything that looked likely. What happens if you try to change the brightness using the on screen display? Have you tried using LG's OnScreen Control software for Windows? Sanford

…

On 07/17/2018 04:52 PM, rhtenhove wrote: Hi, thanks for your swift and extensive response! I've ran a script, and even tried to run the |scs| command multiple times directly after the |setvcp| command: ddcutil -b 12 setvcp 10 + 10 --noverify& \ while true; do ddcutil -b 12 scs --noverify sleep 0.3 done To no avail. I failed to mention 2 things: * brightness revert happens after ~0.2 seconds after the value has visually changed. Trying |scs| any faster than 0.3 in the script makes the communication fail. * I am able to change contrast without any issues, same goes for other commands such as color temperature and input select I've also attached my SoftMCCS output, if that may be of any interest. I did not find any mention of |SaveCurrentSettings| in that report, which as I understand is feature code 0x0c. By the way, trying to change brightness using SoftMCCS has the same effect. GSM5AFD softMCCS test report.txt <https://github.com/rockowitz/ddcutil/files/2203348/GSM5AFD.softMCCS.test.report.txt> I will go into your 2) and 3) remarks later on. Thanks again! Regards, Ruben — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbmie-hBbuE7kp8JJ_y2UZryp9_W0ks5uHk6lgaJpZM4PeVwh>.

[rhtenhove]

That's a sandwich.. ;)

I've also sent an enquiry to LG, in the hope that something conclusive may arise there.

The OSD works properly. If that wasn't the case, then it would clearly be defective. Everything so far points to an improper implementation.
Part of the SoftMCCS test was a full reset, after which the behaviour didn't change. So that shows that it isn't a combination of settings causing the issues.

I've tried the LG software quite a while back, but it isn't compatible with any useful controls of the display.

Ruben

[jonathanmuth]

I ran into the issue described here when setting up BetterDisplay for my 27MU67-B on my Mac.

After spending some time in the OSD, I discovered that the following combination of settings makes the brightness setting stick:

• Picture -> Picture Mode -> Custom
• General -> SMART ENERGY SAVING = High or Low

My guess is that the predefined picture modes are messing with the brightness in the background. Why SMART ENERGY SAVING needs to be active for the brightness setting to stick is a mystery to me …

Hope this helps. Let me know if this does something for you.

Update: Turns out that SMART ENERGY SAVING will change the brightness when there is a lot of movement on screen. So even though the DDC command is accepted at first, the display will revert back to the brightness set via Quick Settings -> Brightness after some time … 😭