Sigil-2.0.0 Released

[KevinH]

@Vanguard3000,
I have been reading the code in Qt6.5.2 in qwindowsscreen.cpp and it appears the serialnumber for each monitor is extracted from an edidRegistryKey in the Windows registry.

Each monitor will dump its edid block when connected and the qt code tries to parse it to get the pieces.

If for any reason both edid blocks do not exist in the registry or if edid parsing fails, this will fail.

This provides an avenue to explore if editing the registry might help solve the issue.

[Vanguard3000]

Here's the debug info:

Debug: Primary Screen:  "LG FHD (1)" "LG Electronics" "16843009"
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" "16843009"
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

So it looks like it knows there IS a primary monitor, but because all the other info is identical it doesn't know WHICH one that is. I've readded the "FrienldyName" keys and it's not recording that in your debug log.

[Edit] I'm wondering where that "LG FHD" name is coming from (not the registry, apparently) since that may be the "name" it's looking for.

[Edit 2] Okay, I've found it in a different spot in the registry. I'm going to do something stupid...

[Edit 3] I tried renaming them and restarted but the name reverted. Worth a try I guess.

Originally Posted by KevinH

@Vanguard3000,
I have been reading the code in Qt6.5.2 in qwindowsscreen.cpp and it appears the serialnumber for each monitor is extracted from an edidRegistryKey in the Windows registry.

The monitors have a registry EDID key in a "device parameters" subfolder within the monitor's folder (i.e.
"HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\DISP LAY\GSM5BCA\5&96b30e3&0&UID4352\Device Parameters"
). Both EDID entries are identical as well.

[KevinH]

Since both EDID's are identical it explains why the SerialNumbers of both are identical: 16843009

Given everything is identical, there is just no way for Qt to tell them apart. Especially not using the serialNumber extracted from identical EDID blocks.

Do you have any other ports you could use for a second display. Maybe a different usb-c to hdmi adapter or anything else like that?

I know they make inline edid modifiers. Some are dirt cheap. Perhaps you could use one to change the edid of the second monitor to use a different serial number?

Something like this come to mind, but you would need one that can change the serial number. I am not surevanyone even makes one.

https://www.amazon.ca/Passthrough-Ge...08RCMFLMK?th=1

Until we can find out how to distinguish between the two monitors that Qt can detect we have no way to fix or patch anything.

[KevinH]

Are those EDID blocks in hex code? If so could you copy each of them to text files so that I can try parsing the edid blocks and create a new edid with a changed serial number?

I am really stumped.

[KevinH]

Actually that Sigil debug output in incorrect as well. It should show the primary screen then show all screens including the primary and secondary screens. So it should show 3 in total. That only shows 2 entries.

So Qt thinks you only have one screen, as the second one overwrote the first one!

You are not in "clone" mode with your screens by any chance?

[Vanguard3000]

Originally Posted by KevinH

Do you have any other ports you could use for a second display. Maybe a different usb-c to hdmi adapter or anything else like that?

I know they make inline edid modifiers. Some are dirt cheap. Perhaps you could use one to change the edid of the second monitor to use a different serial number?

I tried switching DP ports. My card has an HDMI port as well but Idon't believe I have an adapter going that way.

Originally Posted by KevinH

Are those EDID blocks in hex code? If so could you copy each of them to text files so that I can try parsing the edid blocks and create a new edid with a changed serial number?

Yes, they are of type REG_BINARY and the value is in hex.

Originally Posted by KevinH

I am really stumped.

Me too. Sorry. Seems like an issue Qt would have noticed before this version went live.

Originally Posted by KevinH

You are not in "clone" mode with your screens by any chance?

No, they're on "Extend".

[KevinH]

Qt changed the way they do this because of bug reports. EDID blocks are NOT supposed to have the same serial numbers. So what Qt did really should not have hurt but in your case it did.

I still can not figure out why your debug.txt has only two entries. It should list the info for the primary first. And then list it for all screens, primary included.

