loadvcp failes when only EDID is present,about rockowitz/ddcutil

Comments (14)

mkoskar commented on June 8, 2024

RE: quiet output, I've obviously missed the -t option although the following warning goes to stdout instead of stderr:

VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate.
VCP 10 ERR

from ddcutil.

rockowitz commented on June 8, 2024

On 07/30/2017 06:38 PM, Miroslav Koskar wrote: I've used |dumpvcp| to create a dump file and then went ahead and started messing with it a bit :). I've noticed that when I've removed all the identification except EDID |loadvcp| failed with: |ddcutil: base/displays.c:211: create_mfg_model_sn_display_identifier: Assertion `strlen(pIdent->mfg_id) + strlen(pIdent->model_name) + strlen(pIdent->serial_ascii) > 0' failed. [1] 8411 abort (core dumped) ddcutil loadvcp file | Is there any reason for failing? |ddcutil --edid <EDID>| works ok.

Just an edge case that should result in an error message, not an assert failure. Not handling the edge case where the identifiers have been stripped from the VCP file. When the --edid option is specified, ddcutil ignores the identifiers in the VCP file, which explains why that case works. A will go into the next point release. Thanks for reporting it. Sanford

…

*Feedback:* Thanks for |ddcutil|! I'm playing with it for some time already. My initial interest was to test if my monitor is off or not. Seems I can do it with |ddcutil getvcp d6| and parse for |sl=0x05|. I was wondering that maybe some option for making output a bit more quiet, that is showing just a value? So far I'm using this for setting brightness. * Intel HD 4000 (i915) * DELL U2412M (VCP Version: 2.1) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbp42gDir1ntdc1h0tkWYVsyNbhkBks5sTQXXgaJpZM4OnxJ9>.

from ddcutil.

rockowitz commented on June 8, 2024

I assume you're getting these messages when you've turned off the monitor. I can see the argument that this output should go to stderr. But consider. The first line is essentially informational, and could preface the output for multiple fields. If the output level were normal or verbose, one would clearly expect it to be part of the larger report. It would be odd for it to sometimes go to stdout and other times to stderr. Similarly, it would be odd if "VCP 10 value" goes to stdout, but "VCP 10 ERR" goes to stderr, especially if we're reporting multiple VCP codes, in which case a report could be split between stdout and stderr. From one perspective, this may be an error. From another it's just a normal data response. So generally all output goes to stdout, unless its clearly an error. Sanford

…

On 07/30/2017 07:30 PM, Miroslav Koskar wrote: RE: quiet output, I've obviously missed the |-t| option although the following warning goes to /stdout/ instead of /stderr/: |VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate. VCP 10 ERR | — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsblqjYBtGJAaqa2d91LH1eohzCRKfks5sTRIngaJpZM4OnxJ9>.

from ddcutil.

mkoskar commented on June 8, 2024

I would expect first line (informational as you say) go to stderr and the real response VCP 10 ERR go to stdout. So that when inside the shell I can easily get only the response for parsing e.g., pwr=$(ddcutil -t -e "$edid" getvcp d6). I can filter the output for the last line of course but why not to benefit from stderr. If one needs all, there is always 2>&1. Well, just an idea.

What I do now is that I ignore output if I get exit status > 0 so:

if pwr=$(ddcutil -t -e "$edid" getvcp d6); then
    pwr=$(awk '{print $4}' <<<"$pwr")
    [[ $pwr = 'x05' ]] && continue
fi

from ddcutil.

rockowitz commented on June 8, 2024

Miroslav, I believe you're conflating informational messages with error messages. What you really want is a distinction between lines you want to parse and lines you want to ignore, i.e. another output format option named, for sake of specificity, --program. Consider, for example, the output of "ddcutil getvcp profile --verbose". How would you split that into stdout and stderr in a way that's both consistent with the stdout/stderr distinction and consistent with the split you propose for "ddcutil getvcp profile --terse"? Sanford

…

On 07/31/2017 04:07 AM, Miroslav Koskar wrote: I would expect first line (informational as you say) go to stderr and the real response |VCP 10 ERR| go to stdout. So that when inside the shell I can easily get only the response for parsing e.g., |pwr=$(ddcutil -t -e "$edid" getvcp d6)|. I can filter the output for the last line of course but why not to benefit from stderr. If one needs all, there is always |2>&1|. Well, just an idea. What I do now is that I ignore output if I get exit status > 0 so: |if pwr=$(ddcutil -t -e "$edid" getvcp d6); then pwr=$(awk '{print $4}' <<<"$pwr") [[ $pwr = 'x05' ]] && continue fi | — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbhh8VoMCLgHKbGlutlgXYsoANkCdks5sTYsygaJpZM4OnxJ9>.

from ddcutil.

mkoskar commented on June 8, 2024

Well for --verbose it's ok to dump everything to stdout because that's what user expects. You are right to say this is about output format, that is stdout format. I was just surprised to see that line there, I actually get it when interrogating my laptop's LVDS panel which obviously doesn't support DDC while still having i2c bus. It's design decision and that's ok with me, just thought I point it out ;).

from ddcutil.

rockowitz commented on June 8, 2024

Miroslav, Please don't get me wrong. I very much appreciate the input, and you're not the first person to request changes that would make ddcutil easier to script. So seeing those use cases is very helpful. It's just that I'm having a hard time coming up with a simple, consistent way to handle the gray areas of stdout vs stderr. What commands did you use to get the output you reported, i.e.: ||| VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate. VCP 10 ERR | Are you forcing the I2C address for the LVDS panel using the --bus option? If so, what is normal output, i.e. without --terse? Sanford

…

On 07/31/2017 08:05 AM, Miroslav Koskar wrote: Well for --verbose it's ok to dump everything to stdout because that's what user expects. You are right to say this is about output format, that is stdout format. I was just surprised to see that line there, I actually get it when interrogating my laptop's LVDS panel which obviously doesn't support DDC while still having i2c bus. It's design decision and that's ok with me, just thought I point it out ;). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbjWSzkElSXOwAjPU0cLpt-aHIzKiks5sTcMPgaJpZM4OnxJ9>.

from ddcutil.

mkoskar commented on June 8, 2024

No worries, I don't want to be nitpicking on details. My original point here was to point out that while ddcutil -e would work that is find display only by edid, loadvcp wouldn't and fail on assert but I concede I edited the file which is kinda dumb anyway :).

RE: format thing. Yes I get this when targeting LVDS monitor directly either by bus or by edid.
What I do now in my script is that I want to filter out monitors that are turned off, so I cycle through all outputs and call ddcutil for edid that I have from sysfs. Actually now I figured I can get i2c bus number too; for DP outputs it's directly under output node; the rest is under card node and I match it to the output by the name (e.g., i915 gmbus panel would be for LVDS-1 :| well it's not very nice but works and it's rather fast because I can use --nodetect).

$ ddcutil detect
Invalid display
   I2C bus:             /dev/i2c-2
   Supports DDC:        false
   EDID synopsis:
      Mfg id:           LEN
      Model:            Unspecified
      Serial number:    Unspecified
      Manufacture year: 2008
      EDID version:     1.3
   DDC communication failed

$ ddcutil -t -e <edid> getvcp d6
VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate.
VCP D6 ERR

$ ddcutil -e <edid> getvcp d6
VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate.
VCP code 0xd6 (Power mode                    ): Invalid response. status code=ENXIO(-6): No such device or address

from ddcutil.

rockowitz commented on June 8, 2024

The following changes will go into the next point release of ddcutil: 1) If output level is --terse, the "version for display is undetected" message will not be shown. 2) As mentioned previously, if all monitor identifiers are missing from the VCP file then loadvcp will fail will an error message and not abort. 3) The situation where the --edid option (or another option) specifies a monitor that does not support DDC will be handled as a "Display not found". This message is written stderr, and ddcutil returns with status code 1 indicating failure. This is a bug fix. The internal lookup function was not checking for DDC support. So the behavior of your "ddcutil -e <edid> getvcp d6" example will change. How specifically are you associating I2C bus numbers with device names under sysfs. Not sure what you mean by the output node. Can you give me some fully qualified /sys path names that you use? Regards, Sanford

…

On 08/01/2017 07:21 AM, Miroslav Koskar wrote: No worries, I don't want to be nitpicking on details. My original point here was to point out that while |ddcutil -e| would work that is find display only by edid, |loadvcp| wouldn't and fail on assert but I concede I edited the file which is kinda dumb anyway :). RE: format thing. Yes I get this when targeting LVDS monitor directly either by bus or by edid. What I do now in my script is that I want to filter out monitors that are turned off, so I cycle through all outputs and call |ddcutil| for edid that I have from |sysfs|. Actually now I figured I can get i2c bus number too; for DP outputs it's directly under output node; the rest is under card node and I match it to the output by the name (e.g., |i915 gmbus panel| would be for |LVDS-1| :| well it's not very nice but works and it's rather fast because I can use |--nodetect|). |$ ddcutil detect Invalid display I2C bus: /dev/i2c-2 Supports DDC: false EDID synopsis: Mfg id: LEN Model: Unspecified Serial number: Unspecified Manufacture year: 2008 EDID version: 1.3 DDC communication failed $ ddcutil -t -e <edid> getvcp d6 VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate. VCP D6 ERR $ ddcutil -e <edid> getvcp d6 VCP (aka MCCS) version for display is undetected or less than 2.0. Output may not be accurate. VCP code 0xd6 (Power mode ): Invalid response. status code=ENXIO(-6): No such device or address | — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbpJhcbBRZx80_jnYkGp7KqY5ufvkks5sTwpJgaJpZM4OnxJ9>.

from ddcutil.

mkoskar commented on June 8, 2024

Ok, cool. Thanks!

RE: I2C bus numbers

+0:drm$ pwd
/sys/class/drm

+0:drm$ ls -lad card0/card0-*
drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-1
drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-2
drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-3
drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-1
drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-2
drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-3
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-LVDS-1
drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-VGA-1

+0:drm$ ls -lad card0/card0-*/i2c-*
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-1/i2c-6
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-2/i2c-7
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-3/i2c-8

+0:drm$ cat card0/card0-*/i2c-*/name
DPDDC-B
DPDDC-C
DPDDC-D

+0:drm$ ls -lad card0/device/i2c-*
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-0
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-1
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-2
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-3
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-4
drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-5

+0:drm$ cat card0/device/i2c-*/name
i915 gmbus ssc
i915 gmbus vga
i915 gmbus panel
i915 gmbus dpc
i915 gmbus dpb
i915 gmbus dpd

So for whatever reason it seems DP outputs have their i2c associated directly underneath "output node" that is e.g., card0/card0-DP-1 sysfs path.

For the rest I've assumed simple translation table:

bus2out['i915 gmbus dpb']='HDMI-A-1'
bus2out['i915 gmbus dpc']='HDMI-A-2'
bus2out['i915 gmbus dpd']='HDMI-A-3'
bus2out['i915 gmbus panel']='LVDS-1'
bus2out['i915 gmbus vga']='VGA-1'

Here is the bash script where I'm using it.

from ddcutil.

rockowitz commented on June 8, 2024

