readme could describe how to find out monitor IDs

[pm215]

The readme documents how to support multiple monitors by adding config file sections with 'monitor_id' specifications to distinguish the different monitors. However, it doesn't describe how to find out what your monitor's monitor ID is so that you can set the config value appropriately.

If this is easy to do with existing command line tools, the readme could just say how to do that, as it does for USB IDs. If it's difficult, maybe display_switch could have a command line option for "don't do anything, just print all the IDs for all connected monitors" (since it seems to already have the code for "enumerate all the connected displays and find their ID string").

[pm215]

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.

[haimgel]

@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.

[pm215]

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.

[dbr]

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

[lordee]

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