Sigil-2.0.0 Released

[Vanguard3000]

Odd. I've repeated the process - I swear I did it correctly - and got some new stuff:

Debug: Primary Screen:  "LG FHD (1)" "LG Electronics" "16843009LG FHD"
Debug:     geo        :  QRect(1920,0 1920x1080)
Debug:     avail   geo:  QRect(1920,0 1920x1040)
Debug:     devideRatio:  1
Debug:     logical dpi:  96 96
Debug:     physic  dpi:  81.28 80.6824
Debug: 

All Screens
Debug: Screen:  0 "LG FHD (1)" "LG Electronics" "16843009LG FHD"
Debug:     geo        :  QRect(1920,0 1920x1080)
Debug:     avail   geo:  QRect(1920,0 1920x1040)
Debug:     devideRatio:  1
Debug:     logical dpi:  96 96
Debug:     physic  dpi:  81.28 80.6824

The only thing I did differently was I had initially renamed the original to "bak_qwindows.dll", and this time I removed it to another folder.

Anyway, it looks like It's getting the "name" value from the EDID rather than the "FriendlyName" value I had set in the registry. I'm not sure if it matters but they're in slightly different locations. In the attachment, I've circled the FriendlyName in red and the Device Parameters subfolder containing the EDID in blue.

When I tried changing the serial number in the EDID it reverted when Windows restarted so I assume the same would be true for changing the name in the EDID.

[DiapDealer]

I would love for that test to be double-checked if possible. Move the original qwindows.dll completely out of the platforms folder, and put the new one in. The new qwindows.dll file should be the only file in the platform folder. Also make sure your launching the version of Sigil that has the new dll (in case you have two Sigil installations and are accidentally launching the wrong one). Also make sure to delete the existing debug log before launching Sigil.

I ask only because I got different output (with SOME name appended to my serial number) when testing the new patched dll. I never made any registry changes and still saw different results.

I first renamed my existing dll and left it in the platform folder. But after I named them back, the patched version of the dll was still being use (even though it had the wrong name). That's why I'm recommending only the one dll in that platforms folder. Windows has the annoying habit of sometimes using routines from dlls still in memory rather than accessing the dll again.

EDIT: We cross-posted, obviously. Thanks for your diligence.

Thanks in advance.

[KevinH]

Hmm, new code is doing the following which should read the friendly name not the edid name.

        // We skip edid.identifier because it is unreliable, and a better option
        // is already available through DisplayConfigGetDeviceInfo (see below).
        names << QString::fromWCharArray(deviceName.monitorFriendlyDeviceName);

so I have no idea unless it is reading a different friendly name than the one you set.

Strange!

Have you tried a full restart to force-all new values to be read?

[DiapDealer]

I should be able to do some testing to check these particulars, at least. Even if I can't duplicate the main issue.

[KevinH]

That would be grand.
Perhaps the monitor friendly name and the monitor driver friendly name are two different things?

We just need to set the right friendly name to make it appear in in that serial number and we can be in business.

Let me check how Qt 5.12.10 did things since that worked for Vanguard3000 previously as it was used for Sigil 1.9.30.

Originally Posted by DiapDealer

I should be able to do some testing to check these particulars, at least. Even if I can't duplicate the main issue.

[Vanguard3000]

I hadn't restarted after the second time adding the DLL but I had restarted several times since adding the friendlyName, and confirmed it was showing correctly in the Device manager.

I'm out for the evening but later tonight if I have time I'll try chucking a different Friendly snae on the monitor folder (i.e. leaving the current ones as is) and a second new one in the Device Parameters subfolder.

[KevinH]

It turns out that prior to Qt 6.5.2 the name used is now called the data.deviceName.
If setting friendly monitor names doesn't work I might try adding deviceName to the serial number to force it to revert to earlier behaviour.

So we still have one more avenue to explore if using friendly monitor names does not work.

[KevinH]

I started to search github for code that accesses "monitorFriendlyDeviceName" and found this snippet in the chrome code:

// Gets a user-friendly name for a given display using EDID data. Returns an
// empty string if the provided path is unset/nullopt or EDID data is not
// available for the device.
std::string GetFriendlyDeviceName(
    const absl::optional<DISPLAYCONFIG_PATH_INFO>& path) {
  if (!path)
    return std::string();
  DISPLAYCONFIG_TARGET_DEVICE_NAME targetName = {};
  targetName.header.type = DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME;
  targetName.header.size = sizeof(targetName);
  targetName.header.adapterId = path->targetInfo.adapterId;
  targetName.header.id = path->targetInfo.id;
  LONG result = DisplayConfigGetDeviceInfo(&targetName.header);
  if (result == ERROR_SUCCESS && targetName.flags.friendlyNameFromEdid)
    return base::WideToUTF8(targetName.monitorFriendlyDeviceName);
  return std::string();
}

So it appears that the flags determine where the monitor friendly name comes from and just like Vanguard3000 said it appears to be derived from the EDID which in this case makes it worthless.

I am going to change the patch to use the deviceName info to see if that is unique.

[DiapDealer]

That explains why even though I have the friendly name configured, I'm getting empty info for the display on my Windows VM. I doubt Oracle bothers with faking a reasonable edid. I'll have to wait until I get near a physical Windows machine.

[patrik]

I have dual screens on a win 10 machine. Let me know if you want me to run something.

[KevinH]

Originally Posted by patrik

I have dual screens on a win 10 machine. Let me know if you want me to run something.

Thanks. Unfortunately to recreate the bug, you need two absolutely identical monitors that just happen to have two identical EDID serial numbers that the manufacturer should never have allowed to happen. It appears at least some manufacturers did including LG and Acer.

That said, I have sent a new patch to DiapDealer for building to use the deviceName appended to the serial number. The deviceName was used in the Qt version from Sigil 1.9.30 and earlier so if it worked then it should work here.

Once we have a new qt windows plugin dll, we can test it to see if that fixes the bug.

The nice thing about this version is that it will NOT require any registry changes at all.

[nabsltd]

Originally Posted by Vanguard3000

Anyway, it looks like It's getting the "name" value from the EDID rather than the "FriendlyName" value I had set in the registry. I'm not sure if it matters but they're in slightly different locations. In the attachment, I've circled the FriendlyName in red and the Device Parameters subfolder containing the EDID in blue.

This screenshot shows that Windows is using the default PnP monitor driver. Monitors don't really need "drivers", but the INF and other support files give Windows more information about the monitor. Installing it might help.

[KevinH]

@Vanguard3000.

Okay, DiapDealer has graciously rebuilt the qt windows plugin one more time, removing the need to deal with any registry stuff.

You can grab it from here:

https://github.com/kevinhendricks/Bu...nMac/releases/

It is again called qwindows.dll.zip (I replaced the previous build).

Unzip it and use it to completely replace the previous version in the same location as before.

Then give a fresh startup of the debug Sigil a try.

This version uses exactly the same information used by Qt 5.12.X as used in Sigil-1.9.30 and appends it to the serial number to hopefully make them unique.

If Sigil 1.9.30 worked properly, this one should too.

Please let us know.

Thanks!

[KevinH]

Since all my posting on the Qt bug report whose fix caused this problem in the first place seems to have been ignored, I opened a new bug report with Qt, that at least shows the code they are using is broken.

For the record, here is the new bug report:

https://bugreports.qt.io/browse/QTBUG-116499

[theducks]

I have 2 sets of dual screens handy (Acer and LG). Due to the shape, I run with the Acers on the bottom on different systems.
BUT FOR YOU
I can move some cables for a test