Moving lxqt-config-monitor to KScreen

[jleclanche]

TLDR: I've been working all night on moving lxqt-config-monitor to the KScreen framework. These are my notes.

I was playing with my laptop and xrandr and I had to add a custom mode through the xrandr command line. I then noticed lxqt-config-monitor couldn't pick it up as it expects a resolution when in fact it's getting a mode name. I tried to look at fixing it but discovered that the code is an absolute mess. The entire thing relies on parsing xrandr command line output in --verbose mode. It's incredibly nasty.

Fortunately the KDE folks have an excellent KScreen framework. It has virtually zero dependency and has support for pluggable backends. This is necessary if we're ever going to move to wayland; although we have a concept of a backend in lxqt-config-monitor right now, the entire thing relies on passing string data around which is a huge no-no.
The main KScreen dev is also wonderfully responsive.

We have to do some user-facing changes though. This isn't just switching one backend for another.

• We lose gamma settings. We can get gamma through EDID but not set it. I hope this can be corrected, although setting gamma belongs in more advanced settings...
• Refresh rates need to be coupled with resolutions. In KScreen, you can only get/set modes, not individual resolution/rate (for good reason too). This does make the job a bit more complex in getting available rates for a resolution.
• This is a good occasion to improve the UI. I want to get rid of "Unify all monitors", it's a weird option which belongs in quick options. Rate and resolution should be on the same line. The screen list could get icons representing the type of screen that is there.
• We can also start showing unplugged screens. Food for thought.
• Positioning monitors with the mouse is neat, but it has to be improved. The code for it is super nasty too.

Also: Right now, the save button writes an autostart file to start xrandr with the given config; something we're inheriting from lxrandr. Not only are the paths hardcoded etc but it's also not the expected behaviour from the user at all. It will result in flicker at login time and there's no way to ever know this is why.

I'll push some branched work at some point this week. Anyone interested in helping with this?

[PCMan]

I'd suggest that you talk to @selairi before going further in case he is doing the same thing.
Maybe he already had some work in progress.
About the points you mentioned:

1. Gamma setting can still be done through xrandr
2. What's the good reason? Listing all modes at the same time clutters the UI Currently we only show available rates for a resolution, too. So it's not possible to select an invalid mode.
3. The option comes from the original lxqt-config-randr. I believe that @selairi has some ideas to improve it.
4. Showing unplugged screen is not necessarily a good idea. It creates confusion and clutters the UI. Besides, there is no correct way to detect when a monitor is plugged in. The only reliable way I know is polling, which is quite inefficient.
5. Agree, the positioning UI needs some improvements.
   About xrandr, I think it's a reasonable way and there will be something equivalent for wayland later.
   It's both lightweight and desktop independent so can be used outside LXQt.
   The flicker is not a problem. Different users might need different resolutions.
   As this is a user-specific config, we can only know the settings "after" login.
   If the mode the user want is different from the one used by the display manager or the previous user, there will be a flicker. This is almost inevitable, however, if we want to support different modes for different users.

[jleclanche]

Some extra notes I forgot.

• We lose brightness and backlight (unless we hard set with xrandr). Again I believe this is OK because those are settings the users will want to control from somewhere else. They don't belong there.
• Wayland is a bit problematic. There is nothing like xrandr for wayland, gnome uses a port of their xrandr wrapper to dbus there.

The only reliable way I know is polling, which is quite inefficient.

I think KScreen actually solves this.

[heliocastro]

So

My proposal, is there something missing on kscreen that is neede any
feature ?

I will do the code and push for review in KDE, if necessary, otherwise I
can commit myself as soon is a reasonable request.

Helio

On Mon, Feb 16, 2015, 03:34 Jerome Leclanche [email protected]
wrote:

Some extra notes I forgot.

• We lose brightness and backlight (unless we hard set with xrandr).
  Again I believe this is OK because those are settings the users will want
  to control from somewhere else. They don't belong there.

• Wayland is a bit problematic. There is nothing like xrandr for
  wayland, gnome uses a port of their xrandr wrapper to dbus there.

  The only reliable way I know is polling, which is quite inefficient.

I think KScreen actually solves this.

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