Can you copy and paste the two edid blocks into a text file and zip then up and post them. I want to try decoding them just to verify that Qt has not messed that up.

[democrite]

I'll try to keep investigating and see if I can find something reproducable.

Originally Posted by DiapDealer

Also keep in mind that Sigil is never going to be 100% aesthetically mac. Nor is it going to be 100% aesthetically Windows. Sigil, first and foremost, needs to work on three different platforms with the same codebase. Hopefully without crashing on any of them. If disabling native file dialogs on one platform makes keeping things stable on three platforms easier, then that is what we will do.

I understand that it's just you two. Yet I sort of like the idea of trying to be as native as possible on all platforms. Possible hidden preference? What to say, it is just more pleasing, elegant, mouse gestures, keyboard shortcuts, and UI actions would feel more native without the need of cognitive distraction to stop and think, hey I need to change how I press keys, move the mouse, etc. for some moment. Perhaps difficult yet who knows, maybe if such becomes slowly implemented, users will just be happier, more will use it, and maybe someday others will join in and contribute. Perhaps I just think such is part of making an app more popular, pleasant, useful, praised, and one might someday get all else that comes along with such.

[RbnJrg]

Right now I updated to Sigil 2.01 from the Arch repo and that version is compiled with Qt 5.15.10 and not Qt 6.5.2. Does that fact make Sigil 2.x (from the Arch repo) not work fully?

[KevinH]

Originally Posted by RbnJrg

Right now I updated to Sigil 2.01 from the Arch repo and that version is compiled with Qt 5.15.10 and not Qt 6.5.2. Does that fact make Sigil 2.x (from the Arch repo) not work fully?

That is unfortunate. We contacted them in advance to tell them about the move to Qt6 but unfortunately they seem to have ignored us.

Perhaps DiapDealer can nudge them a bit.

Sigil will remain buildable under Qt 5.15 or so for the next year just to handle much older Linux distributions.

As long as you can still run all your plugins, you should be okay. Test ones that use Qt to do the plugin's gui to see. Try one of Doitsu's qt based ones and our Readium Reader plugin as I know it uses Qt.

If they all continue to work, you should be okay.

But Arch should really be using Qt6.5.2

[Vanguard3000]

Originally Posted by KevinH

Can you copy and paste the two edid blocks into a text file and zip then up and post them. I want to try decoding them just to verify that Qt has not messed that up.

Here you go! This is everything in
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\E num\DISPLAY\GSM5BCA

You'll find the two EDIDs in there. Also, there are a few displays that have appeared with no properties in there. They've appeared during my tinkering and can't be removed.

[DiapDealer]

Originally Posted by democrite

I understand that it's just you two.

That really doesn't have anything to do with it.

Originally Posted by democrite

Yet I sort of like the idea of trying to be as native as possible on all platforms.

And what you're not understanding is that that's not always possible when one is dealing with a cross-platform project that is built from the same code on ALL platforms. We rely on Qt to do ALL the heavy lifting (graphically).

[DiapDealer]

Originally Posted by KevinH

That is unfortunate. We contacted them in advance to tell them about the move to Qt6 but unfortunately they seem to have ignored us.

Perhaps DiapDealer can nudge them a bit.

Sigil will remain buildable under Qt 5.15 or so for the next year just to handle much older Linux distributions.

As long as you can still run all your plugins, you should be okay. Test ones that use Qt to do the plugin's gui to see. Try one of Doitsu's qt based ones and our Readium Reader plugin as I know it uses Qt.

If they all continue to work, you should be okay.

But Arch should really be using Qt6.5.2

I was rather disappointed when I saw that. I gave the Arch maintainer plenty of advance notice, I thought. They already have their PageEdit package as a roadmap. He seemed genuinely in favor of it, and thanked me for the info I shared. He indicated he was going to work on putting it together (Qt6). At this point, I have no idea what the resistance might be. I sort of assumed it was a done deal. I still hold out a little hope that an update might happen. I've no idea how many packages he's wrangling.

