Display not found with LG UltraFine 27MD5KL #123
Labels
Comments
|
I've just retried it without the dock (with the monitor directly in the laptop's Thunderbolt port), but results were almost identical; no display found. |
|
Andre,
You have, as they say, an interesting problem.
First, using ddcutil as the name for what the program has become is a
bit of a misnomer. Originally the Monitor Control Class Spec simply
defined the contents of the messages carried by I2C. Then in a bit of
jujitsu, a spec was defined for communicating MCCS over USB. Originally
designed for DDC/CI, the ability to communicate MCCS over USB instead of
I2C was added a couple years . So ddcutil might better be named
mccsutil, but that would be even more confusing.
What usbenv is saying is that the monitor identifies itself on the USB
bus as supporting the USB Monitor Control Class Specification, as a
particular type of USB Human Interface Device (HID). That is, it claims
to implement a set of USB "reports" that carry MCCS related commands.
When ddcutil detect tries to use those reports, it doesn't work. The
other commands (getvcp, probe, etc.) start out performing the detection
reported by the detect command. So if detect doesn't find any monitors
supporting MCCS, neither will the other commands.
While I2C is carried over a specified set of wires in VGA, DVI, and HDMI
cables, for DisplayPort I2C communication is emulated over the AUX
channel. Unfortunately, the i915 driver does not implement the I2C
communication for recent docking stations (which use DisplayPort Multi
Stream Protocol, aka MST). It may be that the I2C over Aux emulation
has been extended to Thunderbolt, and we're simply seeing a limitation
of the i915 driver. If you can, one thing to try is to bypass the dock
and plug directly into the laptop, using a type C connector if that
exists on the laptop or a DisplayPort to Thunderbolt converter cable.
Please run the commands "ddcutil environment --verbose" and "ddcutil
usbenvironment --verbose" as root and send the output as attachments
(i.e. not inline). I may be able to say more with that.
Regards,
Sanford
bit of background. To not go too far back, DDC/CI defines how to
communicate with a monitor, incorporating and extending I2C. By
analogy, I think of DDC/CI as a subclass of the I2C superclass. The Once
upon a time, Phillips developed the I2C hardware bus, a simple 2 wire
interface. I2C defines the physical communication. The Access.Bus
protocol defined how I2C could
…On 5/26/20 10:54 PM, andrejpodzimek wrote:
While the 5k resolution works fine and looks awesome (thanks to this
latest fix
<https://gitlab.freedesktop.org/drm/intel/-/issues/27#note_510258>), I
haven't found a way to make backlight controls work. I tried lots of
combinations, both as |root| and as a regular user:
ddcutil getvcp 10 --hiddev 3
ddcutil getvcp 10 --usb 7.5
ddcutil probe --hiddev 3
ddcutil probe --usb 7.5
ddcutil detect
ddcutil usbenv# <<< This does something!
I always get /No displays found/ from |detect| and /Display not found/
from the (more) monitor-specific commands. Only |ddcutil usbenv| seems
to identify the monitor somehow:
|Device /dev/usb/hiddev3, devnum.busnum: 7.5, vid:pid: 043e:9a70 - LG
Electronics Inc. LG UltraFine Display Controls Identifies as a USB HID
monitor |
Initially I tried a few LG-specific brightness control tools, but they
didn't work for me
<velum/lguf-brightness#8>, likely because
they assume i2c over DisplayPort or the like, whereas this monitor is
Thunderbolt-only and may not have an i2c bus relayed through
Thunderbolt. I do have |i2c_hid| loaded, but no i2c devices pop up in
|/dev|.
Full |ddcutil usbenv| output
* *when run as root
<https://github.com/rockowitz/ddcutil/files/4686119/ddcutil_usbenv_root.txt>*
* *when run as a regular user
<https://github.com/rockowitz/ddcutil/files/4686120/ddcutil_usbenv_user.txt>*
In particular, this piece of data looks like “something
backlight-related”:
|/sys/kernel/debug/hid/0003:043E:9A70.0014/rdesc: 05 80 09 01 a1 01 06
82 00 09 10 15 04 26 1c 02 67 e1 00 00 01 55 0e 75 20 95 01 b1 42 06
82 00 09 10 67 e1 00 00 01 55 0e 75 20 95 01 81 02 05 0f 09 50 15 00
26 20 4e 66 10 01 55 0d 75 10 95 01 b1 42 c0 INPUT[INPUT] Field(0)
Application(0080.0001) Usage(1) 0082.0010 Logical Minimum(4) Logical
Maximum(540) Unit Exponent(-2) Unit(SI Linear : Centimeter^-2*Candela)
Report Size(32) Report Count(1) Report Offset(0) Flags( Variable
Absolute ) FEATURE[FEATURE] Field(0) Application(0080.0001) Usage(1)
0082.0010 Logical Minimum(4) Logical Maximum(540) Unit Exponent(-2)
Unit(SI Linear : Centimeter^-2*Candela) Report Size(32) Report
Count(1) Report Offset(0) Flags( Variable Absolute NullState )
Field(1) Application(0080.0001) Usage(1) PhysicalInterfaceDevice.0050
Logical Minimum(0) Logical Maximum(20000) Unit Exponent(-3) Unit(None
: None*None) Report Size(16) Report Count(1) Report Offset(32) Flags(
Variable Absolute NullState ) 0082.0010 ---> Sync.Report |
System configuration
* Lenovo X1 Carbon Generation 7 (with a Core i7-8665U and a 4k display)
* LG UltraFine 27MD5KL (5k monitor)
* Lenovo Thunderbolt dock
<https://www.lenovo.com/us/en/accessories-and-monitors/home-office/Thunderbolt-Dock-Gen-2-US/p/40AN0135US>
(with the laptop on the host-side Thunderbolt port and the monitor
on the peripheral-side Thunderbolt port)
* Kernel: 5.7.0-rc6 with three fixes (Port sync for skl+
<https://patchwork.freedesktop.org/series/74691/>, Fix off-by-one
in DispID DTD pixel clock
<https://patchwork.freedesktop.org/series/76398/> and EDID DispId
fix <https://github.com/vsyrjala/linux/tree/edid_multi_dispid_ext>)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#123>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3WAMPRKP225YGIDOEDRTR6F7ANCNFSM4NLUIYOA>.
|
|
Alright, here's a workaround. Brightness can be controlled using this tool, loosely based on acdcontrol: // This code has been shamelessly extracted from acdcontrol:
// https://www.dionysopoulos.me/apple-display-brightness-controls-in-ubuntu-desktop/
# define _POSIX_C_SOURCE 200809L
#include <fcntl.h>
#include <inttypes.h>
#include <linux/hiddev.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
static const uint32_t USAGE_CODE = 0x820010; // Magic!
static const size_t MAX_INT32_DIGITS = 10;
static const char HID_DEVICE[] = "/dev/usb/hiddev";
int main(int argc, const char* const* argv) {
if (argc != 3) {
if (argc)
dprintf(STDERR_FILENO, "Usage: %s <HID device> <brightness>\n", argv[0]);
return EXIT_FAILURE;
}
bool error = false;
char *endptr;
const uint32_t device = strtoul(argv[1], &endptr, 10);
if (!argv[1] || *endptr) {
dprintf(STDERR_FILENO, "Malformed device number '%s'\n", argv[1]);
error = true;
}
char device_name[sizeof(HID_DEVICE) + MAX_INT32_DIGITS];
sprintf(device_name, "%s%" PRIu32, HID_DEVICE, device);
const int32_t brightness = strtoul(argv[2], &endptr, 10);
if (!argv[2] || *endptr) {
dprintf(STDERR_FILENO, "Malformed brightness value '%s'\n", argv[2]);
error = true;
}
if (error) return EXIT_FAILURE;
const int fd = open(device_name, O_RDWR);
if (fd < 0) {
perror("HID open() failed");
return EXIT_FAILURE;
}
const struct hiddev_usage_ref usage_ref = {
.report_type = HID_REPORT_TYPE_FEATURE,
.report_id = HID_REPORT_ID_FIRST, // This is for LG; Apple may use 16
.field_index = 0,
.usage_index = 0,
.usage_code = USAGE_CODE,
.value = brightness, // For LG 27MD5KL, this is 400 to 54000.
};
if (ioctl(fd, HIDIOCSUSAGE, &usage_ref) < 0) {
perror("HIDIOCSUSAGE failed");
return EXIT_FAILURE;
}
const struct hiddev_report_info report_info = {
.report_type = HID_REPORT_TYPE_FEATURE,
.report_id = HID_REPORT_ID_FIRST, // This is for LG; Apple may use 16
.num_fields = 1,
};
if (ioctl(fd, HIDIOCSREPORT, &report_info) < 0) {
perror("HIDIOCSREPORT failed");
return EXIT_FAILURE;
}
if (close(fd) < 0) {
perror("HID close() failed");
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}Example for clang -std=c11 -Wall -Wextra -pedantic -march=native -O3 brightness.c -o brightness
./brightness 3 400 # minimum
./brightness 3 54000 # maximum
./brightness 3 36000 # my usual choice |
|
@rockowitz Here's the output:
The C example above shows what |
|
ddcutil's USB connected monitor support is based on usbcntrl, which in
turn derived from acdcontrol. (See
https://www.ddcutil.com/acknowledgements/). I have an old Apple 23"
Cinema display here that I test with. Interestingly, its USB interface
implements only VCP feature x10 (brightness) IIRC, but its I2C interface
implements a larger set of feature codes.
A cursory look at acdcontrol.cpp shows it is indeed using the USB
Monitor Control Class Specification.
Bottom line: ddcutil should work. It's probably a configuration issue.
Try running: "ddcutil chkusbmon /dev/usb/hiddevN" where N is
appropriate. chkusbmon, as described in https://www.ddcutil.com/usb/ is
a simplified check created for use in UDEV rules. Run it as root to
take permission issues.
I'll review your environment and usbenvironment output to see what more
can be gleaned. The assertion failure that terminates usbenvironment
execution indicates my utility package hit something that it didn't
regard as legal or at least as expected based on the USB spec. I'll
look into this as well.
Sanford
…On 5/27/20 2:05 AM, andrejpodzimek wrote:
Alright, here's a workaround. Brightness can be controlled using this
tool, loosely based on acdcontrol
<https://www.dionysopoulos.me/apple-display-brightness-controls-in-ubuntu-desktop/>:
// This code has been shamelessly extracted from acdcontrol:
//
https://www.dionysopoulos.me/apple-display-brightness-controls-in-ubuntu-desktop/
#define _POSIX_C_SOURCE 200809L
#include <fcntl.h>
#include <inttypes.h>
#include <linux/hiddev.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
static const uint32_t USAGE_CODE =0x820010;// Magic!
static const size_t MAX_INT32_DIGITS =10;
static const char HID_DEVICE[] ="/dev/usb/hiddev";
int main(int argc,const char*const* argv) {
if (argc !=3) {
if (argc)
dprintf(STDERR_FILENO,"Usage: %s <HID device> <brightness>\n", argv[0]);
return EXIT_FAILURE;
}
bool error =false;
char *endptr;
const uint32_t device =strtoul(argv[1], &endptr,10);
if (!argv[1] || *endptr) {
dprintf(STDERR_FILENO,"Malformed device number '%s'\n", argv[1]);
error =true;
}
char device_name[sizeof(HID_DEVICE) + MAX_INT32_DIGITS];
sprintf(device_name,"%s%" PRIu32, HID_DEVICE, device);
const int32_t brightness =strtoul(argv[2], &endptr,10);
if (!argv[2] || *endptr) {
dprintf(STDERR_FILENO,"Malformed brightness value '%s'\n", argv[2]);
error =true;
}
if (error)return EXIT_FAILURE;
const int fd =open(device_name, O_RDWR);
if (fd <0) {
perror("HID open() failed");
return EXIT_FAILURE;
}
const struct hiddev_usage_ref usage_ref = {
.report_type = HID_REPORT_TYPE_FEATURE,
.report_id = HID_REPORT_ID_FIRST,// This is for LG; Apple may use 16
.field_index =0,
.usage_index =0,
.usage_code = USAGE_CODE,
.value = brightness,// For LG 27MD5KL, this is 400 to 54000.
};
if (ioctl(fd, HIDIOCSUSAGE, &usage_ref) <0) {
perror("HIDIOCSUSAGE failed");
return EXIT_FAILURE;
}
const struct hiddev_report_info report_info = {
.report_type = HID_REPORT_TYPE_FEATURE,
.report_id = HID_REPORT_ID_FIRST,// This is for LG; Apple may use 16
.num_fields =1,
};
if (ioctl(fd, HIDIOCSREPORT, &report_info) <0) {
perror("HIDIOCSREPORT failed");
return EXIT_FAILURE;
}
if (close(fd) <0) {
perror("HID close() failed");
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
Example for |/dev/usb/hiddev3|:
clang -std=c11 -Wall -Wextra -pedantic -march=native -O3 brightness.c -o brightness
./brightness 3 400# minimum
./brightness 3 54000# maximum
./brightness 3 36000# my usual choice
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SK7M6K65TSFSGO6BDRTSUQ5ANCNFSM4NLUIYOA>.
|
|
Re the environment command:
Your logs are full of drm errors in the i915 driver.
I2C devices exist in the /sys tree, but are not instantiated as /dev/i2c
devices. See the Device Identifier Cross Reference Report and
Configuration Suggestions at the end of the output. The i2c-dev driver
is not loaded. It is required to create the /dev/i2c devices.
The double entries (i2c-6 and i2c-7) is an anomaly sometimes seen with
DisplayPort monitors. Only one will actually support DDC communication.
…On 5/27/20 2:14 AM, andrejpodzimek wrote:
@rockowitz <https://github.com/rockowitz> Here's the output:
* |ddcutil environment --verbose|
<https://github.com/rockowitz/ddcutil/files/4686767/ddcutil_environment_verbose.txt>
(This terminates successfully.)
* |ddcutil usbenvironment --verbose|
<https://github.com/rockowitz/ddcutil/files/4686770/ddcutil_usbenvironment_verbose.txt>
(This dies with a |SIGABRT|.)
The C example above
<#123 (comment)>
shows what |ioctl()| commands work for brightness on this monitor. (I
haven't tried to figure out what that other |FEATURE| (and also the
|INPUT|) means.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RBH66FQWXMIVBZUF3RTSVUVANCNFSM4NLUIYOA>.
|
|
Oh, now I see that all of this has been just my mistake + ignorance. I had Brightness control works ( Thanks a lot for looking into this and sorry for all the noise. |
|
I'm glad that ddcutil is now working for you. However, there are some
odd things about your configuration that I'm hoping you'll help me explore.
- Two /i2c-dev devices for the same monitor. I've seen this for
DisplayPort devices. Normally, DDC works only over one of the /dev/i2c
devices, and detection should filter out the crippled duplicate.
Apparently that is not happening in your case.
- Have you hacked the EDID so that identical monitors have the same
serial number?
- Querying VCP feature xDF VCP Version fails. Per the MCCS spec, this
feature must be implemented (at least as of version 2.0, which was
released years ago) .
- The monitor looks like it should support the USB Monitor Control Class
spec, but detection doesn't find it.
- The assert failure that terminated "ddcutil usbenvironment --verbose"
appears to be because the of input that violates a spec related to DDC
handling. I have replaced the assert with code that attempts to recover
from the situation.
Additionally, as you've found, the i2c_hid driver is a red herring.
Some hardware devices, such as touchpads, have an I2C hardware
interface. The i2c_hid driver provides a serial bus like interface to
those devices. It is unrelated to the use of I2C in DDC/CI.
The ddcutil 0.9.9-dev branch on github contains the change to avoid the
assert failure.
Please run the following commands (n.b. as root) and send the output as
attachments:
$sudo ddcutil interrogate
$sudo ddcutil usbenvironment
and, if have built from the latest 0.9.9-dev branch, also
$sudo ddcutil usbenvironment --verbose
Thank you.
Sanford
…On 5/28/20 5:23 AM, andrejpodzimek wrote:
Oh, now I see that all of this has been just my mistake + ignorance. I
had |i2c_hid| loaded and thought that was all (and no i2c devices
showed up). In fact what I should have had was *|i2c_dev|*, but I
didn’t have it due to a strange glitch. (I'm jusing a |-rc| kernel to
get 5k working on this monitor (with |i915|) and |i2c_dev| just didn’t
load.) After some trial and error (and |i2c_dev| at last), I got this:
|# ddcutil detect Invalid display I2C bus: /dev/i2c-5 EDID synopsis:
Mfg id: BOE Model: Serial number: Manufacture year: 2018 EDID version:
1.4 DDC communication failed This is an eDP laptop display. Laptop
displays do not support DDC/CI. Display 1 I2C bus: /dev/i2c-6 EDID
synopsis: Mfg id: GSM Model: LG UltraFine Serial number: 003NTTQ58945
Manufacture year: 2020 EDID version: 1.4 VCP version: Detection failed
Display 2 I2C bus: /dev/i2c-7 EDID synopsis: Mfg id: GSM Model: LG
UltraFine Serial number: 003NTTQ58945 Manufacture year: 2020 EDID
version: 1.4 VCP version: Detection failed |
Brightness control *works* (|setvcp 10 ...|) for both |--display 1|
and |--display 2|.
Thanks a lot for looking into this and sorry for all the noise.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3W2UAJCNZ6HI3LKSMTRTYUS3ANCNFSM4NLUIYOA>.
|
Well, at least brightness can be set using any of the two devices. It takes effect over the entire monitor, presumably; the backlight (fortunately) doesn't have two tiles.
Nope, the monitor is in a pristine factory state and I didn't attempt to override the EDID in software anywhere else.
That's weird. Well, at least the HID trick above still works for brightness. (Not sure what the other
|
|
Thank you for running the tests. The current 0.9.9-dev branch contains
several changes based on your reports. See comments at end.
On 5/29/20 5:17 PM, andrejpodzimek wrote:
* Two /i2c-dev devices for the same monitor. I've seen this for
DisplayPort devices. Normally, DDC works only over one of the
/dev/i2c
devices, and detection should filter out the crippled duplicate.
Apparently that is not happening in your case.
Well, at least brightness can be set using any of the two devices. It
takes effect over the entire monitor, presumably; the backlight
(fortunately) doesn't have two tiles.
* Have you hacked the EDID so that identical monitors have the same
serial number?
Nope, the monitor is in a pristine factory state and I didn't attempt
to override the EDID in software anywhere else.
* The monitor looks like it should support the USB Monitor
Control Class
spec, but detection doesn't find it.
That's weird. Well, at least the HID trick above still works for
brightness. (Not sure what the other |FEATURE| or the |INPUT| is.)
Maybe one of these mysterious devices is an entry point to the
functionality you mentioned?
|$ lsusb | grep LG Bus 006 Device 004: ID 043e:9a68 LG Electronics
USA, Inc. Bus 006 Device 003: ID 043e:9a71 LG Electronics USA, Inc.
Bus 006 Device 002: ID 043e:9a60 LG Electronics USA, Inc. USB3.1 Hub
Bus 005 Device 005: ID 043e:9a70 LG Electronics USA, Inc. USB2.1 Hub
Bus 005 Device 004: ID 043e:9a66 LG Electronics USA, Inc. Bus 005
Device 003: ID 043e:9a73 LG Electronics USA, Inc. Bus 005 Device 002:
ID 043e:9a61 LG Electronics USA, Inc. USB2.1 Hub |
Please run the following commands (n.b. as root) and send the
output as
attachments:
* |$sudo ddcutil interrogate|
<https://github.com/rockowitz/ddcutil/files/4704364/ddcutil_interrogate.txt.gz>
← This gets a |SIGABRT| with |0.9.9-dev|.
ddcutil detected an inconsistency in its statistics reporting. The
assert() failures have been replaced by code that reports the error and
continues. Please re-run with latest 0.9.9-dev branch.
* |$sudo ddcutil usbenvironment|
<https://github.com/rockowitz/ddcutil/files/4704371/ddcutil_usbenvironment.txt>
This looks like there's a USB HID compliant monitor. As a next step,
please run the following command as root and send the output: "ddcutil
detect --verbose --trace usb
* |$sudo ddcutil usbenvironment --verbose|
<https://github.com/rockowitz/ddcutil/files/4704379/ddcutil_usbenvironment_verbose.txt>
← This works fine with |0.9.9-dev|.
The patched code revealed the source of the error, which has been
fixed. Please re-run to confirm and send the output.
Finally, to drill down on the duplicate /dev/i2c device issue, please
run the following as root and send the output:
# ddcutil probe --bus 7
# ddcutil probe --bus 8
Thanks again for your help.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3XDHP42IP4XWRWGOKDRUAQ7VANCNFSM4NLUIYOA>.
|
|
|
Andre (I assume I've properly parsed your username), I believe I've
found the reason that ddcutil detect is not finding a USB connected
monitor in your situation. I've uploaded several changes to branch
0.9.9-dev.
Please rebuild ddcutil from the latest 0.9.-dev branch and upload the
output:
dddutil detect --verbose --trace usb
ddcutil usbenvironment
I am still trying to puzzling over the two seemingly identical /dev/i2c
devices associated with the display, and the fact that for each of them
few of the features declared in the capabilities string are actually found.
Sanford
…On 5/31/20 1:50 PM, andrejpodzimek wrote:
* |ddcutil interrogate|
<https://github.com/rockowitz/ddcutil/files/4708099/ddcutil_interrogate.txt>
* |ddcutil detect --verbose --trace usb|
<https://github.com/rockowitz/ddcutil/files/4708103/ddcutil_detect_--verbose_--trace_usb.txt>
* |ddcutil usbenvironment --verbose|
<https://github.com/rockowitz/ddcutil/files/4708104/ddcutil_usbenvironment_--verbose.txt>
* |ddcutil probe --bus 6|
<https://github.com/rockowitz/ddcutil/files/4708106/ddcutil_probe_--bus_6.txt>
* |ddcutil probe --bus 7|
<https://github.com/rockowitz/ddcutil/files/4708107/ddcutil_probe_--bus_7.txt>
* |ddcutil probe --bus 8| → |No monitor detected on I2C bus
/dev/i2c-8| (Exit code is 1.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3W573TLG6UFB2MK6GDRUKKEVANCNFSM4NLUIYOA>.
|
|
I've fixed a bug that I believe caused display detection to fail for
your monitor's USB connection. The updated code is in branch 0.9.9-dev.
Please run the usual "ddcutil detect --verbose --trace usb" both as root
and normally. The former should work and, unless you've changed
permissions on the /dev/usb/hiddev files (e.g. using UDEV), the latter
should report that opening the hiddev file failed because of permissions.
Command "ddcutil usbenvironment" been modified to eliminate some low
level USB information that was not very useful, and to read the EDID
using USB connection if possible. Run it as root.
Please send the output for all 3 cases.
Thank you,
Sanford
…On 6/3/20 11:10 AM, andrejpodzimek wrote:
* |ddcutil detect --verbose --trace usb|
<https://github.com/rockowitz/ddcutil/files/4724274/ddcutil_detect_--verbose_--trace_usb.txt>
* |ddcutil usbenvironment|
<https://github.com/rockowitz/ddcutil/files/4724275/ddcutil_usbenvironment.txt>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3Q2OLAV6BFJRL6WIVDRUZRXBANCNFSM4NLUIYOA>.
|
|
|
Andre,
Bear in mind that I2C and USB are two quite independent mechanisms for
communicating with a monitor's Virtual Control Panel (VCP). /dev/i2c
devices are used to communicate over an I2C bus, /dev/usb/hiddev devices
are used for communication over USB. Group "i2c" is commonly (but alas
not always) assigned to /dev/i2c devices. It would not make sense to
assign such a group name to a /dev/usb/hiddev device.
Though group "i2c" is commonly used for /dev/i2c devices, that is not
always the case. Depending on how i2c-tools is packaged for a
particular platform, it may or may not create group "i2c" install udev
rules that and assign /dev/i2c devices to that group. . It has been
suggested that ddcutil installation packages should perform similarly,
but I don't want ddcutil to be the proverbial bull in the china shop.
Hence the complex instructions (and checks in "ddcutil environment") re
setting up /dev/i2c permissions.
When checking if a /dev/usb/hiddev device represents a communication
path to a monitor's VCP, there are two concerns. The first is
permissions, the second is that certain USB devices, e.g. mice, can be
disabled if the usual VCP communication protocol is used. ddcutil has
to be careful the check first that a USB device is not a keyboard or
mouse, but is potentially a monitor supporting VCP communication (more
technically it has to be a USB Human Interface Device (HID) , but not a
keyboard or mouse).
Laptop displays, i.e. currently eDP devices never implement a VCP,
either over I2C (using DDC/CI) or over USB (as a HID).
With all this as background, the message you've noted:
|Monitor on device /dev/usb/hiddev3 reports no EDID or has invalid EDID.
Ignoring.|
is not about an eDP connection. hiddev3 really is a USB connection for
communicating with your monitor. The message indicates that
/dev/usb/hiddev3 claims to support the HID Monitor Control Class Spec.
(In fact, we can see from usbenvironment that it implements a couple VCP
features, including x10 - brightness). But on closer inspection it
lacks the USB "report" that returns the EDID, which ddcutil requires.
So ddcutil has to ignore it.
Back to the permissions question, ddcutil provides some sample rules
(45-ddcutil-i2c.rules and 45-ddcutil-usb.rules) for assigning groups and
permissions to the respective devices. These are located in the source
tree at data/etc/udev/rules.d. For the packages I provide, they are
installed under /usr/share/ddcutil/data.
Per your suggestion, it would be possible to create a special group, say
"ddcutil" or "mccs", which udev rules such as the above to set group and
permission on the appropriate /dev/i2c and /dev/usb/hiddev devices, in
addition to whatever group names they have. But I fear this would lead
to even more confusion. And it is something that would occur when
ddcutil is installed from a package, not when building from source.
If you haven't already, take a look at www.ddcutil.com/usb and
www.ddcutil.com/permissions. These pages have just sort of grown and
need to be rewritten, but they should fill in some of the details.
In summary, all our testing revealed a bug in how ddcutil detects USB
connected monitors, but even with that fixed your monitor's USB
implementation is insufficient for ddcutil's needs.
There main 2 outstanding issues in your monitor/driver. Neither appear
to be problems for you - ddcutil is controlling your monitor
brightness. However, they do catch my attention.
First, why are there duplicate /dev/i2c devices for the monitor, which
both appear to work? I've seen this before, with the nouveau driver,
but in that case one of the /dev/i2c devices supported DDC/CI, and one
didn't, and it was possible to distinguish the two by examining /sys.
In your case I don't see any way to pick a device to ignore. This may
be a problem in the monitor's DDC/CI implementation, it may be an amdgpu
problem. or some combination.
The second is that the capabilities string reports a large number of VCP
features, but when ddcutil attempts to read most of these feature values
it receives a well-formed response packet with the unsupported feature
bit set. I'll puzzle over this a more, but at this point my best guess
is that it's also problem in the monitor's DDC/CI implementation.
Thank you for all your help in diagnosing these issues.
Regards,
Sanford
…On 6/11/20 10:35 PM, andrejpodzimek wrote:
*
|ddcutil detect --verbose --trace usb|
<https://github.com/rockowitz/ddcutil/files/4768345/ddcutil_detect_--verbose_--trace_usb.txt>
First this couldn't open any of the |/dev/i2c-*| devices. So I
added myself to the |i2c| group. (Which is already wrong; this
should be managed by |systemd| using ACLs to grant permissions
dynamically based on logins and seats (just like sound cards and
input devices are managed). Unfortunately, I couldn't find a
suitable |udev| + |systemd| configuration example on the web that
would manage |/dev/i2c-*| properly.) Even with my |i2c|
membership, it still complains about |/dev/usb/hiddev*|. But those
devices have |root:root| ownership and |600| permissions by
default, so no quick'n'dirty membership hack is available.
|Open failed for /dev/usb/hiddev0: errno=EACCES(13): Permission
denied Open failed for /dev/usb/hiddev2: errno=EACCES(13):
Permission denied Open failed for /dev/usb/hiddev3:
errno=EACCES(13): Permission denied Open failed for
/dev/usb/hiddev4: errno=EACCES(13): Permission denied |
I guess the only proper and root-avoiding solution would be to
have seat-based ACLs managed by |udev| + |systemd|. Which sounds
like quite a big undertaking involving lots of USB IDs of monitors
and lots of configuration. 😱
*
|sudo ddcutil detect --verbose --trace usb|
<https://github.com/rockowitz/ddcutil/files/4768351/sudo_ddcutil_detect_--verbose_--trace_usb.txt>
I haven't mentioned it before, but this rants a bit on |stderr|
when it sees |eDP1|, the laptop display:
|Monitor on device /dev/usb/hiddev3 reports no EDID or has invalid
EDID. Ignoring. |
*
|sudo ddcutil usbenvironment|
<https://github.com/rockowitz/ddcutil/files/4768354/sudo_ddcutil_usbenvironment.txt>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3XXMIJD6ARTQVL2OXDRWGH5JANCNFSM4NLUIYOA>.
|
|
Thanks for the details. My entire point about the ACLs was the little
Presumably, I'm not in the Just like sound cards (or even more so), monitors should be associated with a particular login seat. (There's no point in allowing a user logged in over SSH or from an unrelated seat to adjust backlight brightness.) However, as you pointed out, this should be done in a separate project (using |
|
As for the (numerous) monitor capabilities listed but not really “exposed”, this is something that I also find puzzling. One of my goals was to set a cooler color tone on the monitor, but the corresponding capabilities don't seem to be actually working. Admittedly, I haven't tried too many wannabe-clever tricks to poke around and skip some of the checks, simply because I don't really want to brick the monitor. But since my laptop has a much cooler tone than the monitor and since I prefer white at 6000 K anyway, I thought it would be awesome to configure this on the monitor as well. |
|
Andre,
I doubt that any "clever tricks" are going to work here. ddcutil sends a
well formed DDC Feature Request packet and, despite what the
capabilities report indicates, receives a well formed DDC Feature
Response packet reporting features as unsupported. To see this, run
getvcp with option "--trcfunc ddc_write_read"
I do have one really remote possibility, that valid data is returned
even though the unsupported feature flag is set. If you send me the
output of "ddcutil probe --trcfunc ddc_write_read" I'll pour over it to
see if I cab find a pattern. Please use the latest 0.9.9-dev branch.
If you can connect the monitor to a Windows system, EnTech's softMCCS
<https://entechtaiwan.com/lib/softmccs.shtm>is another way to check what
the monitor is doing.
Regards,
Sanford
…On 6/14/20 5:46 PM, andrejpodzimek wrote:
As for the (numerous) monitor capabilities listed but not really
“exposed”, this is something that I also find puzzling. One of my
goals was to set a cooler color tone on the monitor, but the
corresponding capabilities don't seem to be actually working.
Admittedly, I haven't tried too many wannabe-clever tricks to poke
around and skip some of the checks, simply because I don't really want
to brick the monitor. But since my laptop has a much cooler tone than
the monitor and since I prefer white at 6000 K anyway, I thought it
would be awesome to configure this on the monitor as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RKR6CVARCCCPGB3LLRWVAMVANCNFSM4NLUIYOA>.
|
|
Further thoughts:
The user manual does not document an On Screen Display. Is there a
button to turn it on? The capabilities string indicates that features
xCA (OSD Button Control) and xCC (OSD Language) are supported.
Conceivably there's a firmware fix for this model. The support page for
the monitor does not list one, but it does point to the LG Screen
Manager, a Mac app for updating the firmware (and presumably searching
for updates). So if you have access to a Mac you might try that.
On other thing to try is to use a setvcp command to see if it actually
changes observed behavior. (Of course, the verification step will fail,
since that's just an internal getvcp.) Interesting possibilities are
feature x04 (Restore Factory Defaults) and x05 (Restore Factory
Brightness/Contrast).
Sanford
…On 6/14/20 5:46 PM, andrejpodzimek wrote:
As for the (numerous) monitor capabilities listed but not really
“exposed”, this is something that I also find puzzling. One of my
goals was to set a cooler color tone on the monitor, but the
corresponding capabilities don't seem to be actually working.
Admittedly, I haven't tried too many wannabe-clever tricks to poke
around and skip some of the checks, simply because I don't really want
to brick the monitor. But since my laptop has a much cooler tone than
the monitor and since I prefer white at 6000 K anyway, I thought it
would be awesome to configure this on the monitor as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RKR6CVARCCCPGB3LLRWVAMVANCNFSM4NLUIYOA>.
|
No, the monitor has exactly zero buttons. It doesn't show any signs of an OSD, controlled or automatic. (Older monitors sometimes show a message for a few seconds when they detect inputs or lose signal, but this one doesn't.)
I don't have any of that.
I tried |
|
On 7/3/20 2:58 PM, andrejpodzimek wrote:
If you send me the output of "ddcutil probe --trcfunc ddc_write_read"…
* |ddcutil probe --trcfunc ddc_write_read|
<https://github.com/rockowitz/ddcutil/files/4871038/ddcutil_probe_--trcfunc_ddc_write_read.txt>
I've looked at the raw getvcp response packets. They are indeed well
formed with the Unsupported Feature bit set. I had thought that perhaps
the data bytes (MH, ML, SH, SL) would nonetheless be set meaningfully.
Not so.
Is there a button to turn it on?
No, the monitor has exactly zero buttons. It doesn't show any signs of
an OSD, controlled or automatic. (Older monitors sometimes show a
message for a few seconds when they detect inputs or lose signal, but
this one doesn't.)
This really looks like a monitor built to behave like a Mac monitor. I
wouldn't be surprised if there were some Mac-specific way to change
Monitor settings.
If you can connect the monitor to a Windows system…
So if you have access to a Mac you might try that.
I don't have any of that.
Interesting possibilities are feature x04 (Restore Factory
Defaults) and x05 (Restore Factory Brightness/Contrast).
I tried |ddcutil --display 1 setvcp x05 1|. But it didn't have any
noticeable effect. A subsequent |getvcp| on value |10| returned the
same brightness I had set before. The command terminates successfully
though. I wasn't sure what the argument should be (and tried just |0|
and |1|). The feature |x05| is not readable, so I had no reference point.
Any non-zero value for feature x04 or x05 causes a reset. A value of 0
is ignored.
I'm afraid I don't have any more suggestions. As I said above, this
appears to be a monitor built solely with Macs in mind. Thank you for
all your help diagnosing the issues were solvable.
Regards,
Sanford
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VWIQBAGHL42J2EUHTRZYS3TANCNFSM4NLUIYOA>.
|
|
sorry to bump this closed thread, i just want to point out this Andre's C program (#123 (comment)) works with the newly released Apply studio display 5k. |
|
It's not clear to me what "this script" in your message refers to. The "123 (comment)" link is to Andre's C program derived from acdconttrol. Are you communicating with the monitor using I2C or USB? |
the new apple studio display is brightness over usb only, no ddc support as far as I can tell. I edited my last comment to be more clear. output from ddcutil usbenv command for those interested. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While the 5k resolution works fine and looks awesome (thanks to this latest fix), I haven't found a way to make backlight controls work. I tried lots of combinations, both as
rootand as a regular user:ddcutil getvcp 10 --hiddev 3 ddcutil getvcp 10 --usb 7.5 ddcutil probe --hiddev 3 ddcutil probe --usb 7.5 ddcutil detect ddcutil usbenv # <<< This does something!I always get No displays found from
detectand Display not found from the (more) monitor-specific commands. Onlyddcutil usbenvseems to identify the monitor somehow:Initially I tried a few LG-specific brightness control tools, but they didn't work for me, likely because they assume i2c over DisplayPort or the like, whereas this monitor is Thunderbolt-only and may not have an i2c bus relayed through Thunderbolt. I do have
i2c_hidloaded, but no i2c devices pop up in/dev.Full
ddcutil usbenvoutputIn particular, this piece of data looks like “something backlight-related”:
System configuration
The text was updated successfully, but these errors were encountered: