add support for reporting external monitor info using ddcutil #49
Comments
|
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
<#49?email_source=notifications&email_token=ADMGY3WLR2GMXCOZ53GOZB3Q76SH3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJDKYBA>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3S5TYG4CDEPBTWKWCTQ76SH3ANCNFSM4KML3ZPQ>.
|
|
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. |
|
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
<#49?email_source=notifications&email_token=ADMGY3STVLAPIRMAANJT6MTRCGXVRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKCHTA#issuecomment-584328140>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3XXGJ5UIO4F3VAJNWLRCGXVRANCNFSM4KML3ZPQ>.
|
|
I need to detect i2c bus numbers where physical monitors are connected. And then run Something like: On my computer N=2. I need to detect this exact number quickly or somehow reduce the range 0..31. |
|
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
<#49?email_source=notifications&email_token=ADMGY3RHEQFCZUJHTTOMUITRCJJKRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLPAXY#issuecomment-584511583>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RXGOYNCYNWEL7TGLTRCJJKRANCNFSM4KML3ZPQ>.
|
|
Fixed by f96fd2f. But still need to optimize this and test properly. I have no desktop nearby until Monday (notebooks are not supported). |
|
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
> <#49?email_source=notifications&email_token=ADMGY3RHEQFCZUJHTTOMUITRCJJKRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLPAXY#issuecomment-584511583>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADMGY3RXGOYNCYNWEL7TGLTRCJJKRANCNFSM4KML3ZPQ>.
>
|
|
Could you please attach sample output of Thanks. |
|
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
<#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
|
|
I'd like to add Thanks. |
|
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
<#49?email_source=notifications&email_token=ADMGY3UTHQXDGKD34OZRFILRCL54TA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNZQRY#issuecomment-584816711>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3UTYSJW5PAFL5VCAXLRCL54TANCNFSM4KML3ZPQ>.
|
|
BTW Tried to add Is it possible to include this patch to upstream? |
|
I've tried to build latest 0.9.9 in Alpine 3.11, but failed to link final binary (something is bad with |
|
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
<#49?email_source=notifications&email_token=ADMGY3T5W5F5QBN7Y4QVLUTRCP6M3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQ3VOY#issuecomment-585218747>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3WCCC7IHHZU7GO76OLRCP6M3ANCNFSM4KML3ZPQ>.
|
|
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
<#49?email_source=notifications&email_token=ADMGY3XVIEHMPCD5HSGDZSLRCQOXTA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRMMTI#issuecomment-585287245>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VHGT6OCCPUTP744ADRCQOXTANCNFSM4KML3ZPQ>.
|
|
|
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
<#49?email_source=notifications&email_token=ADMGY3TSHKYBXCCTX3E6OZTRCRCYTA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSAOZY#issuecomment-585369447>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3TVFUC2PGCGMABEAPLRCRCYTANCNFSM4KML3ZPQ>.
|
Full list of problems:
I've applied a temp fix for 1-4 by But stuck at 5 with no ideas what is going wrong. The error log of the compiler: 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 |
|
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 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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49?email_source=notifications&email_token=ADMGY3S6AZ33ZJUIM5CYTVDRCRFCBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSCRTA#issuecomment-585377996>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3QGPVDQFAA4QQHRJ4LRCRFCBANCNFSM4KML3ZPQ>.
|
|
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 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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49?email_source=notifications&email_token=ADMGY3SP2USGRMXWTGEHATTRCRSHVA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSN55A#issuecomment-585424628>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3UNPDBSAODXNKEOBATRCRSHVANCNFSM4KML3ZPQ>.
|
|
Last build error:
|
|
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 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|.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49?email_source=notifications&email_token=ADMGY3QHHRYJLGR2PKDV5N3RCVDY7A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELU6XWA#issuecomment-585755608>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SMAIHRBNLPIX3AJXTRCVDY7ANCNFSM4KML3ZPQ>.
|
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. |
Seems that this include was necessary for |
Could you please revert this change? I'll try to use Thanks. |
|
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
<#49?email_source=notifications&email_token=ADMGY3RLXCLPLUFUC6NVHP3RCWKJBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWG22Q#issuecomment-585919850>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SGYYMFXRFN7T7CGZTRCWKJBANCNFSM4KML3ZPQ>.
|
|
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
> <#49?email_source=notifications&email_token=ADMGY3RLXCLPLUFUC6NVHP3RCWKJBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWG22Q#issuecomment-585919850>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADMGY3SGYYMFXRFN7T7CGZTRCWKJBANCNFSM4KML3ZPQ>.
>
|
|
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
<#49?email_source=notifications&email_token=ADMGY3UH7TNP2JZ5MB2KXUTRCWMF3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWIRBI#issuecomment-585926789>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3TBOE4Q4GJRLJVFN3DRCWMF3ANCNFSM4KML3ZPQ>.
|
Build succeeded on 9f320. Thanks a lot! Started build of d378f. |
Build succeeded on d378f. |
|
Built Also AppImage is ready: https://github.com/linuxhw/hw-probe/releases/download/1.5/hw-probe-1.5-162-x86_64.AppImage I'll test them when I access my desktop on Monday. |
|
Got first probe of Dell P2414H by Docker image: https://linux-hardware.org/?probe=546f54f7e3&log=ddcutil But it takes about 40 seconds to I want to enable this probe by default to create large database of Thanks. |
|
Tried to run on another desktop, but |
Fixed by |
|
Second probe (DELL U2417H): https://linux-hardware.org/?probe=9e951ac165&log=ddcutil |
|
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
<#49?email_source=notifications&email_token=ADMGY3QKRVCHN4G3HZH4YFDRDJIDBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL5TVKY#issuecomment-586889899>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VGHSFOZRDZEBODIR3RDJIDBANCNFSM4KML3ZPQ>.
|
|
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
<#49?email_source=notifications&email_token=ADMGY3QKRVCHN4G3HZH4YFDRDJIDBA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL5TVKY#issuecomment-586889899>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VGHSFOZRDZEBODIR3RDJIDBANCNFSM4KML3ZPQ>.
|
Output is not changed. Is there an option to hide |
Output is not changed. Added Thanks! |
|
Does the best I got best performance on The |
|
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
<#49?email_source=notifications&email_token=ADMGY3UYQQ6KUK443WXCLWDRDN325A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAW3PI#issuecomment-587296189>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3QDYPMMLESCRCG5ZDLRDN325ANCNFSM4KML3ZPQ>.
|
|
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
<#49?email_source=notifications&email_token=ADMGY3VJOBBCSERX3U5BOCLRDNZWJA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAVTMI#issuecomment-587291057>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3QKVCUD3K3344E34X3RDNZWJANCNFSM4KML3ZPQ>.
|
Can I use |
|
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
<#49?email_source=notifications&email_token=ADMGY3U2UJAGRHH5QWFZHIDRDSXNRA5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMGJM5I#issuecomment-588027509>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3XGHTES7WTBVGZ7GMLRDSXNRANCNFSM4KML3ZPQ>.
|
|
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.
|
Can a monitor handle multiple ddc requests in parallel? |
|
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
<#49?email_source=notifications&email_token=ADMGY3VJSL72BTIJDDCHJ7TREF5V3A5CNFSM4KML3ZP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVI22I#issuecomment-589991273>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3Q3YHGELHFRKCPS3ULREF5V3ANCNFSM4KML3ZPQ>.
|
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: