Improve external monitor handling.

[PCMan]

When a new monitor is plugged in, we need to show the tool to configure it.
Besides, the tool should be on the primary monitor.
We also need to handle the case when the external monitor is reomved, too.

[capkaverne]

And fix the issue where lxqt-panel iconify the bottom panel and the whole
desktop, crash the widgets and task managers icons when a new monitor
configuration is applied.

On Sat, Jul 19, 2014 at 3:50 PM, PCMan notifications@github.com wrote:

When a new monitor is plugged in, we need to show the tool to configure it.
Besides, the tool should be on the primary monitor.
We also need to handle the case when the external monitor is reomved, too.

—
Reply to this email directly or view it on GitHub
#239.

R.

[Vladimir-csp]

I once created an xrandr wrapper daemon for own use (https://github.com/Vladimir-csp/rerandr) and would like to share some thoughts.
In general, xrandr command in XDG autostart won't do. There should be a daemon, it should react to display-related events and act according to user-preferred model.
It should classify outputs as internal (like LVDS) and external (HDMI, VGA, etc).
Basic model: use only externals, fallback to internals if there aren't any externals
Other models: use everything, custom, etc
Submodels: clone, side-by-side, saved presets.
Presets can be saved based on monitor models, or combination of resolutions. So plugging in some known devices should trigger saved preset with saved orientations, dpi's, etc.

Changing configurations should be incremental, e.g. "enable needed outputs, then disable unneeded", not "disable everything, enable what is needed". In the latter case window placement would most certainly be messed up. General rule of thumb: during transition there should always be some enabled output (unless there is only one CRTC available on the video device). By the way, daemon should also check availability of CRTCs not to run out of them. Xrandr has a bug: it does not free CRTCs first (https://bugs.freedesktop.org/show_bug.cgi?id=29929)

Hope, some of it helps.

[jleclanche]

Nobody picked this up, moving to 1.0.

[Vladimir-csp]

I've created another multimonitor handler in bash. https://github.com/Vladimir-csp/rerandr3
Well, it's pretty dirty, but it illustrates the concept of known setups from my previous message. When run as daemon it listens to hot-plug events and tries to either apply known configuration or enable/stack everything in auto.

One of my users shot himself in the foot recently because of static xrandr in XDG autostart: changed monitor, booted, logged in - out of range!

[jleclanche]

@Vladimir-csp take a look at kscreen. They have a daemon that does exactly that (although it is outside the framework).

[jleclanche]

also see #502

[Vladimir-csp]

...tried to install kscreen package in Debian, it pulls in 105MB of dependencies in 67 packages... Ouch.

[jleclanche]

libkscreen is what you need, not kscreen. libkscreen should have no dependency outside of qt.

[Vladimir-csp]

Unfortunately my coding skills are limited to Bash, so I can not take advantage of the library yet.
With quick googling I couldn't find whether kscreen saves setups based on display models/serials, or just outputs combinations. If such feature can be included in lxqt with libkscreen, it would be perfect!
Use case: Multimonitor setup A at work, different multimonitor setup B at home. Save once, then just plug and play.

[capkaverne]

In ubuntu

sudo apt-get install libkscreen
...
E: Unable to locate package libkscreen

sudo apt-get install libkscreen-dbg
...
The following NEW packages will be installed:
libkscreen-dbg libkscreen1 libqjson0 libqt4-dbg
....
Need to get 117 MB of archives.

is this the package libkscreen-dbg ?

On Mon, Feb 16, 2015 at 1:32 PM, Vladimir-csp notifications@github.com
wrote:

Unfortunately my coding skills are limited to Bash, so I can not take
advantage of the library yet.
With quick googling I couldn't find whether kscreen saves setups based on
display models/serials, or just outputs combinations. If such feature can
be included in lxqt with libkscreen, it would be perfect!
Use case: Multimonitor setup A at work, different multimonitor setup B at
home. Save once, then just plug and play.

—
Reply to this email directly or view it on GitHub
#239 (comment).

R.

[Vladimir-csp]

No, that was kscreen with lots of KDE dependencies.
libkscreen1 wants 7 packages, 2.8MB, 10.9MB unpacked
(libattica0.4 libdbusmenu-qt2 libdlrestrictions1 libkdecore5 libkdeui5 libkscreen1libqjson0)

[kuzmas]

@RcMn
I guess you need libkscreen1 for runtime and libkscreen-dev for development.

[jleclanche]

libattica0.4 libdbusmenu-qt2 libdlrestrictions1 libkdecore5 libkdeui5 libkscreen1libqjson0

That's far more than it actually requires...

[kuzmas]

In short:

Depends: libc6 (>= 2.14), libkdecore5 (>= 4:4.5.85), libkdeui5 (>= 4:4.5.85), libqjson0 (>= 0.7.1), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.6.1), libstdc++6
         (>= 4.1.1), libx11-6, libxcb-randr0 (>= 1.1), libxcb1 (>= 1.6), libxrandr2 (>= 2:1.2.99.3)

In full:

<user>@<host>:~$ aptitude show libkscreen1 libkscreen-dev

Package: libkscreen1                     
State: installed
Automatically installed: yes
Version: 1.0.5-0ubuntu1~ubuntu14.04
Priority: extra
Section: universe/libs
Maintainer: Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 392 k
Depends: libc6 (>= 2.14), libkdecore5 (>= 4:4.5.85), libkdeui5 (>= 4:4.5.85), libqjson0 (>= 0.7.1), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.6.1), libstdc++6
         (>= 4.1.1), libx11-6, libxcb-randr0 (>= 1.1), libxcb1 (>= 1.6), libxrandr2 (>= 2:1.2.99.3)
Conflicts: libkscreen1
Breaks: libkscreen0, libkscreen0
Replaces: libkscreen0, libkscreen0
Description: library for screen management - shared library
 The KDE multiple monitor support is trying be as smart as possible adapting the behavior of it to each use case making the configuration of monitors as simple as
 plugging them to your computer. 

 This package contains the shared library
Homepage: https://projects.kde.org/projects/playground/libs/libkscreen

Package: libkscreen-dev
State: not installed
Version: 1.0.5-0ubuntu1~ubuntu14.04
Priority: extra
Section: universe/libdevel
Maintainer: Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 84.0 k
Depends: libkscreen1 (= 1.0.5-0ubuntu1~ubuntu14.04), libqt4-dev
Conflicts: libkscreen-dev
Description: library for screen management - development files
 The KDE multiple monitor support is trying be as smart as possible adapting the behavior of it to each use case making the configuration of monitors as simple as
 plugging them to your computer. 

 This package contains the files necessary for development.
Homepage: https://projects.kde.org/projects/playground/libs/libkscreen

[paulolieuthier]

As @palinek said in #600, we can create a daemon that would listen to screen changes and could react. I think it can be easily done as part of lxqt-config-monitor. We could create a flag --daemon for it. On screen changes, it could show a simple dialog asking what to do (or possibly do it automatically).

[Vladimir-csp]

The dialog could pop up on unknown display combinations with a choice to either "Apply and save" or just "Apply". If save is chosen, the daemon would not produce dialog if this combination is seen again, just apply saved configuration.
Configurations could be saved by string consisting of ports and display vendors, models and s/n, something like:

LVDS1-x-x-HDMI1-DELL_P2211H-922RN192B2LM-VGA1-DELL_P2211H-922RN192BJ4M

There also should be some timeout or a way to automatically cancel the dialog when known combination is reached through unknown combination. I.e. when user consequently plugs in multiple external monitors.

[Vladimir-csp]

...in fact, forget the serial numbers.

[luke-jr]

libkscreen should have no dependency outside of qt.

Oh, it very much does: Wayland stuff. I just opened #1068 here as a result...

[Vladimir-csp]

Here is a great and lightweight tool: https://github.com/phillipberndt/autorandr no dependencies except x11 utils and python. Has profiles, hooks, auto actions, just works. Could act as a backend for lxqt-config-monitor.