Screen energy saving & KDE issues - HP ProBook G2 470


I decided to switch to KDE (was using GNOME) on Leap 42.2 and now I’m facing issue when screen energy saving kicks in. When screen should turn on it stays completely black, no backlight, nothing. Only choice i have is to close lid and put laptop to sleep. On wakeup screen comes back on. GPU is integrated Intel Broadwell-U with discrete AMD graphics which is disabled in BIOS. This is not hardware issue because it works properly on GNOME installation. Issue is only when using KDE desktop environment.

Any advice?


Cool, 100+ views and no reply.

Could be my fault by not providing more info, but doesn’t really make sense to me with what I found out.

For mouse I use Logitech M557 (bluetooth mouse) and integrated Intel 7260 wifi+bt module. I tested bunch of different linux distros and desktop environments on this particular laptop and never had any issue except openSUSE 42.2 with KDE (this is 1st KDE environment I’m using on laptop, did not tried other distros).

Workaround for this problem is to use laptop’s touchpad for pointer move to wake up screen. Now, I can get used to that, no problem. Question now is which logs to collect and how to properly report a bug to KDE or openSUSE? Since laptop is not actually frozen, I can switch to console mode, login and run script which will collect logs when issue happens (it doesn’t happen always, which is also strange).


Have you checked KDE power management configuration?

System Settings > Power Management > Energy Saving, check ‘Screen Energy Saving’ is disabled for the different power modes as required.

Sorry, but I don’t follow you… I don’t have anything against screen energy saving option if it would work correctly. In fact, I often leave my laptop on because I have open vpn+ssh connection to remote machine which is building my code that I want to monitor. Sure, I can use utility like screen on remote machine, suspend laptop, wake it up from time to time, connect to vpn and ssh… but no thanx.

I ran openSUSE 42.2 with GNOME environment (where ‘Screen Energy Saving’ as it’s called in KDE worked just fine) and just out of curiosity I installed KDE desktop environment because I wanted to try it and I liked it but had issue described. So instead of trying to fix it and fact that reinstalling OS is not a big deal for my setup I went with that option because I did not want to spend much time with issue and was thinking that it’s possible there’s some conflict with both Plasma 5 and GNOME being installed on system at same time. I was wrong :slight_smile:

Now, point is - I have workaround to which I can get used to but if I can contribute in some way to fix this issue I’m here.

Only WARNING I noticed in kernel log is below and it’s related to BT stack.

   23.856502] Bluetooth: HIDP (Human Interface Emulation) ver 1.2   23.856507] Bluetooth: HIDP socket layer initialized
   23.861138] hid-generic 0005:046D:B010.0001: unknown main item tag 0x0
   23.861316] input: Bluetooth Mouse M557 as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:046D:B010.0001/input/input24
   23.861597] hid-generic 0005:046D:B010.0001: input,hidraw0: BLUETOOTH HID v10.01 Mouse [Bluetooth Mouse M557] on f8:16:54:7d:90:eb
   23.862002] ------------ cut here ]------------
   23.862009] WARNING: CPU: 1 PID: 1830 at ../kernel/sched/core.c:7929 __might_sleep+0x76/0x80()
   23.862014] do not call blocking ops when !TASK_RUNNING; state=1 set at <ffffffffa03e4fd5>] hidp_session_thread+0x135/0x860 [hidp]
   23.862048] Modules linked in: hid_generic hidp fuse cmac ecb rfcomm af_packet vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep arc4 xfs libcrc32c intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul iwlmvm mac80211 crc32_pclmul snd_hda_codec_realtek snd_hda_codec_generic nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi drbg ansi_cprng uvcvideo videobuf2_vmalloc videobuf2_memops snd_hda_intel videobuf2_v4l2 videobuf2_core v4l2_common snd_hda_codec snd_hda_core snd_hwdep snd_pcm btusb btrtl iwlwifi btbcm btintel videodev rtsx_pci_ms aesni_intel snd_timer iTCO_wdt iTCO_vendor_support aes_x86_64 bluetooth lrw r8169 gf128mul ppdev glue_helper ablk_helper hp_wmi cfg80211 sparse_keymap snd cryptd memstick mii pcspkr joydev lpc_ich rfkill parport_pc
   23.862068]  8250_fintek mei_me shpchp mei parport soundcore hp_accel lis3lv02d input_polldev thermal hp_wireless tpm_infineon intel_smartconnect battery ac fjes processor ext4 crc16 jbd2 mbcache sd_mod rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw ahci libahci rtsx_pci mfd_core libata ehci_pci ehci_hcd i915 i2c_algo_bit xhci_pci drm_kms_helper syscopyarea sysfillrect xhci_hcd sysimgblt fb_sys_fops usbcore usb_common drm wmi video button sg scsi_mod efivarfs autofs4
   23.862070] CPU: 1 PID: 1830 Comm: khidpd_046db010 Tainted: G           O     4.4.36-8-default #1
   23.862071] Hardware name: Hewlett-Packard HP ProBook 470 G2/2249, BIOS M73 Ver. 01.42 09/26/2016
   23.862073]  0000000000000000 ffffffff81327b17 ffff880224b03c70 ffffffff81a606f1
   23.862075]  ffffffff8107e841 ffffffff81ac5b5b ffff880224b03cc0 0000000000000988
   23.862076]  0000000000000000 0000000000000000 ffffffff8107e8bc ffffffff81a51170
   23.862076] Call Trace:
   23.862087]  <ffffffff81019ea9>] dump_trace+0x59/0x320
   23.862091]  <ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180
   23.862093]  <ffffffff8101b011>] show_stack+0x21/0x40
   23.862097]  <ffffffff81327b17>] dump_stack+0x5c/0x85
   23.862101]  <ffffffff8107e841>] warn_slowpath_common+0x81/0xb0
   23.862104]  <ffffffff8107e8bc>] warn_slowpath_fmt+0x4c/0x50
   23.862108]  <ffffffff810a30f6>] __might_sleep+0x76/0x80
   23.862116]  <ffffffff814fc6b4>] lock_sock_nested+0x24/0x70
   23.862139]  <ffffffffa0771a13>] l2cap_sock_sendmsg+0x53/0xf0 [bluetooth]
   23.862152]  <ffffffff814f7fb0>] sock_sendmsg+0x30/0x40
   23.862156]  <ffffffffa03e41ef>] hidp_send_frame+0x4f/0x80 [hidp]
   23.862169]  <ffffffffa03e4254>] hidp_process_transmit+0x34/0xb0 [hidp]
   23.862178]  <ffffffffa03e51e6>] hidp_session_thread+0x346/0x860 [hidp]
   23.862184]  <ffffffff8109d308>] kthread+0xc8/0xe0
   23.862189]  <ffffffff8160ac8f>] ret_from_fork+0x3f/0x70
   23.864034] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70

   23.864035] Leftover inexact backtrace:

   23.864040]  <ffffffff8109d240>] ? kthread_park+0x50/0x50
   23.864058] --- end trace 13ad08f3a404b6d0 ]---
 8310.916350] perf interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[10856.224032] device-mapper: uevent: version 1.0.3
