[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#780996: marked as done (kscreen: Prevents using "xset dpms force suspend")



Your message dated Mon, 13 Mar 2017 13:40:14 +0100
with message-id <20170313124014.6db3dqw6wvbl7z6t@gnuservers.com.ar>
and subject line Re: Bug#780996: kscreen: Prevents using "xset dpms force suspend"
has caused the Debian Bug report #780996,
regarding kscreen: Prevents using "xset dpms force suspend"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
780996: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780996
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: kscreen
Version: 1.0.2.1-1
Severity: important

I'm using KDE on a laptop with two screens: the internal one, and an external
one connected through HDMI.

With kscreen enabled, it is impossible to use the command "xset dpms force
suspend" in order to put the screens to sleep.

When the screens are put to sleep, kscreen thinks the external screen has been
disconnected. It then tries to reconfigure the layout for the internal screen
(thinking it's the only one connected), waking it up. The operation also wakes
up the external screen shortly after, making kscreen *re*reconfigure the
layout, this time for two screens.

Given the short span of time, almost half the time, kscreen fails to restore
the correct layout and ends up applying a wrong resolution to the external
screen. The external screen must then be disconnected and reconnected in order
to force kscreen to refresh the layout.

I can confirm that disabling kscreen makes this problem go away and makes the
"xset dpms force suspend" command work as expected.

I tried upgrading kscreen to the latest version from experimental as suggested
by Reportbug, but it is dependent on virtual packages that are not provided
anywhere.



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kscreen depends on:
ii  kde-runtime         4:4.14.2-2
ii  libc6               2.19-17
ii  libkdecore5         4:4.14.2-5
ii  libkdeui5           4:4.14.2-5
ii  libkscreen1         1.0.5-1
ii  libplasma3          4:4.14.2-5
ii  libqjson0           0.8.1-3
ii  libqt4-dbus         4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqt4-declarative  4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqtcore4          4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqtgui4           4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libstdc++6          4.9.2-10

kscreen recommends no packages.

kscreen suggests no packages.

--- End Message ---
--- Begin Message ---
Version: 4:5.3.2-2

¡Hola Thibaut!

El 2015-07-15 a las 20:18 +0200, Thibaut Renaux escribió:
After an unrelated system reinstall, I've noticed that Kscreen does work as intended and allows the screen to sleep.

Sorry for taking so long in getting back to you. I'm closing the original report with the version of kscreen that was in unstable when this update was sent.

However, after I installed bumblebee/primus for my Nvidia card, the behavior I described in the bug report shows up again, and the screen can't be put to sleep unless Kscreen is disabled.

Should I open a new bug on the bumblebee package instead of here?

I'm currently using bumblebee with my laptop and xset dpms force suspend still works as expected, hopefully this was fixed in the meantime. If you can still reproduce this issue, please send a new report to bumblebee.

Happy hacking,
--
"Executive ability is deciding quickly and getting somebody else to do the
work."
-- Pollard's Postulate
Saludos /\/\ /\ >< `/

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply to: