Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot enter lowest power state on intel since 64a97b5 #1079

Closed
Stebalien opened this issue Jun 18, 2023 · 3 comments
Closed

Cannot enter lowest power state on intel since 64a97b5 #1079

Stebalien opened this issue Jun 18, 2023 · 3 comments

Comments

@Stebalien
Copy link
Sponsor

Since 64a97b5 (bisected with git), picom prevents my laptop from entering the lowest two (C9/C10) power states (tested with powertop).

Platform

Arch Linux

GPU, drivers, and screen setup

Graphics card: Intel Iris Xe
Xorg Driver: modesetting and intel (tested with both).

glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49)
    Version: 23.1.2
    Accelerated: yes
    Video memory: 64092MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.2
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.2
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

EXWM (Emacs)

picom version

version: 64a97b5

Diagnostics

Version: vgit-b700a

Extensions:

  • Shape: Yes
  • XRandR: Yes
  • Present: Present

Misc:

  • Use Overlay: Yes
  • Config file used: /home/steb/.config/picom.conf

Drivers (inaccurate):

modesetting

Backend: glx

  • Driver vendors:
  • GLX: Mesa Project and SGI
  • GL: Intel
  • GL renderer: Mesa Intel(R) Xe Graphics (TGL GT2)
  • Accelerated: 1

Backend: egl

  • Driver vendors:
  • EGL: Mesa Project
  • EGL driver: iris
  • GL: Intel
  • GL renderer: Mesa Intel(R) Xe Graphics (TGL GT2)

Configuration:

Configuration file
unredir-if-possible = true;
unredir-if-possible-exclude = ["name ~= '^EXWM'"];

vsync = true;
backend = "glx"
glx-no-stencil = true;
glx-no-rebind-pixmap = true;

fading = true;
fade-in-step=0.2;
fade-out-step=0.3;

focus-exclude = [
  "_NET_WM_STATE@[*]:a = '_NET_WM_STATE_FULLSCREEN'",
  "class_g = 'Emacs'",
  "window_type != 'normal'",
];

shadow = true;
shadow-opacity = 0.2;
shadow-radius = 10;
shadow-offset-x = -10;
shadow-offset-y = -10;

shadow-exclude = [
  "!(class_g = 'Emacs' || name ^= 'EXWM floating frame container for' || window_type *= 'menu' || window_type = 'notification')",
  "(class_g = 'LibreWolf' || class_g = 'valent' || class_g = 'easyeffects' || class_g = 'd-spy') && window_type *= 'menu'",
];

Steps of reproduction

  1. Close all applications.
  2. Install/run powertop and verify that your computer can reach the c9/c10 power states (intel).
  3. Start picom 64a97b5.
  4. Verify that it only reaches c8.

Expected behavior

It reaches c9/c10 as did previous picom versions.

Current Behavior

It only reaches c8, significantly reducing battery life.

@Stebalien Stebalien changed the title Cannot enter lowest power state on intel since 64a97b57b5c872555c0a8f74f8e83551618c4eb5 Cannot enter lowest power state on intel since 64a97b5 Jun 18, 2023
@absolutelynothelix
Copy link
Collaborator

try --no-frame-pacing and see #1072.

@Stebalien
Copy link
Sponsor Author

Thanks! That appears to be the issue.

@Stebalien Stebalien closed this as not planned Won't fix, can't repro, duplicate, stale Jun 18, 2023
@yshui
Copy link
Owner

yshui commented Jun 18, 2023

The fix would be stopping listening to present complete notify when the screen hasn't been updated for a while.

@yshui yshui reopened this Jun 18, 2023
yshui added a commit that referenced this issue Jun 24, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Jun 24, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Jun 26, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Jun 26, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 17, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 17, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 18, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 19, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 19, 2023
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:

1. after we rendered a frame, we need to know when it has been displayed
   on the screen.
2. estimating the refresh rate.

This commit makes sure we only request vblank events when it's actually
needed.

Fixes #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
yshui added a commit that referenced this issue Dec 19, 2023
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.

Related: #1079

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
@yshui yshui closed this as completed in 2e1c4e5 Jan 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants