search

linuxhw / hw-probe

Probe for hardware, check operability and find drivers
https://linux-hardware.org/?view=timeline
Other
756 stars 68 forks source link

add support for reporting external monitor info using ddcutil #49

Closed pabs3 closed 4 years ago

pabs3 commented 4 years ago

ddcutil speaks the DDC/MCCS protocols for speaking to external VGA/DVI/HDMI monitors. Using the ddcutil detect/capabilities/usbenv/probe/interrogate commands will provide detailed information about the connected monitors.

https://en.wikipedia.org/wiki/Display_Data_Channel https://www.ddcutil.com/

@rockowitz is the author of ddcutil and would probably appreciate having external monitor DDC information in the https://linux-hardware.org/ database.

PS: please note that the ddcutil output currently contains serial numbers from the monitor EDID data, so those will need to be stripped out.

rockowitz commented 4 years ago

Command "ddcutil probe" is the command you'd want to use to get information about a single monitor.  By default it reports the first monitor.  Rather than parsing the output of  "ddcutil detect", it would probably be simplest to loop over "ddcutil probe --display N" starting at N=1 until failure, or (faster) loop over "ddcutil probe --bus N", for N=0..31.

On 1/27/20 10:39 PM, Paul Wise wrote:

ddcutil speaks the DDC/MCCS protocols for speaking to external VGA/DVI/HDMI monitors. Using the ddcutil detect/capabilities/usbenv/probe/interrogate commands will provide detailed information about the connected monitors.

https://en.wikipedia.org/wiki/Display_Data_Channel https://www.ddcutil.com/

@rockowitz https://github.com/rockowitz is the author of ddcutil and would probably appreciate having external monitor DDC information in the https://linux-hardware.org/ database.

PS: please note that the ddcutil output currently contains serial numbers from the monitor EDID data, so those will need to be stripped out.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3WLR2GMXCOZ53GOZB3Q76SH3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJDKYBA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3S5TYG4CDEPBTWKWCTQ76SH3ANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

Is it possible to quickly get list of busy i2c bus numbers? Without iterating over all 0..31. It takes 3 seconds on my machine and this doubles execution time of the hw-probe.

rockowitz commented 4 years ago

Can't think of any way other than opening the /dev/i2c bus and attempting to perform an operation. Note that an open may succeed but an operation fail with errno EBUSY if another driver is accessing the device.  ddcutil queries udev to reduce the set of buses it needs to inspect, but that is not the question you're asking.  What are you trying to do?

On 2/10/20 3:06 PM, Linux Hardware Project wrote:

Is it possible to quickly get list of busy i2c bus numbers? Without iterating over all 0..31. It takes 3 seconds on my machine and this doubles execution time of the hw-probe.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3STVLAPIRMAANJT6MTRCGXVRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKCHTA#issuecomment-584328140, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XXGJ5UIO4F3VAJNWLRCGXVRANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

I need to detect i2c bus numbers where physical monitors are connected. And then run ddcutil probe --bus N on them w/o the need to loop through 0..31.

Something like:

i2cdetect -l | grep "NVIDIA\|nvkm\|i915\|Radeon\|AMDGPU"

On my computer N=2. I need to detect this exact number quickly or somehow reduce the range 0..31.

rockowitz commented 4 years ago

