Changing Power Mode? about ddcutil

[Platypus2]

I noticed if I set the monitor on when it is, the command does not return the same error. It only seems to happen when turning the monitor off -> on. On -> off or on - on is fine.

I ran

ddcutil setvcp D6 x01 --trace ddc

This is the output: https://pastebin.com/V2pTKQqk

Also:

ddcutil environment --verbose
https://pastebin.com/gWHeq8Q6

ddcutil interrogate
https://pastebin.com/k05QmNsu

Any idea what the Segmentation fault might be from? Anything else that might be useful?

[rockowitz]

On 10/20/2017 04:45 PM, Platypus2 wrote: I recently started running ddcutil on a Pi to easily switch input modes on my Dell monitor. No problems so far. I noticed with the ddcutil capabilities command that I also had: |Feature: D6 (Power mode)| |Values:| |01: DPM: On, DPMS: Off| |04: DPM: Off, DPMS: Off| |05: Write only value to turn off display|

First, a word of caution.   Consider the output of capabilities to a hint, not a guarantee.   The capabilities string returned by the monitor is often wrong - ddcutil does not rely on it.    To see the full set of values defined by the spec:    # ddcutil vcpinfo d6 --verbose But note that a given monitor need not implement all possible values, and for some VCP codes may implement values not defined in the spec.  To see what values the monitor actually supports, try setting the value with setvcp and then check it with getvcp.

Is this safe to use?

If a monitor accepts a value, I don't see why that would be unsafe. But I have no specific knowledge about power management.

I did try it, turning off worked fine with 'ddcutil setvcp D6 x05'. I set it back on, 'ddcutil setvcp D6 x01' (which is what it was when I hadn't touched it).

Did you set it back on by physically turning the monitor on?   Or were you able to use the setvcp command to turn it on?  I would be surprised if that worked.

That also worked, but I got this 'additional' response: Setting value failed for feature d6. rc=DDCRC_RETRIES(-3015): maximum retries exceeded

That error message could be improved.  It comes from the recently added code that automatically verifies the value set by reading it after writing.   Basically it says that reading the value failed because the maximum number of I2C retries was exceeded. Try issuing the setvcp command with the --verbose option.  That will give a detailed report of what is happening.

Do you know why this might happen? It worked fine, I just would be happier knowing why that happened and whether it was safe to use frequently.

Please collect the output of command "ddcutil interrogate" in a file and send it as an attachment.  That should help me better understand your environment.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#36>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbo0yr02ygkinIjxshdMtjhSnlvK9ks5suQZVgaJpZM4QBNaH>.

[Platypus2]

Thanks for the reply :)

First, a word of caution. Consider the output of capabilities to a
hint, not a guarantee. The capabilities string returned by the monitor
is often wrong - ddcutil does not rely on it. To see the full set of
values defined by the spec:

I probably should have waited for that word of caution, but it worked nonetheless.

ddcutil vcpinfo d6 --verbose

ddcutil vcpinfo d6 --verbose.txt

But note that a given monitor need not implement all possible values,
and for some VCP codes may implement values not defined in the spec. To
see what values the monitor actually supports, try setting the value
with setvcp and then check it with getvcp.

This is what I get after turning the monitor back on with setvcp. It is exactly the same as I got when I did getvcp before evening trying to set the power mode.

pi@raspberrypi:~ $ ddcutil getvcp D6
VCP code 0xd6 (Power mode ): DPM: On, DPMS: Off (sl=0x01)

Did you set it back on by physically turning the monitor on? Or were
you able to use the setvcp command to turn it on? I would be surprised
if that worked.

I was surprised as well to be honest - but yes it does work setting it back on after turning it off. I used x05 to turn off, and x01 turn back on. It works, aside from this 'error' of maximum retries exceeded, but the monitor does in fact turn back on.
It's not really 'turned off', its a dell monitor with a touch panel, so it has to be on to some degree to detect the touch. I can even switch input source with the monitor in this state - this is what I tried first before attempting the power mode (I switched the monitor off with touch and then sent the input source command and it was successfully changed with the monitor 'off').

Try issuing the setvcp command with the --verbose option. That will
give a detailed report of what is happening.

ddcutil setvcp D6 x01 --verbose.txt
ddcutil setvcp D6 x01 --trace ddc.txt

Does that help at all, seems it is failing when trying to verify that it worked? I guess that explains why the monitor turned on successfully but I still get this error as it just can't verify that it worked?

Please collect the output of command "ddcutil interrogate" in a file and
send it as an attachment. That should help me better understand your
environment.

ddcutil interrogate.txt

[rockowitz]

First, thanks for the detailed reports.  They make remote diagnosis possible. Responses interspersed...

On 10/20/2017 06:32 PM, Platypus2 wrote: First, a word of caution. Consider the output of capabilities to a hint, not a guarantee. The capabilities string returned by the monitor is often wrong - ddcutil does not rely on it. To see the full set of values defined by the spec: ddcutil vcpinfo d6 --verbose But note that a given monitor need not implement all possible values, and for some VCP codes may implement values not defined in the spec. To see what values the monitor actually supports, try setting the value with setvcp and then check it with getvcp. I probably should have waited for that word of caution, but it worked nonetheless. ddcutil vcpinfo d6 --verbose.txt <https://github.com/rockowitz/ddcutil/files/1403505/ddcutil.vcpinfo.d6.--verbose.txt> Did you set it back on by physically turning the monitor on? Or were you able to use the setvcp command to turn it on? I would be surprised if that worked. I was surprised as well to be honest - but no it does work setting it back on after turning it off. I used x05 to turn off, and x01 turn back on. It works, aside from this 'error' of maximum retries exceeded, but the monitor does in fact turn back on. It's not really 'turned off', its a dell monitor with a touch panel, so it has to be on to some degree to detect the touch. I can even switch input source with the monitor in this state - this is what I tried first before attempting the power mode.

Most interesting.  Which model?

Try issuing the setvcp command with the --verbose option. That will give a detailed report of what is happening. ddcutil setvcp D6 x01 --verbose.txt <https://github.com/rockowitz/ddcutil/files/1403506/ddcutil.setvcp.D6.x01.--verbose.txt> ddcutil setvcp D6 x01 --trace ddc.txt <https://github.com/rockowitz/ddcutil/files/1403507/ddcutil.setvcp.D6.x01.--trace.ddc.txt>

What the DDCRC_RETRIES error is hiding is that each read attempt is failing because the I2C response packet envelope is malformed (DDCRC_RESPONSE_ENVELOPE).  Unfortunately, --trace ddc does not show the bytes of the response (I'll add that ability in the next point release), but it's safe to say that even though the monitor has been turned back on its I2C communication is not quite right.    What happens if you issue the command "ddcutil getvcp d6 --verbose" after a few seconds.   Does getvcp work then?    If it does, as a work around I'd suggest adding the "--noverify" option to the setvcp command.  It will case the verifying getvcp call within setvcp to be skipped.   If the monitor turns on, well you know the command worked.   In fact, setvcp almost always does.  The --verify option was recently added to address some other pathological situations.

Does that help at all, seems it is failing when trying to verify that it worked? I guess that explains why the monitor turned on successfully but I still get this error as it just can't verify that it worked? Please collect the output of command "ddcutil interrogate" in a file and send it as an attachment. That should help me better understand your environment. ddcutil interrogate.txt <https://github.com/rockowitz/ddcutil/files/1403510/ddcutil.interrogate.txt>

Ugh.   interrogate is hitting a segfault, probably because there's something unexpected in the Pi environment.   Do you have valgrind installed?   If so, running the command valgrind ddcutil interrogate --trace all should show where ddcutil crashes.  If valgrind is not available, just running ddcutil interrogate --trace all may be enough for me to pinpoint the segfault location.   I'd very much appreciate if you can do this, as I don't have a Pi here to test with.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsboVDKm4GtG2uDOh-UVYbxyTOtVJKks5suR9wgaJpZM4QBNaH>.

[Platypus2]

Thank you for the help :)

Most interesting. Which model?

Little bit of background - I have two Dell U2715h. They both currently have 3 (out of 4) inputs plugged in and I find myself frequently having to switch between them throughout the day. I stumbled upon the Dell Display Manager and the ability to switch input sources via the command line with it, but quickly found it was windows only which eventually led me to ddcutil :).
My plan at the moment was to use a couple of Pis to change the input source, probably link them together via ethernet and control one via bluetooth and have that control the other via SSH. That way I can switch using my bluetooth keyboard (and a script). Something I thought of trying was to change the input source when the monitor was 'turned off'. To my surprised it worked so I figured there must be someway to turn the monitor off and on if the source switching worked - what would you expect to happen in this situation? I'd have figured something like a 'no display found' error?

What happens if you issue the command "ddcutil getvcp d6 --verbose" after a few seconds. Does getvcp work then?

Yes it does work without any error message - attached:
ddcutil getvcp D6 --verbose.txt

If it does, as a work around I'd suggest adding the "--noverify" option to the setvcp command.

I can confirm that using ddcutil setvcp D6 x01 --noverify works as expected without returning an error of maximum retries exceeded. While I'm more than happy to help - in the short term I presume I'm okay to use this considering it works and no errors are occuring?

Do you have valgrind installed? If so, running the command valgrind ddcutil interrogate --trace all

I just installed it, it seemed to get stuck, I waited for a few minutes but nothing else happen - don't think thats normal. It wouldn't even let me escape out of it. Nonetheless here is the output that I managed to get from it before it gets stuck:

valgrind ddcutil interrogate --trace all.txt

I ran the ddcutil interrogate --trace all as well just in case that provided any more information:

ddcutil interrogate --trace all.txt

I'd very much appreciate if you can do this, as I don't have a Pi here to test with.

No problem, I have a few Pis and img backups. If the monitor supports stuff like this (switching input sources without it being set to that source to begin with etc), I feel the Pis can be really useful for this sort of thing :D

[rockowitz]

Thanks for the detailed info. Comments interspersed ...

On 10/21/2017 07:34 AM, Platypus2 wrote: Thank you for the help :) Most interesting. Which model? Little bit of background - I have two *Dell U2715h*. They both currently have 3 inputs plugged in and I find myself frequently having to switch between them throughout the day. I stumbled upon the Dell Display Manager and the ability to switch input sources via the command line with it, but quickly found it was windows only which eventually led me to ddcutil :). My plan at the moment was to use a couple of Pis to change the input source, probably link them together via ethernet and control one via bluetooth and have that control the other via SSH. That way I can switch using my bluetooth keyboard (and a script). Something I thought of trying was to change the input source when it was 'turned off'. To my surprised it worked so I figured there must be someway to turn it off and on if the source switching worked - what would you expect to happen in this situation? I'd have figured something like a 'no display found' error? What happens if you issue the command "ddcutil getvcp d6 --verbose" after a few seconds. Does getvcp work then? Yes it does work without any error message - attached: ddcutil getvcp D6 --verbose.txt <https://github.com/rockowitz/ddcutil/files/1404034/ddcutil.getvcp.D6.--verbose.txt> If it does, as a work around I'd suggest adding the "--noverify" option to the setvcp command. I can confirm that using |ddcutil setvcp D6 x01 --noverify| works as expected without returning an error of maximum retries exceeded. While I'm more than happy to help - in the short term I presume I'm okay to use this considering it works and no errors are occuring?

Looks like it takes a while after "ddcutil setvcp d6 x01" for the monitor to properly initialize.  The verification read is just happening too soon.  Just a special case where --verify doesn't work.  Bottom line, the monitor wakes up, so you can see that setvcp succeeded.

Do you have valgrind installed? If so, running the command valgrind ddcutil interrogate --trace all I just installed it, it seemed to just get stuck, I waited for a few minutes but nothing else happen - don't think thats normal. It wouldn't even let me escape out of it. Nonetheless here is the output that I managed to get from it before it gets stuck: valgrind ddcutil interrogate --trace all.txt <https://github.com/rockowitz/ddcutil/files/1404038/valgrind.ddcutil.interrogate.--trace.all.txt>

It's getting stuck during valgrind initialization.

I ran the ddcutil interrogate --trace all as well just in case that provided any more information: ddcutil interrogate --trace all.txt <https://github.com/rockowitz/ddcutil/files/1404043/ddcutil.interrogate.--trace.all.txt>

As you could see, no real info.   I'll have to add some more tracing.   How are you building/installing ddcutil? Also, what values are returned by the following commands: arch uname -m uname -p uname -i

…

I'd very much appreciate if you can do this, as I don't have a Pi here to test with No problem, I have a few Pis and img backups. If the monitor supports stuff like this (switching input sources without it being set to that source to begin with etc), I feel the Pis can be really useful for this sort of thing :D — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbsnxh_N24VO7Syv6hkSwVyeQTmuaks5sudaxgaJpZM4QBNaH>.

[Platypus2]

It's getting stuck during valgrind initialization.

Is that a valgrind installation problem then?

How are you building/installing ddcutil?

I built it from source following the documentation provided here:
http://www.ddcutil.com/building/

Installing the packages required before compiling on the pi itself. I also changed the config settings as detailed here:
http://www.ddcutil.com/raspberry/

Also, what values are returned by the following commands:

arch

armv7l

uname -m

armv7l

uname -p

unknown

uname -i

unknown

Let me know if you need anything else.

[Antoron]

I was very surprised, that 'ddcutil setvcp D6 x01' command worked for my Viewsonic vp2250wb when I switched it off with official 'd6 5'. It turned it on several timed and then stopped. Only physical button helped. When I changed OFF command to 'D6 x05' - ON became usable again! And vice versa. Display can be off for several hours and then be successfully turned on. Tried --verify, --maxtries, etc. looks like that only a change does the case. Not always. But it could be turned ONLY with 'ddcutil setvcp D6 x01' command!
Is it possible to understand a dependency here?

[rockowitz]

Antoron, There is no difference in the commands: ddcutil setvcp d6 5 ddcutil setvcp d6 x5 ddcutil setvcp dc x05 Based on your report I double checked this by turning on tracing at the I2C level. The correlation you've observed is accidental. You can see this for yourself by adding option "--trace i2c" and looking for the line: (invoke_i2c_writer) writer=read_writer, bytes_to_write=51 84 03 d6 00 05 6b which is the I2C command to the set value. Note first that not all monitors support feature value 5 to turn off the monitor. The "ddcutil capabilities" command should report the supported values for feature D6, but keep in mind that the DDC capabilities string returned by a monitor is not always accurate. None of the monitors here that support value 5 to turn off the monitor can be turned back on using feature D6 once they have been turned off. This is what I would expect: if a monitor is off then it's off. However, it is possible that your monitor is doing something to remain responsive to DDC commands even though it appears to be turned off. There's a lot of variability in DDC implementation across monitors. Sanford

…

On 06/18/2018 03:11 PM, Antoron wrote: I was very surprised, that 'ddcutil setvcp D6 x01' command worked for my Viewsonic vp2250wb when I switched it off with official 'd6 5'. It turned it on several timed and then stopped. Only physical button helped. When I changed OFF command to 'D6 x05' - ON became usable again! And vice versa. Display can be off for several hours and then be successfully turned on. Tried --verify, --maxtries, etc. looks like that only a change does the case. Not always. But it could be turned ONLY with 'ddcutil setvcp D6 x01' command! Is it possible to understand a dependency here? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbu1tt3BP5i3Wwbd9aJj4Ave_tG6Rks5t9_twgaJpZM4QBNaH>.

[tkna91]

In my environment, it often failed when turning On/Off displays with the same model number but different serial numbers. I repeated the process until it succeeded and it generally worked.

# power off
for i in {1..99} ; do
    ddcutil --model="VY249" --sn="R2LMRS000394" setvcp d6 x05 && break
done
for i in {1..99} ; do
    ddcutil --model="VY249" --sn="R2LMRS005074" setvcp d6 x05 && break
done

# power on
for i in {1..99} ; do
    ddcutil --model="VY249" --sn="R2LMRS000394" setvcp d6 x01 && break
done
for i in {1..99} ; do
    ddcutil --model="VY249" --sn="R2LMRS005074" setvcp d6 x01 && break
done