trigger cosmic-osd display identifier OSD on each screen to ease display arrangement configurations for users

[FreddyFunk]

implements #885

requires pop-os/cosmic-osd#151

preview:

2025-11-09.21-51-08.mp4

[maria-komarova]

Thanks for working on it. There was a previous discussion about it and a mockup. The idea is to always show the numbers when there are 2+ displays connected. We've seen cases where people struggled to identify which display is which while trying to arrange them so having the numbers always present while Displays page in Settings is focused would be helpful. You can see the placement and the styling of the OSD on the mockup. Accent color background is used to make the OSD more immediately apparent.

[wash2]

I think that the way this is implemented is mostly fine, but there should probably be some sort of timeout for the osd, so that if settings fails to dismiss it properly, it disappears on its own after a few seconds. For example, when testing if, if I navigate to the displays page and close the settings app, the osd does not disappear unless I navigate away from the page.

@pop-os/ux Do you think it could appear on first entering the page, then fade away after a few seconds, and reappear when a display is hovered?

[maria-komarova]

Do you think it could appear on first entering the page, then fade away after a few seconds, and reappear when a display is hovered?

I was wondering about that but we've discussed it with @WatchMkr and thought it best to have the numbers show as long as the Displays page is focused.

[FreddyFunk]

I think that the way this is implemented is mostly fine, but there should probably be some sort of timeout for the osd, so that if settings fails to dismiss it properly, it disappears on its own after a few seconds. For example, when testing if, if I navigate to the displays page and close the settings app, the osd does not disappear unless I navigate away from the page.

This should only happen, if you forcefully kill the cosmic-settings process. When you gracefully close the settings app via the "x" button, then the OSD should disappear as well. Nonetheless, during the development I have implemented two different proof of concepts to deal with a cosmic-settings app crash/kill and still be able to hide the display identifier OSD.

1. Add a listener to the display identifier OSD that checks if the process ID that has triggered the event is still running. If not, the OSD close on their own.
2. The OSD closes after a 2 second timer, but sending the identify displays d-bus message resets this timer for all display identifier OSDs.

Option 1 feels a bit hacky, option 2 feels like unnecessary message spam on the d-bus (but manageable, since its a 1-to-n connection from sender to subscriber). I did not feel comfortable with either option so I did not included them. Feel free to let me know what you think would be the best option.

@pop-os/ux Do you think it could appear on first entering the page, then fade away after a few seconds, and reappear when a display is hovered?

I can implement a fade out animation as well. The more specific you are with those details, timings and so on, the better.

[FreddyFunk]

Here is a video of what the current develop state in this pull request looks like:

2025-11-12.21-17-46.mp4

[wash2]

The OSD closes after a 2 second timer, but sending the identify displays d-bus message resets this timer for all display identifier OSDs.

This sounds fine to me for now. Maybe even with a 1 second timer.

This should only happen, if you forcefully kill the cosmic-settings process.

It happened when I closed settings using the Super + Q shortcut

[FreddyFunk]

Alright, then I will do it that way.

[FreddyFunk]

addressed the feedback

[jacobgkau]

This seems to stop working after a display is connected or disconnected. E.g. it works on a laptop (oryp8) with just its internal screen, but no longer shows (even after restarting COSMIC Settings) if I plug in another display. If I boot with two displays, then Settings first shows the OSDs on both, but it no longer shows the OSD at all if I unplug the second display.

I think the OSD's also showing up a little larger than it does in the mockup. Both the current implementation and the mockup had the OSD a little smaller than the date/time in the panel, but the date/time in the mockup's much shorter since it was an older version with an abbreviated month and no "at" word. (In the mockup, the OSD also appears to be smaller than the word "Displays" in Settings, whereas it's larger than that word in the current implementation; just another reference for size.) It doesn't have to be exact, but it might be good to make it a little smaller to better match the mockup for now.

[FreddyFunk]

@jacobgkau oh wow, good catch! I haven't thought about this scenario with the display hot-plugging. I have pushed fixes for that and the visual changes to the OSD pull request.

[jacobgkau]

The visual update looks pretty good. I think it'd be acceptable as-is, but it's still slightly larger than the mockup. Again, use the page's Displays title as a reference-- the mockup had it slightly smaller than that word, while it's still slightly larger in practice. (The small size is intentional since it's stuck on continuously while the settings are open.)

---

Hot updating while plugging/unplugging displays is working. However, I found an issue where it sometimes doesn't show after Settings is re-opened, and then Settings freezes if I try to leave the page.

I can't figure out the exact trigger for this-- it doesn't seem to happen if I wait longer before re-opening Settings, but just re-opening Settings immediately (e.g. before the timer ran out) doesn't guarantee that it'll trigger. But I seem to be able to fairly consistently reproduce it by repeatedly closing Settings with Super-Q and then opening it again right around the time the OSD disappears a second later. It usually seems to happen around my fifth attempt of doing that.

@FreddyFunk Are you able to see that problem occur by doing that?

[FreddyFunk]

I was able to reproduce this error by rapidly moving opening the display page, then any other settings page and then the display page again in a loop to reliably recreate the bug. The debugging took me down a rabbit hole and I found a bug in the pop-os iced fork used by libcosmic used by cosmic-osd. This bug caused a Wayland layer-shell protocol violation: "must ack the initial configure before attaching buffer" which occurres when rapidly creating and destroying layer surfaces.

I have opened a pull request for the fix here: pop-os/iced#250

Once this is merged, libcosmic needs to be updated with the new iced version and then I can update the libcosmic version in the cosmic-osd pull request that is linked to this pull request here.

[FreddyFunk]

I tweaked the visual size of the OSDs again. Hopefully I managed to get this nailed down now.

[FreddyFunk]

I updated libcosmic on the OSD pull request which includes the previously mentioned iced fix. This can now be tested again.

[jacobgkau]

The updated size looks perfect. The OSD also seems to show reliably every time now.

I noticed that if I have the Displays page open, attempting to launch a different page (like Bluetooth) from the Launcher often fails, especially if I'm coming from another workspace (but also often on the same workspace). The Displays page and OSD flicker, but the Displays page remains open. That's a regression.

[FreddyFunk]

I was able to reproduce the bug and pushed a fix for that.

[jacobgkau]

On c58dd10, the bug I described seems to be partially fixed when testing with the Bluetooth page, but it's still happening when I test with the Desktop page. (E.g. if Displays is open, attempting to go to the Desktop page via the Launcher flickers and stays on the Displays page.)

It also still happens sometimes with the Bluetooth page if I'm using the Launcher from the same workspace Displays is open on.

[jacobgkau]

Actually, what I'm seeing now might not be a regression. I'm seeing similar behavior with other pages on another branch of cosmic-settings now.