But yes, Reuben, I think all of 2.0 features will be be available to you with the Arch package. I was back and forth between Sigil Qt5.15.x and Sigil Qt6.5.x quite a bit when doing my testing on my Arch machine.

[KevinH]

Your edid blocks are exactly identical and can be decoded to the following:

{
"manufacturer_id": 7789,
"manufacturer": "Goldstar Company Ltd",
"manufacturer_pnp_id": "GSM",
"product_id": 51803,
"year": 2021,
"week": 1,
"edid_version": "1.4",
"type": "digital",
"width": 60.0,
"height": 34.0,
"gamma": 2.2,
"dpms_standby": true,
"dpms_suspend": true,
"dpms_activeoff": true,
"resolutions": [[720, 400, 70.0], [720, 400, 88.0], [640, 480, 60.0], [640, 480, 72.0], [640, 480, 75.0], [800, 600, 56.0], [800, 600, 60.0], [800, 600, 70.0], [800, 600, 75.0], [832, 624, 75.0], [1024, 768, 87.0], [1024, 768, 60.0], [1024, 768, 72.0], [1024, 768, 75.0], [1152, 864, 75.0], [1280, 720, 60.0], [1280, 800, 60.0], [1280, 1024, 60.0], [1440, 900, 60.0], [1400, 1050, 60.0], [1600, 900, 60.0], [1680, 1050, 60.0]],
"name": "LG FHD",
"serial": 16843009
}


Bytes 12 to 15 (number count starts at 0 not 1) are the serial number.

The last byte is a checksum byte added to make the sum of all 128 bytes to be 0 (mod 256)

So I wonder if it is possible to change one of the EDID blocks to be:

00 ff ff ff ff ff ff 00 1e 6d ca 5b 01 01 01 02
01 1f 01 04 a5 3c 22 78 fb 7b 45 a4 55 4a a2 27
0b 50 54 a5 4b 00 71 4f 81 c0 81 00 81 80 95 00
90 40 a9 c0 b3 00 2a 44 80 a0 70 38 27 40 30 20
35 00 e0 0e 11 00 00 1e 00 00 00 fd 00 30 4b 55
55 12 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4c
47 20 46 48 44 0a 20 20 20 20 20 20 02 3a 80 18
71 38 2d 40 58 2c 45 00 e0 0e 11 00 00 1e 01 ed

which should change its serial number to be 16843010

Might be worth a shot but I would guess that restarting the comnputer would just reset it.

The only right way to fix this is to ask Qt to add back the user device Friendly name but concatenate the the serial number to it to make something any user could make unique.

I have tried to alert Qt's developers to the problem by posting in the original bug report that caused the change to EDID serial numbers in the first place:

See https://bugreports.qt.io/browse/QTBUG-112829

[KevinH]

@democrite,

Would you try using the macOS x86_64 build under Rossetta 2 to see if the bug/abort happens there as well and report back. That would help if I could narrow down my search to be arm64 specific.

Also are you using the latest macOS Ventura 13.5.1 as it is supposed to include a number of bug fixes specific to arm64. It might help. All of my testing is being done with it, and I still can not replicate what you are seeing.

Originally Posted by democrite

I'll try to keep investigating and see if I can find something reproducable.



I understand that it's just you two. Yet I sort of like the idea of trying to be as native as possible on all platforms. Possible hidden preference? What to say, it is just more pleasing, elegant, mouse gestures, keyboard shortcuts, and UI actions would feel more native without the need of cognitive distraction to stop and think, hey I need to change how I press keys, move the mouse, etc. for some moment. Perhaps difficult yet who knows, maybe if such becomes slowly implemented, users will just be happier, more will use it, and maybe someday others will join in and contribute. Perhaps I just think such is part of making an app more popular, pleasant, useful, praised, and one might someday get all else that comes along with such.