[10856.224173] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised:


I guess I don’t follow you either then. It was a simple question about KDE power management that I asked. I don’t have the screen energy saving enabled and the desktop behaves as expected.

Ok, you’re saying that screen energy saving - switch off after x minutes in KDE is not same setting as ‘put display to sleep after x minutes’ in GNOME power manager?

Btw, I switched off screen energy saving and will see how it goes.

No, it’s probably equivalent, but KDE and Gnome have their own config files for this, so needs to be implemented separately. BTW, screen dimming may also need to be turned off.

Btw, I switched off screen energy saving and will see how it goes.

You should be able to check the status (as user) with

xset q

So basically you confirmed what said. I know that gnome and kde do have their own pm managers and daemons. Means bug exists as i wrote in my 2nd post. Any other WM I used with default settings on same machine just works.

Are you saying that despite you disabling the ‘Screen Energy Saving’ the screen backlight still turns off after a period of inactivity?

Yes, with xset q output:

DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

I usually have ‘Dim Screen’ and ‘Screen Energy Saving’ turned off. However, If I leave ‘Dim Screen’ enabled, then following inactivity the display brightness drops in 3 stages (relative the to screen dimming time set) with the backlight off at the last stage. Is that what you’re observing perhaps?

Ah, but that is not the full output of xset q, is it?

As Henk (and others) often say, it is really necessary to include the command as given and the full output in the pasted text in the forum, or you leave out some important information.

I will also add that on many systems (at least, AFAIR, on many laptops), the xset q output will change after a period of time.

I suggest you try the following:

Create a file with the following content:

    xset dpms 0 0 0
    xset -dpms
    xset s noblank

Give it a meaningfull name, such as noblankscreen & save it in /bin

Set the permissions rwxr-xr-x

Set it as a login script for each user you want to disable screen blanking on.

Log out, log back in, or reboot & log in.

Check to see that it all worked by opening a terminal and typing:

xset q

The output should include something similar to the following lines:

Screen Saver:
  prefer blanking:  no    allow exposures:  yes

DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

Note that this will be reset each time the system is hibernated, or goes into sleep mode, or you lock the screen, so after resuming from these states, drop to a console and issue the command:


or whatever name you gave to your script file.

Let me know if that solves your problem.


Sorry, but I’m not sure how I ened up with this answer. I admint that I was tierd when writting posts from post no 2 but what makes you guys think I want my screen not to blank? :slight_smile:

Problem I faced with screen energy saver was very simple. In 1st post I wrote that when screen goes blank, waking it up without putting laptop to sleep is not working (I forgot to said that I’m using bluetooth mouse which I added later in conversation)- Last night I disabled screen energy saver and left my laptop on over night. Screen went blank and this morning it woke up by moving mouse pointer using BT mouse. My point was that this is not working when screen energy saving is on (which is by default). It is working if I use trackpad which is part of laptop.

Anyway, seems like my issue is solved but I still believe there’s a bug with screen energy saving mode + BT mouse.


… I think we were trying to give you a work-around solution to not having your machine lock up: When the screen blanks, it locks up, therefore stop the blankety-blank blanking???:wink:

At any rate … Glad it is working, now.