Multiple monitors wallpaper handled as only one big monitor.

Bug #1730411 reported by Hans P. Möller on 2017-11-06
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
LXQt
New
Unknown
pcmanfm-qt (Ubuntu)
Wishlist
Unassigned

Bug Description

When using multiple monitors you can only chose one wallpaper and it is handled as only one big monitor. openbox+lxde works fine but openbox+lxqt does not.

Also see here for tracking a more permanent solution, as the upstream linked bug may not result in something quite as robust as one would like:
https://phab.lubuntu.me/T54

Simon Quigley (tsimonq2) on 2018-02-05
Changed in lubuntu-next:
status: New → Triaged
importance: Undecided → High
Simon Quigley (tsimonq2) on 2018-02-28
Changed in lubuntu-next:
importance: High → Medium
Simon Quigley (tsimonq2) on 2018-02-28
tags: added: upstream
Walter Lapchynski (wxl) wrote :

That upstream bug seems to suggest there's no such problem in openbox?

Walter Lapchynski (wxl) wrote :

In any case, this ideally is a WM issue, reading that upstream report.

affects: lubuntu-next → openbox (Ubuntu)
Hans P. Möller (hmollercl) wrote :

lxde also uses openbox and you can put different wallpapers for each monitor. When you change the wallpaper it only changes the one in which you have done the right click with the mouse.

Hans P. Möller (hmollercl) wrote :

Apparently this issue also happens in gnome (I haven't used gnome since 2000 and never in 2 monitor environment). In a youtube video they recommend to use hydra-paper https://github.com/GabMus/HydraPaper/ to "create" the wallpaper merging the 2 images in one and use this as wallpaper.

So, maybe the best/simple solution is to include a good wallpaper manager in lubuntu next.

Here is the video https://www.youtube.com/watch?v=3svfVEiOCBU&t=329s

description: updated
Walter Lapchynski (wxl) wrote :

I actually apparently didn't read that bug correctly. The issue is not the window manager at all. It's pcmanfm-qt. Just as with LXDE, the desktop (read: wallpapers) are managed by pcmanfm (see the --desktop switch, which we run by default).

That said, this is an upstream issue that will require a non-trivial fix, especially as they are trying to be agnostic in relation to components, meaning not just the window manager but also the display server so it's a bit of a rabbit hole:
https://github.com/lxqt/lxqt/issues/1175#issuecomment-253859198

affects: openbox (Ubuntu) → pcmanfm-qt (Ubuntu)
Walter Lapchynski (wxl) wrote :

Too bad HydraPaper is GTK. We probably need something lighter. feh can certainly handle this but it's a little cludgy (CLI only) but maybe we can make a little script. There's a bunch of other options to explore, too:
https://wiki.archlinux.org/index.php/List_of_applications#Wallpaper_setters

Someone who readily uses multiple monitors needs to test this stuff and report what works. If we do get a good solution, I'd be inclined to include it with the expectation that we'll eventually remove it once upstream figures things out.

Hans P. Möller (hmollercl) wrote :

I tried all the wallpaper setter that are in ubuntu repositories: Feh, Nitrogen and Variety. Nitrogen and Feh are able to manage the 2 monitors w/o problems and variety runs in backround continuously changing wallpaper, and I couldn't find out how to manage multiple monitors.
The downside is that all of them required to kill "pcmanfm-qt --desktop".

Walter Lapchynski (wxl) wrote :

Keep looking for a good workaround, Hans. Perhaps the cron job that checks to see if the wallpaper has changed and then uses imagemagick to make it the right size for the "one monitor" will solve the issue, but it's not a good permanent fix. Looking outside of pcmanfm-qt has ultimately led us right back to it. Because of that, I'm going to set the importance to wishlist.

I just left a comment at the upstream bug in hopes of spurning development. The long story short is that there's no consistency among window managers and so detection is necessary, but they are reluctant to make a dependency on an X11 component to do this (cuz Wayland). I suggested we simply make a non-default compile time flag to turn this on. Hopefully that will be enough to encourage them to do the work for the immediate need. I can't imagine the code they write won't be in some way useful when Wayland comes around.

Changed in pcmanfm-qt (Ubuntu):
importance: Medium → Wishlist
Walter Lapchynski (wxl) on 2019-04-14
description: updated
Changed in lxqt:
status: Unknown → New
Hans P. Möller (hmollercl) wrote :

I forgot adding the current workaround which is here:
https://code.launchpad.net/~hmollercl/stitchwp/+git/stitchwp

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.