Desktop Icons Disappear on Multi-Monitor

[tiredofit]

Cinnamon 3.2 OS: Arch X; Nvidia Driver

Running a triple monitor setup, with icons on all 3 screens. Randomly icons disappear. In order to restore, required to visit Desktop Settings, Disable Icons on all Monitors, and then Reenable Icons on all monitors.

[Wini-Buh]

I think it's the same problem I described here linuxmint/cinnamon#5973. I could reproduce it easy with help of a virtual machine (I used VirtualBox to check if the problem is reproducible).

At least your work-around to disable icons on all monitors, and then re-enable icons on all monitors works for me (at the moment).

[itzexor]

Pressing F5 with the desktop focused will refresh it and make the icons show up. Not a solution but a more convenient workaround for the time being.

[moretocome]

Same problem as described, thou disabling and re-enabling the icons does nothing, nor does pressing F5 with desktop focused. Cinnamon 3.07 Linux Mint 18 Nvidia driver

[xonxor]

I can confirm this problem with my 3 monitor setup as well. Both above workarounds provided by OP and @itexor work for me (certainly not long term solutions). This issue first appeared when I upgraded to 18.1 using the upgrade manager. Never had any problems of this sort in Linux Mint 18. The Cinnamon version I'm using is 3.2.7 and I use the Nvidia proprietary driver.

[carontiello]

Same problem and pressing F5 on desktop focused, in the meantime, work for me. Cinnamon 3.2.7 Linux Mint 18.1 x64 Intel Integrated Graphics Controller with triple monitor

[jameshibbard]

Same problem here. Mint 18.1, cinnamon. F5 fixes it for me, but more often than not the icons are in random positions.

[LaurentOngaro]

same problem, 3 monitors, icons disappear randomly, F5 or changing icon settings can fix it mint 18.1 x64 cinnamon 3.2.7 AMD HD 7850

[primawill]

I am also having this problem. Linux Mint 18.1 Dual monitors, AMD Phenom II x4,Nvidia GTX260, Cinnamon 3.2.7

[jameshibbard]

Bizarrely, I have found that arranging desktop icons in vertical lines (not horizontal) means that they don't get rearranged when I press F5

[mariuszpass]

I am also having this problem. Dual monitors with diffrent resolution: first one: 1920x1080, second one 1080x1920

[primawill]

As it turns out, I think I may have found out what is causing the problem. I prefer to have my primary monitor on the Right side, and use the left side as my secondary. Upon switching the left to primary and right to secondary the issue went away.

So I experimented with swapping the cables on the monitors thinking whichever monitor was plugged into the DVI-1 spot should be as the primary. That is not the case. Problem still persisted whenever the right side monitor was made the primary, even after swapping the cables.

So my conclusion: If you are using dual monitors, the left side should be the primary and the right side secondary.

[nsoulantikas]

My setup: Kernel: 4.4.0-77-generic x86_64 (64 bit gcc: 5.4.0) Desktop: Cinnamon 3.2.7 (Gtk 3.18.9-1ubuntu3.3) Distro: Linux Mint 18.1 Serena Graphics: Card: Advanced Micro Devices [AMD/ATI] Thames [Radeon HD 7500M/7600M Series] bus-ID: 01:00.0 Display Server: X.Org 1.18.4 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1366x768@60.02hz, 1920x1080@60.00hz, 1920x1080@60.00

3 monitors and the desktop icons disappear when i turn off the primary monitor. It mostly happens for the right click not to work. Initially i switch the monitor settings (where to show icons) but the right click stops functioning.

[feugy]

What Nsoulantikas describe is still with cinammon 18.3

[t-hofmann]

Setup:

• two monitors
• LinuxMint 18.3, Cinnamon

Symptoms on right monitor:

• no right click
• no desktop icons regardless of which monitor is the primary.

Side-note: Using xrandr to scale and position, but no difference if beeing executed or not.

[FrancescoBorzi]

I'm having the same issue using Nemo on Ubuntu 20.04 with 2 displays.

I managed to mirror the icons by right-clicking on the empty desktop and choosing "Customize". However, now I can no longer find a way to open the "Customize" options of my desktop.

EDIT: actually it's not mirrored, but I have to press F5 in order to update one desktop whenever I drag an icon to another desktop

[aplatypus]

Yes -- #metoo since the recent updates this week. Desktop icons vanish and application windows all "gather in the same monitor" with a multim monitor set-up.

ANYWAY ,,, I would like to float the concept that Desktop configuration SHALL BE transparent.

My second point is more useful. You can "get your icons/shorcuts" back as follows.

