GitLab

We already had some behaviour for the case where the lid closes, we were
not applying it when initialising the daemon though, so a laptop would
start showing the screen to the keyboard until the user takes action.

This change addresses it so that upon initialising we run the same code
we would run if we closed the lid.


(cherry picked from commit deaaa7da)

Summary:
lockAutoRotate(true) would enable the automatic rotation and
lockAutoRotate(false) would disable auto rotation which is the opposite
of what the function name would imply, so rename it to setAutoRotate.

We also need a getter for the value to display the status in the UI.
This getter checks if all applicable outputs have auto rotate enabled
and returns that value.

Test Plan: tested on Plasma Mobile

Reviewers: #plasma, bshah, nicolasfella, romangg

Reviewed By: #plasma, bshah, romangg

Subscribers: romangg, nicolasfella, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28773

Summary:
This allows to lock the current rotation or temporary inhibit auto
rotation behavior on mobile

Test Plan: tested on mobile

Reviewers: romangg

Reviewed By: romangg

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28115

Summary:
With this patch KScreen controls rotation of internal outputs if an orientation
sensor is present and emitting rotation values.

The default behavior is auto-rotation but can be configured through control
files.

This functionality is developed for the Wayland session but might potentially
also work on X11, what needs to be tested more.

Test Plan: Screen of convertible with orientation sensor rotates.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: plasma-devel, davidedmundson

Tags: #plasma

Maniphest Tasks: T11475

Differential Revision: https://phabricator.kde.org/D26037

Don't ask the user for a screen configuration on login, instead, apply a sane default.
When connecting a new screen, apply a default configuration so the user gets immediate
feedback "something's happening" and then prompt for a configuration via the OSD in case
the chosen default doesn't fit.

BUG: 398816
FIXED-IN: 5.17.0

Differential Revision: https://phabricator.kde.org/D22803

Summary:
In order to consolidate the code and as a preparatory step for larger changes
introduce a wrapper class for KScreen::Config types. This class combines
information about the type and the previously static Serializer methods, such
that the Serializer class can be removed.

Test Plan: Autotest updated.

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Maniphest Tasks: T10028

Differential Revision: https://phabricator.kde.org/D16989

Summary:
Do not export class, privatize and unvirtualize members. Rename
config init function, cleanup includes and white space.

Test Plan: Manually in Wayland session.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: broulik, davidedmundson, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D16875

Summary: Purely for cosmetic reasons.

Test Plan: Compiles.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: davidedmundson, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D16874

One of LiMux client's requirements is for display configuration to be easily accessible by mouse.
The OSD cannot be accessed by mouse, so this applet offers commonly used screen layouts in an
easily accessible place.

To keep the screen on during a presentation (when the application does not do that or the user is
actually demonstrating something on the machine itself) one needs to uncheck the non-userfriendly
labeled "Enable powermanagement" check box in the battery monitor. Since this is also affects "screen
setup", it is placed in this plasmoid as well.

The widget can be placed as an always-visible plasmoid in the panel or in System Tray where it would
only show if presentation mode is enabled or more then one screen is connected.

Differential Revision: https://phabricator.kde.org/D14855

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: davidedmundson, broulik, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14361

Summary:
The OsdManager was trying to be a singleton while used from only one
place. Simplify it.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14166

Summary:
This makes the working of the display button much more intuitive.

FEATURE: 390096

Test Plan: Tested with external display plugged in, system behaves as expected

Reviewers: #plasma, dvratil

Reviewed By: dvratil

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D10896

Osd represents a single osd dialog.
OsdManager handles showing them per output.

The content can be loaded from a QML file. It should be reachable via
DBus, but I haven't tried.

This should also make the osd wayland compatible.

Summary:
Show the plasma OSD with icon "preferences-desktop-display-randr" and
text when the display button has been pressed.

When only one displays is connected, "No External Display" is connected.
When more displays are connected, "Changing Screen Layout" is shown.

This is pretty bare-bones, it doesn't show what kind of setup it will
choose now, or next. This could be done by improving Generator, now,
however. The problem is that when we're applying a new config, displays
will flicker due to being mode-set, so the OSD isn't all that useful
since the screens will settle down.
It is useful in case of only one screen, since it gives feedback to a
button that otherwise just appears do nothing.

I think this could be enhanced in the future by giving the opportunity
to pick a layout. For 5.8, this brings a noticeable improvement and lays
the base for further work.

Test Plan: manually tested both cases (1 and 2 screens)

Reviewers: #plasma, mart

Reviewed By: mart

Subscribers: graesslin, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D2718

It seems with the fixed crtc handling, that the setoperation now
succeeds in critical cases. This patch apparently avoids restoring a
valid configuration on startup, so let's back it out for now.

Summary: Use QObject's memory management tricks by parenting the timers.

Test Plan: kded5 still works

Reviewers: graesslin

Reviewed By: graesslin

Subscribers: plasma-devel, #plasma

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D1736

Summary:
Use a timer to avoid catching configChanged signals after we set
changes.

The long version:

TL;DR: We have a race condition when the kscreen daemon starts. It looks
up a known config, then applies it and subsequently resaves the config.
The same happens on config changes, it writes, then re-reads and then
re-writes the config change.
I've managed to prevent this from happening by adding a timer that does
avoids saving the config as a direct reaction to our own config changes.

So what happens on kded5 startup after loading the kscreen2 module:

- the kscreen config is requested and received
- the kscreen daemon (KD) looks into its config directory for a suitable
  config file
  (a config file is identified by a combined hash of all screen
attached, so unique per connected set of outputs)
- KD usually finds a config
- KD ignores configChanged events before it starts ...
- a KScreen::SetConfigOperation to apply the "known config"
- SetConfigOperation returns after a while (say 100ms later)
- we re-enable the change monitor
- we receive a configChanged signal
- we save the new config (usually to the existing config file)

I don't think this behavior is desirable. I don't see a reason why the
daemon should save its config right after applying it. I think this
causes more problems than we want, since the startup may overwrite the
user's config. This behavior seems to be desired by the code in KD, it's
already blocking configChanged signals during the SetOperation (which,
to be honest may result in nightmarish behavior in any way, so it might
be a kludge which aims too short).

From libkscreen perspective, SetConfigOperation::finished cannot
guarantee that all configChanged signals are already fired and that it's
safe to watch for new, independent changes now. At least on X11, we
simply don't know, and what we can do is wait a bit and cross fingers
that we're not catching our own noise. The changed signal *may* come
from a re-request of the edid information, but this is a bit hard to
track down, and not too useful, anyway, since changed Edid may affect a
large number of a screen's properties.
In the Wayland backend, that's a different story and we can prevent this
behavior at an earlier stage, so this timer is "probably not needed" (I
haven't tested that).

This effectively prevents KD from catching reactions to its own changes
and does not trigger saving the config file on every login. It still
reacts to changes from libkscreen, but will avoid re-saving the config a
few times. The timer may not be the neatest of solutions for this, but
it does help narrowing down the problem and may be a last resort action.
Most importantly, it avoids the re-writing of the config on startup and
plugging/unplugging a monitor effectively.

The timer value of 100ms is also used in kwin, which should make the
behavior (which is no problem in kwin) more solid.

CCBUG:346961
CCBUG:358011

Reviewers: graesslin

Reviewed By: graesslin

Subscribers: plasma-devel, #plasma

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D1730

The scrolls are unclear on the true purpose of it, but the prophecy clearly
states that unless we replace magical numerical constants by enums, our code
will be cursed to be buggy until the end of all time.

KScreen can now handle laptop lid being closed or opened. Once we get the
isLidClosedChanged signal, we wait for 2 seconds to find out whether it will
trigger system suspend or not. This is atm the only way how to "detect"
whether closing lid will suspend the computer or not.

If the we don't get the aboutToSuspend() signal within 2 seconds (an arbitrary
constant), we save the current config with "_lidOpened" suffix and turn off
the output.

When we are notified that lid has been opened, we first check whether a config
file with the same ID, but "_lidOpened" suffix exist, and if it does we use
it to reconstruct the config prior to closing the lid. If there is no such
config, we just try to come up with something (applyConfig()).

This is far from perfect (stupid suspend detection, changes made to configs
while laptop lid is closed will be forgotten once lid is opened again), but
it works reasonably well.

Plasma still seems to struggle with these complex changes, but that's another
problem.

Instead of connected and disconnected from all the signals in each Output, we
just listen to ConfigMonitor::configurationChanged(). This will reduce the
number invocations of configChanged() and thus m_saveTimer delays.

Disables compilation of the plasmoid (C++ plasmoids are unsupported in KF5)
and the kcm because does crazy things with the QDeclarativeItems.
Tests don't pass but Alex promised he'll look at it.

This can happen in VirtualBox for instance, where resizing window emits
a lot of XRandR events which causes inconsistancies in configs.

REVIEW: 110930
BUG: 319878
FIXED-IN: 1.0

Add 'outputConnected' and 'unknownOutputConnected' DBus signals
to the KDED module.