[jleclanche]

An API to get/set gamma would be nice.

[Vladimir-csp]

Can it recognize unique setups based on monitors` models and/or serial numbers?

[danvratil]

Hi,

KScreen dev here ;) I'm really glad that KScreen found it's use outside KDE, and I've got a few comments (or rather observations) related to our past experience with working with screen management...

We lose gamma settings. We can get gamma through EDID but not set it. I hope this can be corrected, although setting gamma belongs in more advanced settings...

I'm fine with implementing this in KScreen. I actually had to check if we even have this option in KDE...and found that we don't, or it's very well hidden :)

Refresh rates need to be coupled with resolutions. In KScreen, you can only get/set modes, not individual resolution/rate (for good reason too). This does make the job a bit more complex in getting available rates for a resolution.

What we do in KScreen KCM (the UI for KScreen in KDE) is that we actually hide the refresh rate combobox into "Advanced options" and always default to "Auto" value. Users rarely need to change that and "the higher the better" is usually the right heuristics to figure the right refresh rate automatically :)

In the general UI we only show slider to change resolution. In XRandR, certain modes are marked as "preferred" - those are usually monitor's native modes (mode = resolution + refresh rate - you can have multiple modes with the same resolution, but different refresh rate). When user chooses a resolution which is in the preferred modes list, the "Auto" refresh rate refers to the preferred mode with such resolution. When users chooses a resolution which is not "preferred", we fallback to choosing the highest refresh rate as the "Auto" value.

Finally, this can be implemented rather easily through model + QSortFilterProxy, or, since the amount of modes is usually reasonably small, it's possible to just iterate over all the modes when users changes resolution and extract the list of refresh rates from all modes with matching resolution.

When applying, you just iterate over the modes again and find the one with matching res and refresh rate. IIRC this is how we do it right now in KScreen, mostly because I'm being lazy to write the model ;-)

This is a good occasion to improve the UI. I want to get rid of "Unify all monitors", it's a weird option which belongs in quick options. Rate and resolution should be on the same line. The screen list could get icons representing the type of screen that is there.

The first versions of KScreen did not have any "Unify" button - to clone screens, you had to drag one screen in the UI on top of the other. Although this seemed logical and easily discoverable to me, turned out I couldn't be more wrong. Users struggled to discover this "feature" and complained constantly, which forced us to actually have a "Unify" button in the UI.

Positioning monitors with the mouse is neat, but it has to be improved. The code for it is super nasty too.

If you are using QML, you can probably steal most of our code from KScreen KCM. It's ugly, dirty, but it works :) Or let me know when you write it yourself, I'll happily steal it from you into KScreen :-)

Also: Right now, the save button writes an autostart file to start xrandr with the given config; something we're inheriting from lxrandr. Not only are the paths hardcoded etc but it's also not the expected behaviour from the user at all. It will result in flicker at login time and there's no way to ever know this is why.

Note that you won't ever get rid of the flicker - sometimes it's necessary to turn off all screens and re-enable them again one by one (for instance when you run out of CRTCs or don't have any free compatible CRTCs left).

Finally, there are currently couple bugs in Qt 5 that are hitting us hard, so just that you know: QTBUG-42985 - all Qt 5 apps crash when there are no screens available (during reconfiguration for instance, as explained above). Secondly there's QTBUG-40207 - Qt polling hardware on start & on every screen change. This is superslow in XRandR (the call can take up to two seconds or even more, depends on HW and drivers), so it blocks event loop of all Qt apps for considerable amount of time and hogs X server. I'm planning to hack on that a bit inside Qt ;)

Regarding Wayland support: in Wayland screens are managed by compositor, so in order for KScreen to be able to talk to compositor, a new protocol has to be defined. I talked about this briefly with some people - the current situation being that Wayland devs don't really want screen management to be part of the main protocol (it should have only rudimentary informations about screens, I guess more or less what's exposed by QScreen in Qt right now), which I agree with. I talked with GNOME people and they don't feel real need for cross-desktop standardized Wayland protocol for full-scaled screen management, which I also kinda agree with. So for Wayland support the current plan is that we will have backend that will be able to speak to KWin through our own Wayland protocol extension for screen management. Of course for that we first need to sit down with KWin devs and discuss how/what to do. I assume LxQt is using KWin as WM/compositor (sorry, I don't really know :)), so you would get Wayland support in KScreen for free. If inter-operability with alternative compositors is desirable and interesting enough, I think it would be great to sit down with other WM/DE devs and figure out some common protocol that would make everyone happy...unfortunately this is a very low-priority issue for me right now most due to lack of time :( If anyone is interested, feel free to contact me :)

[jleclanche]

I assume LxQt is using KWin as WM/compositor

We want to be WM-independent as much as possible. While I don't specifically want something like xrandr to be part of wayland itself, it is a huge mistake imo not to make a proper standardized dbus API for the needs of common mortals... Duplicating all this for every WM? Spare me, please :/

[jleclanche]

So there's two parts to screen management. The first part is what we currently do: an interface to manage screens.
The second part is more involved. We want to be able to react to hardware events. When a monitor is plugged out, we want it to be dropped. When a monitor is plugged in, we want to load its last known working settings.

@danvratil What would you think about a separation of concerns? Currently you have a kded kscreen daemon for that last part. I'm not entirely sure it needs to be that involved. I actually think this functionality should be (mostly) in xorg as it is so maybe it doesn't even need to know about different backends and such. It would just be a small daemon that watches over hardware events and:

• When a monitor device is plugged in, loads its best configuration
  • New device: Apply preferred config
  • Remembered device: Apply last known working config
• When a monitor device is plugged out, drops the screen

This only needs to know when a screen device becomes available/unavailable and whenever screen configuration has changed (so that it can save the difference somewhere). How much is needed for that? If we can do something that doesn't even link to libkscreen, it could be entirely cross-desktop.

[Vladimir-csp]

My daemon becomes less dirty and more feature-rich. https://github.com/Vladimir-csp/rerandr3
I welcome you to estimate some concepts by using my rerandr3 combined with some GUI tool e.g. arandr:

• install rerandr3 to /usr/local/bin/rerandr3, install arandr
• insert udev rule (see instructions inside rerandr3)
• start rerandr3 daemon
• run arandr ; rerandr3 save so rerandr3 will save configuration as soon as arandr exits
• play with cables and monitors

[jleclanche]

I mean rerandr3 is the right concept but I don't think it's the right application, since it depends on the xrandr command line.

[Vladimir-csp]

I'm writing it for personal use anyway. Just offering it for concept testing.

[jleclanche]

@Vladimir-csp I didn't mean to be snarky. I love that you're working on it :)

[jleclanche]

I pushed my work on the switch-to-kscreen branch.

• Dropped support for saving to an autostart file. I am categorically against that.
• Dropped backlight and brightness support. I'm open to discussion on them coming back in, but I'm currently against them being there.
• Dropped "Quick settings". My goal is that the UI becomes simple and adaptative enough that it's no longer needed.
• Dropped "Auto" from resolution and refresh. The preferred resolution is now always first and always bolded.
• Moved refresh rates under a new "advanced settings" tab.
• Added rotation support in the advanced tab.
• Dropped support for positioning things by hand. I'm not against it coming back in the advanced settings, but it'd need to be rewritten anyway.
• Dropped the "Unify all outputs" setting. It's confusing.
• Dropped support for setting gamma. I want this back in the advanced settings once KScreen supports it.
• Moved bits and bobs around to make the UI less confusing
• Setting primary monitor is now done with a checkbox inside the now-much-emptier monitor UI.
• Almost all redundant parts of the UI disappear when there is only one connected output.

This is what it looks like now:

Another nicety is that it now nicely fits on 640x480 screens.

It's not perfect yet. I still have some size adjustment issues and the x/y positioning spinboxes are still a bit too confusing to my taste. I'd also like to add icons to the output list on the left (I don't know how, and I don't have the graphics available - @intialonso ping?). The apply button should also grey itself off when there is no change to apply.

Also note that actually applying settings doesn't work, so don't use this and expect it to work just yet ;)

[jleclanche]

BTW, I need more human-readable names as well for the outputs. @danvratil any advice?

[Vladimir-csp]

Looks great!
Small layout preview could fit on the left, maybe even on 640x480 screen (or hidable?)

"this screen extends..." and "this screen clones" could be rearranged into streamlined action:

This screen [ is the reference | clones | extends to right | extends to left | extends above | extends below | has custom position ] [ $other_screen_selector]
And below that: [x] [y] fields. activated when "has custom position" is selected.

[jleclanche]

I considered that. I'm not sure it's less confusing though.

It also makes an unsafe assumption l18n-wise regarding positioning of the text. Anything that removes extraneous options is good in my book, as long as users immediately find what they're looking for. If I'm removing "unify all outputs" and the quick clone setting, cloning needs to be immediate to find.

Regarding layout preview.. I don't know. A serious one would have to have a full 2d plane so there's no way that would fit anywhere on that page. We could have a Preview button. But all this raises the question whether it's needed at all. Maybe if I hear more support for it.

[Vladimir-csp]

...a quick mockup:

[jleclanche]

Humour this: What happens when you set Screen 1 to extend right of Screen 2, then you go set Screen 2 to extend right of Screen 1?

[jleclanche]

As a thought, we could reuse the concept of a primary display. So we remove the "Make this the primary display" checkbox, we then have:

[This screen is my primary display]
[This screen clones another display]
[This screen extends another display]

1 would give no further UI elements.
2 would give a dropdown like you're showing, with no x/y spinners
3 would give a dropdown and spinners. The dropdown lets you choose any other screen or "Positioned absolutely". Choosing a screen automatically sets the relevant values in the spinners. Modifying spinner values automatically sets "Positioned absolutely" in the dropdown.

[Vladimir-csp]

What happens when you set Screen 1 to extend right of Screen 2, then you go set Screen 2 to extend right of Screen 1?

The last decision should override previous.

I would place one dropdown with [ primary | clone | extend/overlay ] selection
Below that I would conditionally show:

• for primary: nothing
• for clone: dropdown with other outputs (this variant should sync resolutions, so nothing extra here)
• for extend/overlay:
  • dropdown with other outputs and "custom" item.
  • dropdown with directions (can be greyed out by "custom" above)
  • dropdown with edges to allign with ("top" or "bottom" for "left-of" or "right-of" directions, "left" or "right" for "above" or "below" directions, and also "center". How else could can control that?)
  • spinners (when touched, output is set to "custom", directions and edges are greyed out)

An alternative to this are drag&drop with visual clues. Mockup:

[jleclanche]

Why should there be a difference between clone and overlay?

[jleclanche]

This is what I'm currently running with.

Extending:

Cloning:

Primary just doesn't show anything. I pushed the code.

[Vladimir-csp]

I was also referring to a generic situation: if you disable something, it is better to temporary preserve framebuffer size, and then update it when the whole change is applied.
For example, if you swap one output with another. Or if you change monitor. Or if you change your only monitor, then it is better to save framebuffer size permanently until another monitor is plugged in. (swapping the only monitor on desktop PC?).

[selairi]

Hello,

I was playing with my laptop and xrandr and I had to add a custom mode
through the xrandr command line. I then noticed lxqt-config-monitor
couldn't pick it up as it expects a /resolution/ when in fact it's
getting a mode name. I tried to look at fixing it but discovered that
the code is an absolute mess. The entire thing relies on parsing
xrandr command line output in --verbose mode. It's incredibly nasty.

Could you be so kind to send me your xrandr command? Maybe, I can try to
fix it.

I was not thinkinkg of changing the lxqt-config-monitor backend to Kscreen.

I agree with PCMan that xrandr is a good way. It's lightweight and
desktop independent. In Wayland I was thinking of writing a similar
command line tool, if not available.

Sorry, but I couldn't answer you sooner.

Thanks.

[selairi]

I starting to study switch-to-kscreen
https://github.com/lxde/lxqt-config/tree/switch-to-kscreen branch. I
will send my comments.

I started some changes in the interface (xrandr based), but I stop. I
have pushed some of my changes in the interface to master branch. It
isn't finished, but it works OK. No sense to work on something that will
be destroyed.

El 17/02/15 a las 14:38, Jerome Leclanche escribió:

I pushed my work on the switch-to-kscreen
https://github.com/lxde/lxqt-config/tree/switch-to-kscreen branch.

• Dropped support for saving to an autostart file. I am
  categorically against that.
• Dropped backlight and brightness support. I'm open to discussion
  on them coming back in, but I'm currently against them being there.
• Dropped "Quick settings". My goal is that the UI becomes simple
  and adaptative enough that it's no longer needed.
• Dropped "Auto" from resolution and refresh. The preferred
  resolution is now always first and always bolded.
• Moved refresh rates under a new "advanced settings" tab.
• Added rotation support in the advanced tab.
• Dropped support for positioning things by hand. I'm not against it
  coming back in the advanced settings, but it'd need to be
  rewritten anyway.
• Dropped the "Unify all outputs" setting. It's confusing.
• Dropped support for setting gamma. I want this back in the
  advanced settings once KScreen supports it.
• Moved bits and bobs around to make the UI less confusing
• Setting primary monitor is now done with a checkbox inside the
  now-much-emptier monitor UI.
• Almost all redundant parts of the UI disappear when there is only
  one connected output.

This is what it looks like now:
image
https://cloud.githubusercontent.com/assets/235410/6228947/71ff2bde-b6ba-11e4-8e50-7c7fa33ae8d3.png

It's not perfect yet. I still have some size adjustment issues and the
x/y positioning spinboxes are still a bit too confusing to my taste.
I'd also like to add icons to the output list on the left (I don't
know how, and I don't have the graphics available - @intialonso
https://github.com/intialonso ping?). The apply button should also
grey itself off when there is no change to apply.

Also note that actually applying settings doesn't work, so don't use
this and expect it to work just yet ;)

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

[selairi]

Suggestions:

Other config tools use LxQt::ConfigDialog. Maybe lxqt-config-monitor should use it too. I could implement it. In order to do this, it is necessary to add a method to replace "Reset button" by "Apply button" to LxQt::ConfigDialog class.

A Cancel dialog is needed. I can write it as well.

Finally, I have some problems with git. If I try to clone with:

 git clone https://github.com/lxde/lxqt-config.git

it works. But when I try to list branches, only master branch is listed. And I can not swicth to "swicth-to-kscreen" branch. ¿¿¿???

[palinek]

What did you try? Everything seems to work correctly here:

palco:~/tmp$ git clone https://github.com/lxde/lxqt-config.git
Cloning into 'lxqt-config'...
remote: Counting objects: 3803, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 3803 (delta 8), reused 0 (delta 0), pack-reused 3784
Receiving objects: 100% (3803/3803), 925.58 KiB | 868.00 KiB/s, done.
Resolving deltas: 100% (2758/2758), done.
Checking connectivity... done.
palco:~/tmp$ cd lxqt-config/
palco:~/tmp/lxqt-config$ git show-branch -a
* [master] The last xrandr backend commit. Save settings added. Framebuffer screen size fixed.
 ! [origin/HEAD] The last xrandr backend commit. Save settings added. Framebuffer screen size fixed.
  ! [origin/fast-app-chooser] Delay loading of application icons in the app-chooser dialog for faster loading.
   ! [origin/icon-theme-preview] lxqt-config-appearance/icontheme: String performance enhancements
    ! [origin/lxinput] Rename lxqt-config-mouse to lxqt-config-cursor to reflect what it does. Remove unnecessary desktop entry files and do some makefile cleanup.
     ! [origin/master] The last xrandr backend commit. Save settings added. Framebuffer screen size fixed.
      ! [origin/monitor-config] Added monitors magnetic attraction in position dialog.
       ! [origin/setxkbmap] * Preserve the config values in lxqt-session config file. * Support setting key used to switch layouts.
        ! [origin/switch-to-kscreen] lxqt-config-monitor: Use a separate combobox for clones
         ! [origin/sync-iconengine] Update to keep up with our QIconLoader
----------
...

palco:~/tmp/lxqt-config$ git checkout switch-to-kscreen
Branch switch-to-kscreen set up to track remote branch switch-to-kscreen from origin.
Switched to a new branch 'switch-to-kscreen'
palco:~/tmp/lxqt-config$ git branch -vv
  master            4864237 [origin/master] The last xrandr backend commit. Save settings added. Framebuffer screen size fixed.
* switch-to-kscreen 6f97487 [origin/switch-to-kscreen] lxqt-config-monitor: Use a separate combobox for clones

[selairi]

Solved (I will never write code after midnight). Sorry

I will start to write some changes in a few days.

Thanks

2015-04-27 8:22 GMT+02:00, palinek [email protected]:

What did you try? Everything seems to work correctly here:

palco:~/tmp$ git clone https://github.com/lxde/lxqt-config.git
Cloning into 'lxqt-config'...
remote: Counting objects: 3803, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 3803 (delta 8), reused 0 (delta 0), pack-reused 3784
Receiving objects: 100% (3803/3803), 925.58 KiB | 868.00 KiB/s, done.
Resolving deltas: 100% (2758/2758), done.
Checking connectivity... done.
palco:~/tmp$ cd lxqt-config/
palco:~/tmp/lxqt-config$ git show-branch -a
* [master] The last xrandr backend commit. Save settings added. Framebuffer
screen size fixed.
 ! [origin/HEAD] The last xrandr backend commit. Save settings added.
Framebuffer screen size fixed.
  ! [origin/fast-app-chooser] Delay loading of application icons in the
app-chooser dialog for faster loading.
   ! [origin/icon-theme-preview] lxqt-config-appearance/icontheme: String
performance enhancements
    ! [origin/lxinput] Rename lxqt-config-mouse to lxqt-config-cursor to
reflect what it does. Remove unnecessary desktop entry files and do some
makefile cleanup.
     ! [origin/master] The last xrandr backend commit. Save settings added.
Framebuffer screen size fixed.
      ! [origin/monitor-config] Added monitors magnetic attraction in
position dialog.
       ! [origin/setxkbmap] * Preserve the config values in lxqt-session
config file. * Support setting key used to switch layouts.
        ! [origin/switch-to-kscreen] lxqt-config-monitor: Use a separate
combobox for clones
         ! [origin/sync-iconengine] Update to keep up with our QIconLoader
----------
...

palco:~/tmp/lxqt-config$ git checkout switch-to-kscreen
Branch switch-to-kscreen set up to track remote branch switch-to-kscreen
from origin.
Switched to a new branch 'switch-to-kscreen'
palco:~/tmp/lxqt-config$ git branch -vv
  master            4864237 [origin/master] The last xrandr backend commit.
Save settings added. Framebuffer screen size fixed.
* switch-to-kscreen 6f97487 [origin/switch-to-kscreen] lxqt-config-monitor:
Use a separate combobox for clones

---

Reply to this email directly or view it on GitHub:
#502 (comment)

[paulolieuthier]

@selairi looking forward to seeing your PRs.

[selairi]

I have just uploaded some changes to switch-to-kscreen branch at lxde/lxqt-config.
It can:

• Change mode, rate and rotation
• Change position using GUI
• Save settings and load them at session start

I have written a first implementation of the screen daemon. It only runs lxqt-config-monitor when you connect a new screen.

Updated version of libkscreen is needed.

It needs some testing...

[jleclanche]

@selairi I like that UI a lot more than the previous one.

Can you change "Always be joined" to Keep monitors attached?

[selairi]

Can you change "Always be joined" to `Keep monitors attached`?

Done, I will upload in next commit. I'm writing a monitor daemon.

[jleclanche]

@selairi Is the kscreen stuff functional? if it is, it should land now, we're nearing the release.

[selairi]

Kscreen config-monitor is functional. One user has reported a system
crash, but I can not reproduce it.

El 24/10/15 a las 06:54, Jerome Leclanche escribió:

@selairi https://github.com/selairi Is the kscreen stuff functional?
if it is, it should land now, we're nearing the release.

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

[paulolieuthier]

Fixed!

[bugz8unny69]

I think, 'Always be joined' and 'Keep monitors attached' or 'Unify' are all confusing. Why not simply use, 'Keep desktop clone', etc?