• identify the file matching the missing desktop icon
• ls -l ~/Desktop/*.desktop
• Rename it ...
  • mv -v ~/Desktop/01_example.desktop ~/Desktop/02_example.desktop
• 'Something' picks that file name change and the logo reappears!!
  • Unfortunately touch does not work. It must be a rename (mv) or a copy (cp).
  • Go figure!!

I'm also a little mystified by the "community attitude" to Desktop as a concept. Maybe I need a blog. My second job was at a university and they had two(2) Lisa workstations. They had a desktop. After working on a Cray design CD mainframe it was like a shot of some kind of illegal substance!

I have never been clear on any direction that chooses to 'remove' a desktip as a metaphor without offering an alternative. In later life I studied the area of behaviour about consumer choices. So far no one ever created a ground swell of adoption with designs that refused to meet the preferences of the 'influencers' and 'mainstream' customer.

Remember the take-up and resounding success of Windows 8!???

• NO?

Exactly the point.

[robertwhitton]

I struggle to believe that this is still broken since it was first reported in 2016 - this is pretty basic stuff.

Desktop icons are basically an unusable feature at the moment as far as I can see. I have all of the issues mentioned above. With icons disappearing, icons randomly moving about etc. The F5 refresh will sometimes recover icons but the original ordering is lost.

There are also other problems. The icon ordering changes whether they are on the primary monitor or not. If I ask for the icons to be on both monitors then I get some of them on the primary and some of them on the non-primary but none of the icons appear on both. I can't see any commonality between the icons it puts on each monitor - it's truly bizarre.

I'm more than willing to help debug this issue if there are any tests that I could run or any command output that would prove useful.

It's pretty easy to provoke problems by using the desktop settings to move the icons between monitors.

I have attached some screenshots showing some of the problems using this technique. These are in time order. I start with my desktop icons ordered how I like with them on the non-primary monitor (left half of the screen capture). Then I move the icons to the primary monitor. Oops they all get reordered. Now I move them back to the non-primary - they get even crazier. Finally I ask for the icons to be on both monitors and the set of icons seems to get randomly split across both monitors.

[robertwhitton]

I should have added that I obtained the above results in LM20/Cinnamon 4.6.7

[felagund]

Any time I unplug a monitor from my laptop, icons get missing. F5 brings them back, but their positions get reset :-(.

Ubuntu 20.10, under Unity.

[Auravendill]

I think, the bug I have is mostly the same, although the results are a bit different: (Nearly) everytime the lockscreen/screensaver starts or sometimes after a reboot, all the icons get reshuffled in some way. Sometimes they all appear only in one quarter of the main screen, sometimes they are banished from the main manitor to the two smaller ones . If this happens they are even sometimes overlapping or at positions, that the grid wouldn't allow.

At least sometimes f5 returned the order to the one, I created.

cinnamon 4.8.6 nemo 4.8.6 Debian 11 Kernel 5.10.0-6-amd64 AMD GPU

[s-m-e]

Another "me-too". Dual-monitor setup, right-hand-side monitor is primary, icons are supposed to be arranged in rows. I am running Linux Mint 20.3 with Cinnamon and all updates as of today applied.

The expected unexpected behavior: After logging out and logging back into Cinnamon (with or without reboot in between does not make a difference), all icons are gone. Sometimes, only the files and folders are missing - stuff like "trash", "home folder" or "network" may actually appear instantaneously, though this happened only a few times.

Workaround: The F5 trick works for me; all files and folders show up again while their original position is lost.

Clues: When hitting F5, the previous positions of files and folders are "lost" - but not those of other stuff like "trash", "home folder", "network" etc. The latter icons come back in their previous spot. The files and folders show up in rows starting from the top left corner. Interestingly, they appear to maintain some kind of stable order across many logins - it's certainly not alphabetical or similar.

Can I help? I'd love to have a look at the code. I'd greatly appreciate if someone could point me at the (potentially) relevant sections.

[mtwebster]

I struggle to believe that this is still broken since it was first reported in 2016 - this is pretty basic stuff.

No, it's not.

It's difficult for nemo to distinguish between events that change the size of the area that's available to place icons.

• Panel height changes
• New panels/removed panels
• New monitors/removed monitors
• Resolution changes
• Resuming from hibernate/sleep
• Desktop (cinnamon or whatever panels) restarting
• Logging in

Sometimes these events can be triggered multiple times in quick succession. Each time any of these events occurs, nemo needs to decide whether this change is temporary or permanent and what to do about stored icon positions - it's trying to maintain the user's desired spacing while keeping the icons centered. Clearly it falls down in this decision-making at some point.

A great deal of time was spent at one point trying to improve the desktop experience by allowing you have a variable placement grid, layout direction, primary/all monitors, etc.. which I think works for most people but utterly fails for others - although we tried to do our best to handle this case, it seems to be those users with monitor layouts that change frequently.

I have one or two relatively simple ideas that may help this situation that I'll try to maybe get a test build out soon.

Can I help?

I really appreciate the offer. Unfortunately it's complex to the point that I'm going to have to spend a few hours refamiliarizing myself with the relevant sections of code just to work on these changes. The toplevel 'window' is nemo-desktop-window.c. Most of the desktop layout handling occurs in nemo-desktop-icon-grid-view.c, nemo-icon-view-grid-container.c, nemo-centered-placement-grid.c. Each monitor is a canvas with the icons positioned from the upper left corner. All position info is stored in a file's metadata (you can view it using gio info <filename>. The metadata for the desktop itself, which stores grid spacing, auto layout, etc... is in ~/.config/nemo/desktop-metadata

[s-m-e]

[...] it seems to be those users with monitor layouts that change frequently

Other than for trouble-shooting this issue, I have not changed my layout at all. So this kind of does not hold up for me at least.

My system can not hibernate in any form, so it's just simple logout/login sequences or reboots. Monitors attached via DVI to Mini-DP-port adapters. Open source AMD driver on AMD card, by the way - on Nvidia-GPU-based systems with proprietary driver I do not see this issue ironically, also Mint Cinnamon with really similar configuration. I am saying this because the Nvidia driver was/is infamous for causing such issues in KDE. Interestingly, for the Nvidia drivers to work properly, one usually needs to disable kernel mode setting, which remains on when using AMD open source drivers. Maybe this is another clue.

I really appreciate the offer.

Let me know if I can help, even if it's "only" by testing your builds on my system.

gio info <filename> and ~/.config/nemo/desktop-metadata are two interesting pointers - thanks. So the desktop-metadata appears to be mostly reliable in my case while the stuff in the files' metadata somehow always falls apart.

Interestingly, the longer I use Cinnamon, the more often I see events where all desktop icons actually survive a logout/login sequence and no pressing of F5 is required. It's about a 1 in 20 chance in my case, but no real pattern. A timing / thread issue?

Speaking about files' metadata: Where / how is this information stored? We're not talking about xattr, are we? Instead, it's the stuff in ~/.local/share/gvfs-metadata/, I presume?

[mtwebster]

Yes it's kept in gvfs-metadata.

I remember first getting some monitors where I could finally try out displayport with my nvidia card.. and a couple of weeks later I was digging thru my box-o-cables to switch back to hdmi and haven't bothered again since. Half the time I couldn't get one or both monitors to wake up after they went into powersave. Also ref https://github.com/linuxmint/cinnamon-settings-daemon/pull/178. This sort of behavior also would mess up my desktop icons as well.

Would you mind giving me the output of:

dconf dump /org/nemo/

and the contents of ~/.config/nemo/desktop-metadata

You mentioned F5 causing repositioning, but it should actually have no effect, and doesn't for me, no matter how I set up my desktop. So I'm a bit curious about that.

Thanks

[ghost]

Either the desktop-metadata thing is a red herring or something is rotten in... Cinnamon (not Denmark).

I tried the elegant way by building a simple program to watch for changes to that file according to this page. No results whatsoever.

Then tried the command line as mentioned here - the part with notify-send: inotifywait -mrq -e create -e modify -e delete $HOME/.config/nemo/desktop-metadata | while read file; do (notify-send "File updated: $file"&) done No results whatsoever. (maybe the while read file part is wrong...?)

Then I simply opened the file in Xed, knowing that on each change to an open file it would show a notification banner asking to reload it. No results whatsoever.

For all the above tests I tried moving a random icon from one position to another. And back after a while. It was like nothing happened, no change to the file.

Then I pressed F5 on the desktop. It updated a bunch of icons that previously didn't bother to show the lock emblem corresponding to target files being located on a read-only partition even after a few Cinnamon reloads. After this operation Xed finally woke up and displayed the 'file changed' banner.

Interestingly though, while running the C script in the first test and pressing F5 on the desktop it did sense changes and output the following:

File meta data changed
File is deleted
File monitor has been removed

Before that, the inotifywaitcommand in test 2 above did not react in any way to the F5 keypress.

Wanted to mention that I would've tried the inotify-hookable command too (mentioned somewhere here) but when I saw how many dependencies it was asking to install I just uttered the shortest and most efficient prayer in the world (according to Sir Anthony Hopkins' character in the 360 movie) and went on.

And that's about all for now.

[mtwebster]

I suppose I wasn't clear enough.

Nemo sees the desktop 'view' as a location expressed as x-nemo-desktop:/// (for comparison, the root of your filesystem is file:///. This location doesn't really exist anywhere, except in nemo at runtime, so it uses nemo-desktop-metadata to store information about the each monitor (in the file, see entries labeled [desktop-monitor-nn] - things you can customize about the view.

There are a few icons on the desktop that also don't exist anywhere except - Computer, Trash, direct links to mounts. If you modify these, that data also gets stored in nemo-desktop-metadata, for lack of anywhere else to put it. The 'Home' folder is treated like a special folder also for the purposes of the desktop, even though it is real.

On the other hand, actual files and folders have their metadata stored by gvfs with the files themselves. You'd have to monitor those individually to see their metadata updating (man gio).

so:

• fake items, actual desktop details, nemo-desktop-metadata
• real files, gvfs metadata

[ghost]

You're not making any sense (to me). It may be my fault. Let's try again:

I have 10 icons on my desktop. I move one of them to a different location. How do I capture this movement and get a notification about it? Or in other words: where is this icon's position stored and read from? In an individual file that I should know all details about from my crystal globe, not in a generic desktop environment that could be watched for any changes? I thought desktop-metadata was the almighty storage location but apparently not so much.

The really important question: why is this desktop thing treated like a child? I mean: all that data should be stored in purely binary form readily readable by the machine - not in humanly readable form that takes a lifetime to convert and process. It'd be hilarious if it weren't tragic.

I'm utterly dissapointed. Gonna shut up coz the things I'd say wouldn't be very nice.