readme could describe how to find out monitor IDs about display-switch HOT 5 OPEN

I wonder if it would be doable to have some kind of "discovery" sub-command

For example the user could run something like display-switch discover. Then they click the USB-switch button and the command displays which devices are (dis)connected. They switch monitor input manually and it describes which display has switched to which input. This would provide all the necessary values to enter into the config file

from display-switch.

For Linux the answer might be that you can get this info via "ddcutil detect", which produces output like this for each monitor:

Display 1
   I2C bus:             /dev/i2c-5
   EDID synopsis:
      Mfg id:           DEL
      Model:            DELL U2719D
      Serial number:    361PY13
      Manufacture year: 2020
      EDID version:     1.3
   VCP version:         2.1

I'm not sure which fields of this display_switch is reading and matching on, though.

from display-switch.

@pm215 I suggest running display_switch with empty or dummy monitor_id, the app will log whatever monitor IDs it detected, then you could update the config to match that.

from display-switch.

The logging seems to indicate that display_switch is only finding numeric monitor IDs, eg

19:20:20 [INFO] Display '22789' is currently set to Custom(0x1111)

whereas the readme suggests that the config file monitor_id ought to be able to match against model or manufacturer names or serial numbers. Looking at the code in display_control.rs, it looks like it's only looking at the ddc_hi::DisplayInfo::id, and not the other strings. I added a bit of debug printing:

--- a/src/display_control.rs
+++ b/src/display_control.rs
@@ -49,6 +49,9 @@ pub fn log_current_source() {
     }
     let unique_names = are_display_names_unique(&displays);
     for (index, mut display) in displays.into_iter().enumerate() {
+        info!("Display id {} manufacturer_id {:?} model_name {:?} serial_number {:?}",
+              display.info.id, display.info.manufacturer_id,
+              display.info.model_name, display.info.serial_number);
         let display_name = display_name(&display, if unique_names { None } else { Some(index + 1) });
         match display.handle.get_vcp_feature(INPUT_SELECT) {
             Ok(raw_source) => {

which shows that the interesting stuff is in the fields we're not using:

19:25:10 [INFO] Display id 22789 manufacturer_id Some("DEL") model_name Some("DELL U2719D") serial_number Some("361PY13")
19:25:10 [INFO] Display '22789' is currently set to Custom(0x1111)
19:25:10 [INFO] Display id 22790 manufacturer_id Some("DEL") model_name Some("DELL U2719D") serial_number Some("DT86VS2")
19:25:10 [INFO] Display '22790' is currently set to Custom(0x1111)

Maybe display_name() should be concatenating these things together with the 'id' string?

The ddc_hi documentation says that id is "a unique identifier for the display, format is specific to the backend", and it looks like for Linux the i2c-dev backend just uses the (major,minor) of the device, so in this case 22789 == hex 0x5905 which is device 59,5 (/dev/i2c-5) and 22790 is 59,6 which is /dev/i2c-6. Being able to match on something specific to the monitor like its manufacturer or serial number seems like it would be more reliable than matching on something that's a detail of how the monitor DDC connection appears in the i2c subsystem.

from display-switch.

Ran into this same problem, ended up shrugging my shoulders and trying the switch globally - saw in the logs it told me exactly what names it was expecting. A discovery command would be great.

Along with that, already using the switch and having an awkward setup, a nicer command for usb id discovery might be along the lines of: lsusb > a && echo sleepstart && sleep 2 && echo sleepend && lsusb > b && diff -u a b

from display-switch.