I think the most efficient way to detect which I2C buses have monitors is to examine directories /sys/class/drm/cardN/cardN-  Directory entry edid  returns the EDID if it exists (i.e. if there's a monitor) and entry i2c- gives the I2C bus name.

Note that DDC operations are expensive in terms of elapsed time. ddcutil typically spends 90% of it's elapsed time sleeping due to waits mandated by the DDC protocol.  The "--stats calls" reports the number of Linux IO calls, sleep calls, and the elapsed time for each.

On 2/11/20 2:43 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I need to detect i2c bus numbers where physical monitors are connected. And then run |ddcutil probe --bus N| on them w/o the need to loop through 0..31.

Something like:

|i2cdetect -l | grep "NVIDIA|nvkm|i915|Radeon|AMDGPU" |

On my computer N=2. I need to detect this exact number quickly or somehow reduce the range 0..31.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3RHEQFCZUJHTTOMUITRCJJKRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLPAXY#issuecomment-584511583, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3RXGOYNCYNWEL7TGLTRCJJKRANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

Fixed by f96fd2ff3560cbdec5cea3fd01b58af877ece424. But still need to optimize this and test properly. I have no desktop nearby until Monday (notebooks are not supported).

rockowitz commented 4 years ago

Correction to my prior post.  I just came across some comments indicating that the sysfs i2c-* directory entries do not exist for some drivers. However, If an I2C bus does not have a monitor, command "ddcutil probe --bus N" is pretty cheap.  It entails a single 50 ms DDC protocol mandated sleep, so execution time is just north of that (52 ms on the system I'm writing from).

-- Sanford

On 2/11/20 8:17 AM, Sanford Rockowitz wrote:

I think the most efficient way to detect which I2C buses have monitors is to examine directories /sys/class/drm/cardN/cardN-  Directory entry edid  returns the EDID if it exists (i.e. if there's a monitor) and entry i2c- gives the I2C bus name.

Note that DDC operations are expensive in terms of elapsed time.  ddcutil typically spends 90% of it's elapsed time sleeping due to waits mandated by the DDC protocol.  The "--stats calls" reports the number of Linux IO calls, sleep calls, and the elapsed time for each.

  • Sanford

On 2/11/20 2:43 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I need to detect i2c bus numbers where physical monitors are connected. And then run |ddcutil probe --bus N| on them w/o the need to loop through 0..31.

Something like:

|i2cdetect -l | grep "NVIDIA|nvkm|i915|Radeon|AMDGPU" |

On my computer N=2. I need to detect this exact number quickly or somehow reduce the range 0..31.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3RHEQFCZUJHTTOMUITRCJJKRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLPAXY#issuecomment-584511583, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3RXGOYNCYNWEL7TGLTRCJJKRANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

Could you please attach sample output of ddcutil probe --bus N for a monitor?

Thanks.

rockowitz commented 4 years ago

Attached is output from command "ddcutil probe --bus 14"

Some comments:

1) probe is a wrapper for part or all of other commands, particularly "ddcutil get vcp scan" and "ddcutil capabilities --verbose", and in turn is part of "ddcutil interrogate".  These commands have evolved to simplify the instructions given to users who report problems.  As such, there are no guarantees as to the stability of the output, though the feature scan and capabilities reports have not seen changes in some time.  The API, on the other hand, is expected to be  stable.

2) There was a bug in the use of --bus with probe (unexpected code path).  I caught it this morning when formulating a reply to you. The fix is in the current development branch 0.9.9-dev on github.

-- Sanford On 2/11/20 10:58 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Could you please attach sample output of |ddcutil probe --bus N| for a monitor?

Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3S6COVEFUDIEP2IC2LRCLDJRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELM6U4I#issuecomment-584706673, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QOULBTXFHBHZ45EOTRCLDJRANCNFSM4KML3ZPQ.

EDID version: 1.4 Mfg id: DEL, model: DELL U3011, sn: PH5NY2CIANXL Product code: 16485, binary serial number 1095653452 (0x414e584c)

Unsupported feature indicator: DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED

Capabilities for display on bus /dev/i2c-14 Unparsed capabilities string: (prot(monitor)type(lcd)model(U3011)cmds(01 02 03 07 0C E3 F3)vcp(02 04 05 06 08 10 12 14(01 05 08 0B 0C) 16 18 1A 52 60(01 03 04 0C 0F 11 12) AC AE B2 B6 C6 C8 C9 D6(01 04 05) DC(00 02 03 04 05) DF FD)mccs_ver(2.1)mswhql(1)) MCCS version: 2.1 Commands: Command: 01 (VCP Request) Command: 02 (VCP Response) Command: 03 (VCP Set) Command: 07 (Timing Request) Command: 0c (Save Settings) Command: e3 (Capabilities Reply) Command: f3 (Capabilities Request) VCP Features: Feature: 02 (New control value) Feature: 04 (Restore factory defaults) Feature: 05 (Restore factory brightness/contrast defaults) Feature: 06 (Restore factory geometry defaults) Feature: 08 (Restore color defaults) Feature: 10 (Brightness) Feature: 12 (Contrast) Feature: 14 (Select color preset) Values (unparsed): 01 05 08 0B 0C Values ( parsed): 01: sRGB 05: 6500 K 08: 9300 K 0b: User 1 0c: User 2 Feature: 16 (Video gain: Red) Feature: 18 (Video gain: Green) Feature: 1A (Video gain: Blue) Feature: 52 (Active control) Feature: 60 (Input Source) Values (unparsed): 01 03 04 0C 0F 11 12 Values ( parsed): 01: VGA-1 03: DVI-1 04: DVI-2 0c: Component video (YPrPb/YCrCb) 1 0f: DisplayPort-1 11: HDMI-1 12: HDMI-2 Feature: AC (Horizontal frequency) Feature: AE (Vertical frequency) Feature: B2 (Flat panel sub-pixel layout) Feature: B6 (Display technology type) Feature: C6 (Application enable key) Feature: C8 (Display controller type) Feature: C9 (Display firmware level) Feature: D6 (Power mode) Values (unparsed): 01 04 05 Values ( parsed): 01: DPM: On, DPMS: Off 04: DPM: Off, DPMS: Off 05: Write only value to turn off display Feature: DC (Display Mode) Values (unparsed): 00 02 03 04 05 Values ( parsed): 00: Standard/Default mode 02: Mixed 03: Movie 04: User defined 05: Games Feature: DF (VCP Version) Feature: FD (manufacturer specific feature)

May support table reads: false

Scanning all VCP feature codes for display [i2c: fd=3, busno=14] VCP code 0x02 (New control value ): No new control values (0x01) VCP code 0x03 (Soft controls ): Unsupported feature code VCP code 0x07 (Unknown feature ): Unsupported feature code VCP code 0x09 (Unknown feature ): Unsupported feature code VCP code 0x0b (Color temperature increment ): Invalid value: 0 VCP code 0x0c (Color temperature request ): 3000 + 2 * (feature 0B color temp increment) degree(s) Kelvin VCP code 0x0d (Unknown feature ): Unsupported feature code VCP code 0x0e (Clock ): current value = 50, max value = 100 VCP code 0x0f (Unknown feature ): Unsupported feature code VCP code 0x10 (Brightness ): current value = 85, max value = 100 VCP code 0x11 (Flesh tone enhancement ): Unsupported feature code VCP code 0x12 (Contrast ): current value = 44, max value = 100 VCP code 0x13 (Backlight control ): Unsupported feature code VCP code 0x14 (Select color preset ): User 2 (sl=0x0c) VCP code 0x15 (Unknown feature ): Unsupported feature code VCP code 0x16 (Video gain: Red ): current value = 100, max value = 100 VCP code 0x17 (User color vision compensation): Unsupported feature code VCP code 0x18 (Video gain: Green ): current value = 100, max value = 100 VCP code 0x19 (Unknown feature ): Unsupported feature code VCP code 0x1a (Video gain: Blue ): current value = 100, max value = 100 VCP code 0x1b (Unknown feature ): Unsupported feature code VCP code 0x1c (Focus ): Unsupported feature code VCP code 0x1d (Unknown feature ): Unsupported feature code VCP code 0x1e (Auto setup ): Auto setup not active (sl=0x00) VCP code 0x1f (Auto color setup ): Unsupported feature code VCP code 0x20 (Horizontal Position (Phase) ): current value = 50, max value = 100 VCP code 0x21 (Unknown feature ): Unsupported feature code VCP code 0x22 (Horizontal Size ): Unsupported feature code VCP code 0x23 (Unknown feature ): Unsupported feature code VCP code 0x24 (Horizontal Pincushion ): Unsupported feature code VCP code 0x25 (Unknown feature ): Unsupported feature code VCP code 0x26 (Horizontal Pincushion Balance ): Unsupported feature code VCP code 0x27 (Unknown feature ): Unsupported feature code VCP code 0x28 (Horizontal Convergence R/B ): Unsupported feature code VCP code 0x29 (Horizontal Convergence M/G ): Unsupported feature code VCP code 0x2a (Horizontal Linearity ): Unsupported feature code VCP code 0x2b (Unknown feature ): Unsupported feature code VCP code 0x2c (Horizontal Linearity Balance ): Unsupported feature code VCP code 0x2d (Unknown feature ): Unsupported feature code VCP code 0x2e (Gray scale expansion ): Unsupported feature code VCP code 0x2f (Unknown feature ): Unsupported feature code VCP code 0x30 (Vertical Position (Phase) ): current value = 50, max value = 100 VCP code 0x31 (Unknown feature ): Unsupported feature code VCP code 0x32 (Vertical Size ): Unsupported feature code VCP code 0x33 (Unknown feature ): Unsupported feature code VCP code 0x34 (Vertical Pincushion ): Unsupported feature code VCP code 0x35 (Unknown feature ): Unsupported feature code VCP code 0x36 (Vertical Pincushion Balance ): Unsupported feature code VCP code 0x37 (Unknown feature ): Unsupported feature code VCP code 0x38 (Vertical Convergence R/B ): Unsupported feature code VCP code 0x39 (Vertical Convergence M/G ): Unsupported feature code VCP code 0x3a (Vertical Linearity ): Unsupported feature code VCP code 0x3b (Unknown feature ): Unsupported feature code VCP code 0x3c (Vertical Linearity Balance ): Unsupported feature code VCP code 0x3d (Unknown feature ): Unsupported feature code VCP code 0x3e (Clock phase ): current value = 31, max value = 100 VCP code 0x3f (Unknown feature ): Unsupported feature code VCP code 0x40 (Horizontal Parallelogram ): Unsupported feature code VCP code 0x41 (Vertical Parallelogram ): Unsupported feature code VCP code 0x42 (Horizontal Keystone ): Unsupported feature code VCP code 0x43 (Vertical Keystone ): Unsupported feature code VCP code 0x44 (Rotation ): Unsupported feature code VCP code 0x45 (Unknown feature ): Unsupported feature code VCP code 0x46 (Top Corner Flare ): Unsupported feature code VCP code 0x47 (Unknown feature ): Unsupported feature code VCP code 0x48 (Top Corner Hook ): Unsupported feature code VCP code 0x49 (Unknown feature ): Unsupported feature code VCP code 0x4a (Bottom Corner Flare ): Unsupported feature code VCP code 0x4b (Unknown feature ): Unsupported feature code VCP code 0x4c (Bottom Corner Hook ): Unsupported feature code VCP code 0x4d (Unknown feature ): Unsupported feature code VCP code 0x4e (Unknown feature ): Unsupported feature code VCP code 0x4f (Unknown feature ): Unsupported feature code VCP code 0x50 (Unknown feature ): Unsupported feature code VCP code 0x51 (Unknown feature ): Maximum retries exceeded VCP code 0x52 (Active control ): Value: 0x00 VCP code 0x53 (Unknown feature ): Unsupported feature code VCP code 0x54 (Performance Preservation ): Unsupported feature code VCP code 0x55 (Unknown feature ): Unsupported feature code VCP code 0x56 (Horizontal Moire ): Unsupported feature code VCP code 0x57 (Unknown feature ): Unsupported feature code VCP code 0x58 (Vertical Moire ): Unsupported feature code VCP code 0x59 (6 axis saturation: Red ): current value = 50, max value = 100 VCP code 0x5a (6 axis saturation: Yellow ): current value = 50, max value = 100 VCP code 0x5b (6 axis saturation: Green ): current value = 50, max value = 100 VCP code 0x5c (6 axis saturation: Cyan ): current value = 50, max value = 100 VCP code 0x5d (6 axis saturation: Blue ): current value = 50, max value = 100 VCP code 0x5e (6 axis saturation: Magenta ): current value = 50, max value = 100 VCP code 0x5f (Unknown feature ): Unsupported feature code VCP code 0x60 (Input Source ): DisplayPort-1 (sl=0x0f) VCP code 0x61 (Unknown feature ): Unsupported feature code VCP code 0x62 (Audio speaker volume ): Unsupported feature code VCP code 0x63 (Speaker Select ): Unsupported feature code VCP code 0x64 (Audio: Microphone Volume ): Unsupported feature code VCP code 0x65 (Unknown feature ): Unsupported feature code VCP code 0x66 (Ambient light sensor ): Unsupported feature code VCP code 0x67 (Unknown feature ): Unsupported feature code VCP code 0x68 (Unknown feature ): mh=0x00, ml=0x05, sh=0x00, sl=0x00 VCP code 0x69 (Unknown feature ): Unsupported feature code VCP code 0x6a (Unknown feature ): Unsupported feature code VCP code 0x6b (Backlight Level: White ): Unsupported feature code VCP code 0x6c (Video black level: Red ): current value = 50, max value = 100 VCP code 0x6d (Backlight Level: Red ): Unsupported feature code VCP code 0x6e (Video black level: Green ): current value = 50, max value = 100 VCP code 0x6f (Backlight Level: Green ): Unsupported feature code VCP code 0x70 (Video black level: Blue ): current value = 50, max value = 100 VCP code 0x71 (Backlight Level: Blue ): Unsupported feature code VCP code 0x72 (Gamma ): Unsupported feature code VCP code 0x73 (LUT Size ): Unsupported feature code (DDC NULL Message) VCP code 0x74 (Single point LUT operation ): Unsupported feature code (DDC NULL Message) VCP code 0x75 (Block LUT operation ): Unsupported feature code (DDC NULL Message) VCP code 0x77 (Unknown feature ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 VCP code 0x78 (EDID operation ): Unsupported feature code (DDC NULL Message) VCP code 0x79 (Unknown feature ): Unsupported feature code VCP code 0x7a (Adjust Focal Plane ): Unsupported feature code VCP code 0x7b (Unknown feature ): Unsupported feature code VCP code 0x7c (Adjust Zoom ): Unsupported feature code VCP code 0x7d (Unknown feature ): Unsupported feature code VCP code 0x7e (Trapezoid ): Unsupported feature code VCP code 0x7f (Unknown feature ): Unsupported feature code VCP code 0x80 (Keystone ): Unsupported feature code VCP code 0x81 (Unknown feature ): Unsupported feature code VCP code 0x82 (Horizontal Mirror (Flip) ): Unsupported feature code VCP code 0x83 (Unknown feature ): Unsupported feature code VCP code 0x84 (Vertical Mirror (Flip) ): Unsupported feature code VCP code 0x85 (Unknown feature ): Unsupported feature code VCP code 0x86 (Display Scaling ): Unsupported feature code VCP code 0x87 (Sharpness ): current value = 8, max value = 100 VCP code 0x88 (Velocity Scan Modulation ): Unsupported feature code VCP code 0x89 (Unknown feature ): Unsupported feature code VCP code 0x8a (Color Saturation ): current value = 50, max value = 100 VCP code 0x8c (TV Sharpness ): Unsupported feature code VCP code 0x8d (Audio Mute ): Unsupported feature code VCP code 0x8e (TV Contrast ): Unsupported feature code VCP code 0x8f (Audio Treble ): Unsupported feature code VCP code 0x90 (Hue ): current value = 50, max value = 100 VCP code 0x91 (Audio Bass ): Unsupported feature code VCP code 0x92 (TV Black level/Luminesence ): Unsupported feature code VCP code 0x93 (Audio Balance L/R ): Unsupported feature code VCP code 0x94 (Audio Processor Mode ): Unsupported feature code VCP code 0x95 (Window Position(TL_X) ): Unsupported feature code VCP code 0x96 (Window Position(TL_Y) ): Unsupported feature code VCP code 0x97 (Window Position(BR_X) ): Unsupported feature code VCP code 0x98 (Window Position(BR_Y) ): Unsupported feature code VCP code 0x99 (Window control on/off ): Unsupported feature code VCP code 0x9a (Window background ): Unsupported feature code VCP code 0x9b (6 axis hue control: Red ): current value = 50, max value = 100 VCP code 0x9c (6 axis hue control: Yellow ): current value = 50, max value = 100 VCP code 0x9d (6 axis hue control: Green ): current value = 50, max value = 100 VCP code 0x9e (6 axis hue control: Cyan ): current value = 50, max value = 100 VCP code 0x9f (6 axis hue control: Blue ): current value = 50, max value = 100 VCP code 0xa0 (6 axis hue control: Magenta ): current value = 50, max value = 100 VCP code 0xa1 (Unknown feature ): Unsupported feature code VCP code 0xa3 (Unknown feature ): Unsupported feature code VCP code 0xa4 (Turn the selected window operation on/off): Unsupported feature code VCP code 0xa5 (Change the selected window ): Unsupported feature code VCP code 0xa6 (Unknown feature ): Unsupported feature code VCP code 0xa7 (Unknown feature ): Unsupported feature code VCP code 0xa8 (Unknown feature ): mh=0x00, ml=0x03, sh=0x00, sl=0x00 VCP code 0xa9 (Unknown feature ): Unsupported feature code VCP code 0xaa (Screen Orientation ): Unsupported feature code VCP code 0xab (Unknown feature ): Unsupported feature code VCP code 0xac (Horizontal frequency ): 32864 hz VCP code 0xad (Unknown feature ): Unsupported feature code VCP code 0xae (Vertical frequency ): 59.80 hz VCP code 0xaf (Unknown feature ): Unsupported feature code VCP code 0xb1 (Unknown feature ): Unsupported feature code VCP code 0xb2 (Flat panel sub-pixel layout ): Red/Green/Blue vertical stripe (sl=0x01) VCP code 0xb3 (Unknown feature ): Unsupported feature code VCP code 0xb4 (Source Timing Mode ): mh=0x00, ml=0x02, sh=0x00, sl=0x01 VCP code 0xb5 (Unknown feature ): Unsupported feature code VCP code 0xb6 (Display technology type ): LCD (active matrix) (sl=0x03) VCP code 0xb7 (Monitor status ): Unsupported feature code VCP code 0xb8 (Packet count ): Unsupported feature code VCP code 0xb9 (Monitor X origin ): Unsupported feature code VCP code 0xba (Monitor Y origin ): Unsupported feature code VCP code 0xbb (Header error count ): Unsupported feature code VCP code 0xbc (Body CRC error count ): Unsupported feature code VCP code 0xbd (Client ID ): Unsupported feature code VCP code 0xbe (Link control ): Unsupported feature code VCP code 0xbf (Unknown feature ): Unsupported feature code VCP code 0xc0 (Display usage time ): Usage time (hours) = 20201 (0x004ee9) mh=0x00, ml=0x00, sh=0x4e, sl=0xe9 VCP code 0xc1 (Unknown feature ): Unsupported feature code VCP code 0xc2 (Display descriptor length ): Unsupported feature code VCP code 0xc3 (Transmit display descriptor ): Unsupported feature code (DDC NULL Message) VCP code 0xc4 (Enable display of 'display descriptor'): Unsupported feature code VCP code 0xc5 (Unknown feature ): Unsupported feature code VCP code 0xc6 (Application enable key ): 0x45cc VCP code 0xc7 (Unknown feature ): Unsupported feature code VCP code 0xc8 (Display controller type ): Mfg: Mstar (sl=0x05), controller number: mh=0x00, ml=0x94, sh=0x85 VCP code 0xc9 (Display firmware level ): 1.5 VCP code 0xca (OSD ): OSD Enabled (sl=0x02) VCP code 0xcb (Unknown feature ): mh=0xff, ml=0xff, sh=0x00, sl=0x01 VCP code 0xcc (OSD Language ): English (sl=0x02) VCP code 0xcd (Status Indicators ): Unsupported feature code VCP code 0xce (Auxiliary display size ): Unsupported feature code VCP code 0xd0 (Output select ): Unsupported feature code VCP code 0xd1 (Unknown feature ): Unsupported feature code VCP code 0xd2 (Asset Tag ): Unsupported feature code (DDC NULL Message) VCP code 0xd3 (Unknown feature ): Unsupported feature code VCP code 0xd4 (Stereo video mode ): Unsupported feature code VCP code 0xd5 (Unknown feature ): Unsupported feature code VCP code 0xd6 (Power mode ): DPM: On, DPMS: Off (sl=0x01) VCP code 0xd7 (Auxiliary power output ): Unsupported feature code VCP code 0xd8 (Unknown feature ): Unsupported feature code VCP code 0xd9 (Unknown feature ): Unsupported feature code VCP code 0xda (Scan mode ): Unsupported feature code VCP code 0xdb (Image Mode ): Unsupported feature code VCP code 0xdc (Display Mode ): Standard/Default mode (sl=0x00) VCP code 0xdd (Unknown feature ): Unsupported feature code VCP code 0xde (Scratch Pad ): Unsupported feature code VCP code 0xdf (VCP Version ): 2.1 VCP code 0xe0 (Manufacturer Specific ): Unsupported feature code VCP code 0xe1 (Manufacturer Specific ): Unsupported feature code VCP code 0xe2 (Manufacturer Specific ): Unsupported feature code VCP code 0xe3 (Manufacturer Specific ): mh=0x00, ml=0x01, sh=0x00, sl=0x00 VCP code 0xe4 (Manufacturer Specific ): Unsupported feature code VCP code 0xe5 (Manufacturer Specific ): Unsupported feature code VCP code 0xe6 (Manufacturer Specific ): Unsupported feature code VCP code 0xe7 (Manufacturer Specific ): Unsupported feature code VCP code 0xe8 (Manufacturer Specific ): Unsupported feature code VCP code 0xe9 (Manufacturer Specific ): Unsupported feature code VCP code 0xea (Manufacturer Specific ): Unsupported feature code VCP code 0xeb (Manufacturer Specific ): Unsupported feature code VCP code 0xec (Manufacturer Specific ): Unsupported feature code VCP code 0xed (Manufacturer Specific ): Unsupported feature code VCP code 0xee (Manufacturer Specific ): Unsupported feature code VCP code 0xef (Manufacturer Specific ): Unsupported feature code VCP code 0xf0 (Manufacturer Specific ): Unsupported feature code VCP code 0xf1 (Manufacturer Specific ): Unsupported feature code VCP code 0xf2 (Manufacturer Specific ): Unsupported feature code VCP code 0xf3 (Manufacturer Specific ): Unsupported feature code VCP code 0xf4 (Manufacturer Specific ): Unsupported feature code VCP code 0xf5 (Manufacturer Specific ): Unsupported feature code VCP code 0xf6 (Manufacturer Specific ): Unsupported feature code VCP code 0xf7 (Manufacturer Specific ): Unsupported feature code VCP code 0xf8 (Manufacturer Specific ): Unsupported feature code VCP code 0xf9 (Manufacturer Specific ): Unsupported feature code VCP code 0xfa (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x00 VCP code 0xfb (Manufacturer Specific ): mh=0x00, ml=0x01, sh=0x00, sl=0xcc VCP code 0xfc (Manufacturer Specific ): Unsupported feature code VCP code 0xfd (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x74 VCP code 0xfe (Manufacturer Specific ): Unsupported feature code VCP code 0xff (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x00

Comparing declared capabilities to observed features...

Readable features declared in capabilities string: 02 10 12 14 16 18 1a 52 60 ac ae b2 b6 c6 c8 c9 d6 dc df fd

MCCS (VCP) version reported by capabilities: 2.1 MCCS (VCP) version reported by feature 0xDf: 2.1

All readable features declared in capabilities were found by scanning.

Features found by scanning but not declared as capabilities: Feature x0b - Color temperature increment Feature x0c - Color temperature request Feature x0e - Clock Feature x1e - Auto setup Feature x20 - Horizontal Position (Phase) Feature x30 - Vertical Position (Phase) Feature x3e - Clock phase Feature x59 - 6 axis saturation: Red Feature x5a - 6 axis saturation: Yellow Feature x5b - 6 axis saturation: Green Feature x5c - 6 axis saturation: Cyan Feature x5d - 6 axis saturation: Blue Feature x5e - 6 axis saturation: Magenta Feature x68 - Unknown feature Feature x6c - Video black level: Red Feature x6e - Video black level: Green Feature x70 - Video black level: Blue Feature x77 - Unknown feature Feature x87 - Sharpness Feature x8a - Color Saturation Feature x90 - Hue Feature x9b - 6 axis hue control: Red Feature x9c - 6 axis hue control: Yellow Feature x9d - 6 axis hue control: Green Feature x9e - 6 axis hue control: Cyan Feature x9f - 6 axis hue control: Blue Feature xa0 - 6 axis hue control: Magenta Feature xa8 - Unknown feature Feature xb4 - Source Timing Mode Feature xc0 - Display usage time Feature xca - OSD Feature xcb - Unknown feature Feature xcc - OSD Language Feature xe3 - Manufacturer Specific Feature xfa - Manufacturer Specific Feature xfb - Manufacturer Specific Feature xff - Manufacturer Specific

Color temperature increment (x0b) = 0 degrees Kelvin Color temperature request (x0c) = 2 Requested color temperature = (3000 deg Kelvin) + 2 * (0 degrees Kelvin) = 3000 degrees Kelvin

linuxhw commented 4 years ago

@rockowitz

I'd like to add ddcutil to the hw-probe AppImage. But I don't see commits in 0.9.9-dev from Feb 11. Did you pushed them?

Thanks.

rockowitz commented 4 years ago

My oops.  Done.

On 2/11/20 2:45 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I'd like to add |ddcutil| to the hw-probe AppImage. But I don't see commits in 0.9.9-dev from Feb 11. Did you pushed them?

Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3UTHQXDGKD34OZRFILRCL54TA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNZQRY#issuecomment-584816711, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UTYSJW5PAFL5VCAXLRCL54TANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

BTW

Tried to add ddcutil to Alpine Docker and found missed include of sys/types.h in src/util/edid.h and other Alpine build incompatibilities: https://git.alpinelinux.org/aports/tree/testing/ddcutil/execinfo.patch

Is it possible to include this patch to upstream?

linuxhw commented 4 years ago

@rockowitz

I've tried to build latest 0.9.9 in Alpine 3.11, but failed to link final binary (something is bad with inline value_bytes_zero). Is ddcutil-0.9.1 good enough to use (in Alpine edge)?

rockowitz commented 4 years ago

What declarations are missing when compiling edid.h for Alpine Linux that require sys/types.h?

On 2/12/20 9:01 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

BTW

Tried to add |ddcutil| to Alpine Docker and found missed include of |sys/types.h| in |src/util/edid.h| and other Alpine build incompatibilities: https://git.alpinelinux.org/aports/tree/testing/ddcutil/execinfo.patch

Is it possible to include this patch to upstream?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3T5W5F5QBN7Y4QVLUTRCP6M3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQ3VOY#issuecomment-585218747, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3WCCC7IHHZU7GO76OLRCP6M3ANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

0.9.1 is almost 2 years old.  Numerous enhancements and bug fixes.  I'd rather solve the value_bytes_zero() problem.  What's your compiler/linker output?

On 2/12/20 11:21 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I've tried to build latest 0.9.9 in Alpine 3.11, but failed to link final binary (something is bad with |inline value_bytes_zero|). Is |ddcutil-0.9.1| good enough to use (in Alpine edge)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3XVIEHMPCD5HSGDZSLRCQOXTA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRMMTI#issuecomment-585287245, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VHGT6OCCPUTP744ADRCQOXTANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

What declarations are missing when compiling edid.h for Alpine Linux that require sys/types.h?

ushort type is missed.

rockowitz commented 4 years ago

Interesting.  Normally,  sys/types.h is included from stdlib.h (among other places.  There's no harm in adding an explicit include for sys/types.h.  I will do that.

On 2/12/20 2:12 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

What declarations are missing when compiling edid.h for Alpine
Linux that require sys/types.h?

|ushort| type is missed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3TSHKYBXCCTX3E6OZTRCRCYTA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSAOZY#issuecomment-585369447, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3TVFUC2PGCGMABEAPLRCRCYTANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

0.9.1 is almost 2 years old. Numerous enhancements and bug fixes. I'd rather solve the value_bytes_zero() problem. What's your compiler/linker output?

Full list of problems:

  1. Missed ushort type in edid.h
  2. Missed backtrace_symbols(buffer, nptrs) in src/util/debug_util.c
  3. Missed backtrace(buffer, MAX_ADDRS) in src/util/debug_util.c
  4. Missed sbool in src/*/*.c
  5. Undefined reference to value_bytes_zero

I've applied a temp fix for 1-4 by sed:

sed -i '1s/^/#include <sys/types.h>/' src/util/edid.h \
sed -i -e 's/backtrace_symbols(buffer, nptrs)/NULL/' src/util/debug_util.c \
sed -i -e 's/backtrace(buffer, MAX_ADDRS)/0/' src/util/debug_util.c \
sed -i -e 's/sbool/bool_repr/g' src/*/*.c

But stuck at 5 with no ideas what is going wrong. The error log of the compiler:

...
make[3]: Entering directory '/ddcutil-20200211/src'
  CC       app_ddcutil/ddcutil-main.o
  CC       app_ddcutil/ddcutil-app_dynamic_features.o
  CC       app_ddcutil/ddcutil-app_vcp_info.o
  CC       app_ddcutil/ddcutil-app_dumpload.o
  CC       app_ddcutil/ddcutil-app_setvcp.o
  CC       app_ddcutil/ddcutil-app_getvcp.o
  CCLD     libapp.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     ddcutil
/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libcommon.a(ddc_vcp.o): in function `ddc_get_nontable_vcp_value':
ddc_vcp.c:(.text+0x1014): undefined reference to `value_bytes_zero'
/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ddc_vcp.c:(.text+0x1056): undefined reference to `value_bytes_zero'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:885: ddcutil] Error 1
make[3]: Leaving directory '/ddcutil-20200211/src'
make[2]: *** [Makefile:1132: all-recursive] Error 1
make[2]: Leaving directory '/ddcutil-20200211/src'
make[1]: *** [Makefile:577: all-recursive] Error 1
make[1]: Leaving directory '/ddcutil-20200211'
make: *** [Makefile:484: all] Error 2

What I'm trying to do is to add ddcutil to the Docker image of hw-probe in order to collect DDCs of all connected monitors easily like this was done for edid-decode: https://github.com/linuxhw/hw-probe/blob/master/Dockerfile

rockowitz commented 4 years ago

On 2/12/20 2:31 PM, Linux Hardware Project wrote:

0.9.1 is almost 2 years old. Numerous enhancements and bug fixes.
I'd rather solve the value_bytes_zero() problem. What's your
compiler/linker output?

Full list of problems:

  1. Missed |ushort| type in |edid.h|

|       As per previous message, will add explicit include of sys/types.h. |

  1. Missed |backtrace_symbols(buffer, nptrs)| in |src/util/debug_util.c|
  2. Missed |backtrace(buffer, MAX_ADDRS)| in |src/util/debug_util.c|
configure.ac now checks for the existence of header file execinfo.h.  Type backtrace code is iftested out if the header file is not found.
  1. Missed |sbool| in |src//.c|
  2. Undefined reference to |value_bytes_zero|

I've applied a temp fix for 1-4 by |sed|:

|sed -i '1s/^/#include <sys/types.h>/' src/util/edid.h \ sed -i -e 's/backtrace_symbols(buffer, nptrs)/NULL/' src/util/debug_util.c \ sed -i -e 's/backtrace(buffer, MAX_ADDRS)/0/' src/util/debug_util.c \ sed -i -e 's/sbool/bool_repr/g' src//.c |

But stuck at 5 with no ideas what is going wrong. The error log of the compiler:

Inline function value_bytes_zero() is defined in ddc_packets.h. inline function sbool() is defined in core.h, which is explicitly included by just about every source other than those in directory util. Any chance inlining is disabled by your compiler?

I could make these functions non-inline, but I'd prefer to limit that change to Alpine Linux.  Is there a #define that always gets set?

|... make[3]: Entering directory '/ddcutil-20200211/src' CC app_ddcutil/ddcutil-main.o CC app_ddcutil/ddcutil-app_dynamic_features.o CC app_ddcutil/ddcutil-app_vcp_info.o CC app_ddcutil/ddcutil-app_dumpload.o CC app_ddcutil/ddcutil-app_setvcp.o CC app_ddcutil/ddcutil-app_getvcp.o CCLD libapp.la ar: u' modifier ignored sinceD' is the default (see U') CCLD libcommon.la ar:u' modifier ignored since D' is the default (seeU') CCLD ddcutil /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libcommon.a(ddc_vcp.o): in function ddc_get_nontable_vcp_value': ddc_vcp.c:(.text+0x1014): undefined reference tovalue_bytes_zero' /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ddc_vcp.c:(.text+0x1056): undefined reference to `value_bytes_zero' collect2: error: ld returned 1 exit status make[3]: [Makefile:885: ddcutil] Error 1 make[3]: Leaving directory '/ddcutil-20200211/src' make[2]: [Makefile:1132: all-recursive] Error 1 make[2]: Leaving directory '/ddcutil-20200211/src' make[1]: [Makefile:577: all-recursive] Error 1 make[1]: Leaving directory '/ddcutil-20200211' make: [Makefile:484: all] Error 2 |

What I'm trying to do is to add |ddcutil| to the Docker image of |hw-probe| in order to collect DDCs of all connected monitors easily like this was done for |edid-decode|: https://github.com/linuxhw/hw-probe/blob/master/Dockerfile

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3S6AZ33ZJUIM5CYTVDRCRFCBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSCRTA#issuecomment-585377996, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QGPVDQFAA4QQHRJ4LRCRFCBANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

The latest commits to branch 0.9.9-dev should address your compilation and linkage issues.

On 2/12/20 4:24 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

|0.9.1 is almost 2 years old. Numerous enhancements and bug fixes. I'd rather solve the value_bytes_zero() problem. What's your compiler/linker output? |

Full list of problems:

  1. Missed |ushort| type in |edid.h|
  2. Missed |backtrace_symbols(buffer, nptrs)| in |src/util/debug_util.c|
  3. Missed |backtrace(buffer, MAX_ADDRS)| in |src/util/debug_util.c|
  4. Missed |sbool| in |src//.c|
  5. Undefined reference to |value_bytes_zero|

I've applied a temp fix for 1-4 by |sed|:

|sed -i '1s/^/#include <sys/types.h>/' src/util/edid.h \ sed -i -e 's/backtrace_symbols(buffer, nptrs)/NULL/' src/util/debug_util.c \ sed -i -e 's/backtrace(buffer, MAX_ADDRS)/0/' src/util/debug_util.c \ sed -i -e 's/sbool/bool_repr/g' src//.c |

But stuck at 5 with no ideas what is going wrong. The error log of the compiler:

|... make[3]: Entering directory '/ddcutil-20200211/src' CC app_ddcutil/ddcutil-main.o CC app_ddcutil/ddcutil-app_dynamic_features.o CC app_ddcutil/ddcutil-app_vcp_info.o CC app_ddcutil/ddcutil-app_dumpload.o CC app_ddcutil/ddcutil-app_setvcp.o CC app_ddcutil/ddcutil-app_getvcp.o CCLD libapp.la ar: u' modifier ignored sinceD' is the default (see U') CCLD libcommon.la ar:u' modifier ignored since D' is the default (seeU') CCLD ddcutil /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libcommon.a(ddc_vcp.o): in function ddc_get_nontable_vcp_value': ddc_vcp.c:(.text+0x1014): undefined reference tovalue_bytes_zero' /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: ddc_vcp.c:(.text+0x1056): undefined reference to `value_bytes_zero' collect2: error: ld returned 1 exit status make[3]: [Makefile:885: ddcutil] Error 1 make[3]: Leaving directory '/ddcutil-20200211/src' make[2]: [Makefile:1132: all-recursive] Error 1 make[2]: Leaving directory '/ddcutil-20200211/src' make[1]: [Makefile:577: all-recursive] Error 1 make[1]: Leaving directory '/ddcutil-20200211' make: [Makefile:484: all] Error 2 |

What I'm trying to do is to add ddcutil to the Docker image of hw-probe in order to collect DDCs of all connected monitors easily like this was done for edid-decode: https://github.com/linuxhw/hw-probe/blob/master/Dockerfile

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3SP2USGRMXWTGEHATTRCRSHVA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSN55A#issuecomment-585424628, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UNPDBSAODXNKEOBATRCRSHVANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

Last build error:

Making all in .
make[3]: Entering directory '/ddcutil/src'
  CC       app_ddcutil/ddcutil-main.o
  CC       app_ddcutil/ddcutil-app_dynamic_features.o
  CC       app_ddcutil/ddcutil-app_vcp_info.o
  CC       app_ddcutil/ddcutil-app_dumpload.o
  CC       app_ddcutil/ddcutil-app_setvcp.o
  CC       app_ddcutil/ddcutil-app_getvcp.o
  CCLD     libapp.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     ddcutil
  CC       libmain/api_base.lo
In file included from libmain/api_base.c:33:
./libmain/api_base_internal.h:14:10: fatal error: sys/cdefs.h: No such file or directory
   14 | #include <sys/cdefs.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:937: libmain/api_base.lo] Error 1
make[3]: Leaving directory '/ddcutil/src'
make[2]: *** [Makefile:1133: all-recursive] Error 1
make[2]: Leaving directory '/ddcutil/src'
make[1]: *** [Makefile:578: all-recursive] Error 1
make[1]: Leaving directory '/ddcutil'
make: *** [Makefile:485: all] Error 2

/usr/include/sys/cdefs.h is provided only by bsd-compat-headers package on Alpine with a deprecation warning for sys/cdefs.h.

rockowitz commented 4 years ago

I've deleted the include of sys/cdefs.h and pushed the change to github.  It does not appear to be necessary.  If it had been, how would you have proposed dealing with this Alpine Linux deviation.

On 2/13/20 8:33 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Last build error:

|Making all in . make[3]: Entering directory '/ddcutil/src' CC app_ddcutil/ddcutil-main.o CC app_ddcutil/ddcutil-app_dynamic_features.o CC app_ddcutil/ddcutil-app_vcp_info.o CC app_ddcutil/ddcutil-app_dumpload.o CC app_ddcutil/ddcutil-app_setvcp.o CC app_ddcutil/ddcutil-app_getvcp.o CCLD libapp.la ar: u' modifier ignored sinceD' is the default (see U') CCLD libcommon.la ar:u' modifier ignored since D' is the default (seeU') CCLD ddcutil CC libmain/api_base.lo In file included from libmain/api_base.c:33: ./libmain/api_base_internal.h:14:10: fatal error: sys/cdefs.h: No such file or directory 14 | #include <sys/cdefs.h> | ^~~~~ compilation terminated. make[3]: [Makefile:937: libmain/api_base.lo] Error 1 make[3]: Leaving directory '/ddcutil/src' make[2]: [Makefile:1133: all-recursive] Error 1 make[2]: Leaving directory '/ddcutil/src' make[1]: [Makefile:578: all-recursive] Error 1 make[1]: Leaving directory '/ddcutil' make: [Makefile:485: all] Error 2 |

|/usr/include/sys/cdefs.h| is provided only by |bsd-compat-headers| package on Alpine with a deprecation warning for |sys/cdefs.h|.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3QHHRYJLGR2PKDV5N3RCVDY7A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELU6XWA#issuecomment-585755608, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SMAIHRBNLPIX3AJXTRCVDY7ANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

I've deleted the include of sys/cdefs.h and pushed the change to github. It does not appear to be necessary. If it had been, how would you have proposed dealing with this Alpine Linux deviation.

Probably not all apps are compatible with it due to different libc implementation. But it rocks when creating portable Docker apps due to extremely light weight base system.

linuxhw commented 4 years ago

@rockowitz

I've deleted the include of sys/cdefs.h and pushed the change to github. It does not appear to be necessary. If it had been, how would you have proposed dealing with this Alpine Linux deviation.

Seems that this include was necessary for __THROW in api_base_internal.h. I see a bunch of related build errors currently.

linuxhw commented 4 years ago

@rockowitz

I've deleted the include of sys/cdefs.h and pushed the change to github. It does not appear to be necessary. If it had been, how would you have proposed dealing with this Alpine Linux deviation.

Could you please revert this change? I'll try to use bsd-compat-headers to get sys/cdefs.h as a temp solution.

Thanks.

linuxhw commented 4 years ago

@rockowitz

Please look: https://wiki.musl-libc.org/faq.html#Q:-When-compiling-something-against-musl,-I-get-error-messages-about-%3Ccode%3Esys/cdefs.h%3C/code%3E

rockowitz commented 4 years ago

Builds cleanly for me.  Likely because sys/types.h is pulled in indirectly.   A quick scan of /usr/include show's it's actually hard to avoid.  Alpine Linux must surely already have a way to deal with this.

On 2/13/20 2:01 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I've deleted the include of sys/cdefs.h and pushed the change to
github. It does not appear to be necessary. If it had been, how
would you have proposed dealing with this Alpine Linux deviation.

Seems that this include was necessary for |__THROW| in |api_base_internal.h|. I see a bunch of related build errors currently.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3RLXCLPLUFUC6NVHP3RCWKJBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWG22Q#issuecomment-585919850, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SGYYMFXRFN7T7CGZTRCWKJBANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

Ignore the prior message re sys/types.h, not sys/cdef.h.  I need to take care of some things before the snowstorm hits.  I'll look at this later.

On 2/13/20 2:47 PM, Sanford Rockowitz wrote:

Builds cleanly for me.  Likely because sys/types.h is pulled in indirectly.   A quick scan of /usr/include show's it's actually hard to avoid.  Alpine Linux must surely already have a way to deal with this.

On 2/13/20 2:01 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

I've deleted the include of sys/cdefs.h and pushed the change to
github. It does not appear to be necessary. If it had been, how
would you have proposed dealing with this Alpine Linux deviation.

Seems that this include was necessary for |__THROW| in |api_base_internal.h|. I see a bunch of related build errors currently.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3RLXCLPLUFUC6NVHP3RCWKJBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWG22Q#issuecomment-585919850, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SGYYMFXRFN7T7CGZTRCWKJBANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

I have modified files api_base_internal.h and api_base.c to, insofar as I can tell, not depend on cdefs.h by replacing the __THROW macro with the C code it would expand to in the current context. Let me know if this works for you.  If it does, cleanup will follow.

On 2/13/20 2:17 PM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Please look: https://wiki.musl-libc.org/faq.html#Q:-When-compiling-something-against-musl,-I-get-error-messages-about-%3Ccode%3Esys/cdefs.h%3C/code%3E

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3UH7TNP2JZ5MB2KXUTRCWMF3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWIRBI#issuecomment-585926789, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3TBOE4Q4GJRLJVFN3DRCWMF3ANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

I have modified files api_base_internal.h and api_base.c to, insofar as I can tell, not depend on cdefs.h by replacing the __THROW macro with the C code it would expand to in the current context. Let me know if this works for you. If it does, cleanup will follow.

Build succeeded on 9f320. Thanks a lot!

Started build of d378f.

linuxhw commented 4 years ago

@rockowitz

I have modified files api_base_internal.h and api_base.c to, insofar as I can tell, not depend on cdefs.h by replacing the __THROW macro with the C code it would expand to in the current context. Let me know if this works for you. If it does, cleanup will follow.

Build succeeded on 9f320. Thanks a lot!

Started build of d378f.

Build succeeded on d378f.

linuxhw commented 4 years ago

Built 1.5-ddc tag of https://hub.docker.com/r/linuxhw/hw-probe for testing purposes:

xhost +local:
sudo docker run -it -v /dev:/dev:ro -v /lib/modules:/lib/modules:ro -v /etc/os-release:/etc/os-release:ro -v /var/log:/var/log:ro --privileged --net=host --pid=host linuxhw/hw-probe:1.5-ddc -all -upload -enable ddc

Also AppImage is ready: https://github.com/linuxhw/hw-probe/releases/download/1.5/hw-probe-1.5-162-x86_64.AppImage

chmod +x ./hw-probe-1.5-162-x86_64.AppImage
sudo ./hw-probe-1.5-162-x86_64.AppImage -all -upload -enable ddc

I'll test them when I access my desktop on Monday.

linuxhw commented 4 years ago

@rockowitz

Got first probe of Dell P2414H by Docker image: https://linux-hardware.org/?probe=546f54f7e3&log=ddcutil

But it takes about 40 seconds to ddcutil probe --bus 6 on my desktop. Is it possible to speed up somehow? Where is the bottleneck?

I want to enable this probe by default to create large database of DDC probes, but execution time should be limited to 5 sec max per monitor.

Thanks.

linuxhw commented 4 years ago

@rockowitz

Tried to run on another desktop, but ddcutil can't find a monitor (DELL via HDMI on Fedora 31 X11): https://github.com/rockowitz/ddcutil/issues/106

linuxhw commented 4 years ago

@rockowitz

Tried to run on another desktop, but ddcutil can't find a monitor (DELL via HDMI on Fedora 31 X11): rockowitz/ddcutil#106

Fixed by xhost +local:

linuxhw commented 4 years ago

Second probe (DELL U2417H): https://linux-hardware.org/?probe=9e951ac165&log=ddcutil

rockowitz commented 4 years ago

Unfortunately the long execution time is a consequence of the DDC protocol spec, which mandates that the host wait 50-200 ms after writing a command to the display before requesting a reply.  This is compounded for displays with marginal I2C implementations that require retries.  ddcutil spends approximately 90% of its time in sleeps mandated by the DDC protocol. Take a look at the output produced by the --stats option, which reports both the time spent sleeping and the number of I2C retries required.

The sleep time can be adjusted using the -- sleep-multiplier option, which takes a floating point number as an argument. Values < 1 reduce the sleep times from those in the spec, values > 1 increase it.   For example, the Dell U3011 in front of me works reliably with a sleep-multiplier of .1!  On the other hand, communication with the Dell P2411h in my multi-monitor setup requires a sleep-multiplier in the 2-4 range for reliable operation.  (I keep it in the testing mix precisely because its DDC implementation is so marginal.) You might improve performance overall by defaulting to a low sleep-multiplier value, then retrying with successively greater values in case of failure.

It is conceivable that the sleep-multiplier could be dynamically adjusted for long running commands,  increasing or decreasing depending on error rates. But that, as they say, is a project, and I'm not sure how much performance would be achieved overall.

--Sanford

On 2/17/20 4:11 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Got first probe of Dell P2414H by Docker image: https://linux-hardware.org/?probe=546f54f7e3&log=ddcutil

But it takes about 40 seconds to |ddcutil probe --bus 6| on my desktop. Is it possible to speed up somehow? Where is the bottleneck?

I want to enable this probe by default to create large database of |DDC| probes, but execution time should be limited to 5 sec max per monitor.

Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3QKRVCHN4G3HZH4YFDRDJIDBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL5TVKY#issuecomment-586889899, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VGHSFOZRDZEBODIR3RDJIDBANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

I've made some experimental changes to reduce execution time. The changes have been pushed to branch 0.9.9-dev.  One that appears to not introduce errors, but needs much more testing, eliminates certain types of sleep events.  For now, it is enabled using undocumented option "--f1".  Give it a try.

On 2/17/20 4:11 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Got first probe of Dell P2414H by Docker image: https://linux-hardware.org/?probe=546f54f7e3&log=ddcutil

But it takes about 40 seconds to |ddcutil probe --bus 6| on my desktop. Is it possible to speed up somehow? Where is the bottleneck?

I want to enable this probe by default to create large database of |DDC| probes, but execution time should be limited to 5 sec max per monitor.

Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3QKRVCHN4G3HZH4YFDRDJIDBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL5TVKY#issuecomment-586889899, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VGHSFOZRDZEBODIR3RDJIDBANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

@rockowitz

The sleep time can be adjusted using the -- sleep-multiplier option

sudo ddcutil probe --bus 6
# Takes 37.4s

sudo ddcutil probe --bus 6 --sleep-multiplier 0.1 | grep -v "DDC Null Response"
# Takes 15.0s

Output is not changed.

Is there an option to hide ddc_write_read() succeeded after N sleep and retry ... and Extended delay as recovery ... messages?

linuxhw commented 4 years ago

@rockowitz

I've made some experimental changes to reduce execution time. The changes have been pushed to branch 0.9.9-dev. One that appears to not introduce errors, but needs much more testing, eliminates certain types of sleep events. For now, it is enabled using undocumented option "--f1". Give it a try.

sudo ddcutil-prev probe --bus 6
# Takes 37.4s

sudo ddcutil-now probe --f1 --bus 6
# Takes 20.8s

sudo ddcutil-now probe --bus 6 --f1 --sleep-multiplier 0.1
# Takes 16.8s

Output is not changed. Added set_error_stats_sleep_multiplier_factor value to the output.

Thanks!

linuxhw commented 4 years ago

@rockowitz

Does the best sleep-multiplier value depend on cpu or monitor itself?

I got best performance on sleep-multiplier=0.2 on Dell P2414H:

sudo ddcutil-now probe --bus 6 --f1 --sleep-multiplier 0.2
# Takes 8.5s

The --f1 option rocks.

rockowitz commented 4 years ago

All normal sleep times, i.e. as specified by the DDC spec, are multiplied by the --sleep-multiplier value.  So a normal 50 ms wait before querying a response from the monitor becomes 10 ms.  Success depends on the monitor only in the sense that some monitors can compose responses in the reduced time, some cannot.   --sleep-multiplier is useful when targeting a specific monitor whose delay sensitivity is known.  Applied to an arbitrary monitor, a given --sleep-multiplier may work, or it may not.

On 2/18/20 1:11 AM, Linux Hardware Project wrote:

@rockowitz https://github.com/rockowitz

Does the best |sleep-multiplier| value depend on cpu or monitor itself?

I got best performance on |sleep-multiplier=0.2| on Dell P2414H:

|sudo ddcutil-now probe --bus 6 --f1 --sleep-multiplier 0.2 # Takes 8.5s |

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3UYQQ6KUK443WXCLWDRDN325A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAW3PI#issuecomment-587296189, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QDYPMMLESCRCG5ZDLRDN325ANCNFSM4KML3ZPQ.

rockowitz commented 4 years ago

On 2/18/20 12:53 AM, Linux Hardware Project wrote:

The sleep time can be adjusted using the -- sleep-multiplier option

|sudo ddcutil probe --bus 6 # Takes 37.4s sudo ddcutil probe --bus 6 --sleep-multiplier 0.1 | grep -v "DDC Null Response" # Takes 15.0s |

Output is not changed.

Is there an option to hide |ddc_write_read() succeeded after N sleep and retry ...| and |Extended delay as recovery ...| messages?

This debugging message is presently always on so that use of specialized recovery code for handling the DDC Null Message is apparent.  It will be disabled before release 0.9.9 is published.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3VJOBBCSERX3U5BOCLRDNZWJA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAVTMI#issuecomment-587291057, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QKVCUD3K3344E34X3RDNZWJANCNFSM4KML3ZPQ.

linuxhw commented 4 years ago

I've made some experimental changes to reduce execution time. The changes have been pushed to branch 0.9.9-dev. One that appears to not introduce errors, but needs much more testing, eliminates certain types of sleep events. For now, it is enabled using undocumented option "--f1". Give it a try.

Can I use --f1 in production? Will it be renamed in future?

rockowitz commented 4 years ago

On 2/18/20 11:19 PM, Linux Hardware Project wrote:

I've made some experimental changes to reduce execution time. The
changes have been pushed to branch 0.9.9-dev. One that appears to
not introduce errors, but needs much more testing, eliminates
certain types of sleep events. For now, it is enabled using
undocumented option "--f1". Give it a try.

Can I use |--f1| in production? Will it be renamed in future?

Options named --f1, --i1 etc. are undocumented and intended testing purposes.  Their meaning can change at any time.   If the changes are determined not to introduce errors they will simply become part of normal execution.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3U2UJAGRHH5QWFZHIDRDSXNRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMGJM5I#issuecomment-588027509, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XGHTES7WTBVGZ7GMLRDSXNRANCNFSM4KML3ZPQ.

pabs3 commented 4 years ago

I wonder if making hw-probe run multiple processes in the background and aggregating their output would mitigate this issue by having the tool runtime be parallel instead of serial.

linuxhw commented 4 years ago

I wonder if making hw-probe run multiple processes in the background and aggregating their output would mitigate this issue by having the tool runtime be parallel instead of serial.

@rockowitz

Can a monitor handle multiple ddc requests in parallel?

rockowitz commented 4 years ago

On 2/22/20 2:41 PM, Linux Hardware Project wrote:

I wonder if making hw-probe run multiple processes in the
background and aggregating their output would mitigate this issue
by having the tool runtime be parallel instead of serial.

You should be able to run multiple copies of ddcutil in parallel, so long as each accesses only a single I2C device, i.e. uses the --bus option.

It is possible to access multiple displays simultaneously using a single copy of the shared library, with a separate thread for each display.   This is what ddcui does.

@rockowitz https://github.com/rockowitz

Can a monitor handle multiple ddc requests in parallel?

No.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/linuxhw/hw-probe/issues/49?email_source=notifications&email_token=ADMGY3VJSL72BTIJDDCHJ7TREF5V3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVI22I#issuecomment-589991273, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3Q3YHGELHFRKCPS3ULREF5V3ANCNFSM4KML3ZPQ.

pabs3 commented 4 years ago

To be clear, I meant running ddcutil in parallel with other tools for hardware info extraction, but I agree that running ddcutil itself in parallel would be nice.