Clever using /sys/class/drm/card0/card0-*/i2c-* to associate the I2C bus with the connector and its EDID. Sadly, as with so many things related to DDC, the tests used in the script are driver dependent. A quick check shows that the card0-*/i2c-* nodes are present for the following drivers: i915, radeon, amdgpu. They are not present for the following drivers: nouveau, nvidia. Also, while the name field in the i2c-n directory for i915 devices, e.g. "i915 gmbus vga" is pretty descriptive and easily associated with a display, for other drivers it is not. For example, with the nvidia (proprietary) driver, name looks like "NVIDIA i2c adapter 8 at 1:00.0". I wish there were a generalizable way to get the EDID associated with an I2C bus without having to read it myself over I2C. Regards, Sanford

…

On 08/02/2017 11:34 AM, Miroslav Koskar wrote: Ok, cool. Thanks! RE: I2C bus numbers |+0:drm$ pwd /sys/class/drm +0:drm$ ls -lad card0/card0-* drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-1 drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-2 drwxr-xr-x 5 root root 0 Jul 30 22:15 card0/card0-DP-3 drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-1 drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-2 drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-HDMI-A-3 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-LVDS-1 drwxr-xr-x 3 root root 0 Jul 30 22:15 card0/card0-VGA-1 +0:drm$ ls -lad card0/card0-*/i2c-* drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-1/i2c-6 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-2/i2c-7 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/card0-DP-3/i2c-8 +0:drm$ cat card0/card0-*/i2c-*/name DPDDC-B DPDDC-C DPDDC-D +0:drm$ ls -lad card0/device/i2c-* drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-0 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-1 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-2 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-3 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-4 drwxr-xr-x 4 root root 0 Jul 30 22:15 card0/device/i2c-5 +0:drm$ cat card0/device/i2c-*/name i915 gmbus ssc i915 gmbus vga i915 gmbus panel i915 gmbus dpc i915 gmbus dpb i915 gmbus dpd | So for whatever reason it seems DP outputs have their i2c associated directly underneath "output node" that is e.g., |card0/card0-DP-1| sysfs path. For the rest I've assumed simple translation table: |bus2out['i915 gmbus dpb']='HDMI-A-1' bus2out['i915 gmbus dpc']='HDMI-A-2' bus2out['i915 gmbus dpd']='HDMI-A-3' bus2out['i915 gmbus panel']='LVDS-1' bus2out['i915 gmbus vga']='VGA-1' | Here <https://github.com/mkoskar/homefiles/blob/master/bin/edidsum> is the bash script where I'm using it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbo5gg8eljd-0TQxTBlnbpaIS388Yks5sUJb5gaJpZM4OnxJ9>.

from ddcutil.

mkoskar commented on June 8, 2024

Yep, I imagined it would be highly driver dependent ... it's kind of a hack really. Also doesn't make much sense to me why for i915 that direct association is done only for DP ports. Also interesting why nouveau wouldn't do it, no wonder about proprietary drivers though.

Anyway thanks for the info / and changes done. I guess we can close this issue then.

from ddcutil.

rockowitz commented on June 8, 2024

On 08/04/2017 06:27 AM, Miroslav Koskar wrote: Yep, I imagined it would be highly driver dependent ... it's kind of a hack really. Also doesn't make much sense to me why for |i915| that direct association is done only for DP ports. Also interesting why |nouveau| wouldn't do it, no wonder about proprietary drivers though.

FWIW, similarly for the radeon driver there's a direct association only on the DP ports. I suspect it has something to do with the fact that for DP connections I2C communication is emulated using the aux channel (I2C-Over-Aux).

Anyway thanks for the info / and changes done. I guess we can close this issue then.

Thanks for the input. I'll leave this issue open for a couple days in case there's anything more to be said, then close it if not.

…

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

from ddcutil.

mkoskar commented on June 8, 2024

Yes, you're correct about DP ports. I've asked in #intel-gfx freenode channel and somebody explained to me that those i2c buses correspond to DP-aux channels. When I've inquired about why the other i2c buses aren't associated in similar fashion, I got congratulated that I'm most likely the first person to care and that they welcome patches :).

from ddcutil.

loadvcp failes when only EDID is present about ddcutil HOT 14 CLOSED

Comments (14)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent