Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
How could I resolve this? Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
This should restore device brightness to whatever was set before suspend. Assuming your system is using ACPI backlight driver.
How could I resolve this?
You need to find out what and when changes the brightness. It could also be your desktop environment.
Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
This should restore device brightness to whatever was set before suspend. Assuming your system is using ACPI backlight driver.
I'm not sure about it... What I see from dmesg is: [ 28.188464] ideapad_acpi VPC2004:00: Keyboard backlight control not available
How could I resolve this?
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
On 2023-02-18 16:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
...
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
You can hook another script at restore from suspend or hibernation. See https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/SMZGCEUR434DBEQ2MBPEVYTZYNC5UGQY/ for the idea.
Notice that if your desktop restores brightness itself, it may be after that script runs. So perhaps add a delay.
Another place that can change brightness is laptop-mode tools — I'm unsure of the name, though.
Il 18/02/23 13:20, Carlos E. R. ha scritto:
On 2023-02-18 16:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
...
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
You can hook another script at restore from suspend or hibernation. See https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/SMZGCEUR434DBEQ2MBPEVYTZYNC5UGQY/ for the idea.
Notice that if your desktop restores brightness itself, it may be after that script runs. So perhaps add a delay.
Another place that can change brightness is laptop-mode tools — I'm unsure of the name, though.
I tried to review your script but I cannot adapt it to my specific case. I also tried to set systemd backlight restore to 0 into kernel parameters without success.
It will keep in this state which is not ideal and I hope that one day somebody will provide a valid solution because it is really an annoying fail!
Linux should just let the stuff as it is, without touching nothing, but evidently it likes to mess it up! 😬
Regards,
On 2023-02-19 12:58, Marco Calistri wrote:
Il 18/02/23 13:20, Carlos E. R. ha scritto:
On 2023-02-18 16:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
...
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
You can hook another script at restore from suspend or hibernation. See https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/SMZGCEUR434DBEQ2MBPEVYTZYNC5UGQY/ for the idea.
Notice that if your desktop restores brightness itself, it may be after that script runs. So perhaps add a delay.
Another place that can change brightness is laptop-mode tools — I'm unsure of the name, though.
I tried to review your script but I cannot adapt it to my specific case.
Why? :-?
Not enough scripting skill may be.
Besides that I want something "less experimental", something like "plug and play", since I already tested several solutions which have failed.
Inviato da Outlook per Androidhttps://aka.ms/AAb9ysg
________________________________ Da: Carlos E. R. robin.listas@telefonica.net Inviato: domenica 19 febbraio 2023, 09:52 A: oS-sprt support@lists.opensuse.org Oggetto: Re: Video Intel awaking w wrong Brightness level
On 2023-02-19 12:58, Marco Calistri wrote:
Il 18/02/23 13:20, Carlos E. R. ha scritto:
On 2023-02-18 16:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
...
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
You can hook another script at restore from suspend or hibernation. See https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/SMZGCEUR434DBEQ2MBPEVYTZYNC5UGQY/ for the idea.
Notice that if your desktop restores brightness itself, it may be after that script runs. So perhaps add a delay.
Another place that can change brightness is laptop-mode tools — I'm unsure of the name, though.
I tried to review your script but I cannot adapt it to my specific case.
Why? :-?
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like "plug and play", since I already tested several solutions which have failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
- -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
On 18.02.2023 18:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script,
Showing this script may provide some hints. Also why do you need it? Normally the brightness is expected to be set using desktop environment configuration and preserved across reboot.
Here this expected condition do not occurs, due that I use such script: echo -n 1 > /sys/class/backlight/acpi_video0/brightness
ACPI video brightness driver should restore hardware state to this value on resume. It actually prints message that it's doing it.
but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
This should restore device brightness to whatever was set before suspend. Assuming your system is using ACPI backlight driver.
I'm not sure about it... What I see from dmesg is: [ 28.188464] ideapad_acpi VPC2004:00: Keyboard backlight control not available
Keyboard backlight and screen brightness are two independent things.
How could I resolve this?
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
Yes, but it also may be that first kernel restores brightness and then your desktop environment overrides it.
Try booting into run level 3, set brightness, suspend and resume. Is brightness also reset in this case?
Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
Hmm ... I actually wonder why ACPI is used for brightness at all. Default should be to prefer native (intel_backlight in this case) unless overridden by system-specific quirks or manually. Can you provide full dmesg output?
On 2023-02-25 08:11, Andrei Borzenkov wrote:
On 18.02.2023 18:46, Marco Calistri wrote:
Il 18/02/23 11:44, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
...
You need to find out what and when changes the brightness. It could also be your desktop environment.
Well, for the boot my issue is resolved but for the after suspend mode it is not and from what I see by Google it is a very common issue among Linux users.
Yes, but it also may be that first kernel restores brightness and then your desktop environment overrides it.
It could be "laptop-mode-tools".
Il 24/02/23 18:34, Carlos E. R. ha scritto:
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like
"plug and play", since I already tested several solutions which have
failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
-- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
Hi Carlos,
Thanks for the script, I'm testing it.
But, don't I need to enable it as a systemd service?
First attempt, just after creating the script and entering in suspend mode, without exiting or rebooting the system, has failed: brightness set to max!
Logger has wrote the following into my journal:
feb 25 09:55:29 linux-turion64.ddns.net mine-brightness[5433]: Restoring brightness after hibernating/suspend.
Now I'll try to reboot...
Regards,
Il 25/02/23 10:07, Marco Calistri ha scritto:
Il 24/02/23 18:34, Carlos E. R. ha scritto:
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like
"plug and play", since I already tested several solutions which have
failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
-- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
Hi Carlos,
Thanks for the script, I'm testing it.
But, don't I need to enable it as a systemd service?
First attempt, just after creating the script and entering in suspend mode, without exiting or rebooting the system, has failed: brightness set to max!
Logger has wrote the following into my journal:
feb 25 09:55:29 linux-turion64.ddns.net mine-brightness[5433]: Restoring brightness after hibernating/suspend.
Now I'll try to reboot...
Regards,
Sorry to write this but the script as it is, doesn't work at all.
Regards,
Il 25/02/23 05:17, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
Hmm ... I actually wonder why ACPI is used for brightness at all. Default should be to prefer native (intel_backlight in this case) unless overridden by system-specific quirks or manually. Can you provide full dmesg output?
From what I read, this is a kernel issue started with 6.1 branch.
Intel_backlight subfolder has simply disappeared from /sys/class/backlight:
marco@linux-turion64:~> ls /sys/class/backlight/ acpi_video0
Attached dmesg---> https://drive.google.com/file/d/1bxutB4R1OzV1Qb5jWgEQEjJOxE-xn9q1/view?usp=s...
Please notice that I removed then the "y-uuid/4ff65e75-c664-43d8-ab25-25d85336f6b8 mitigations=auto quiet i915.enable_dpcd_backlight=1", since that do not produce the expected result.
Regards,
On 2023-02-25 14:07, Marco Calistri wrote:
Il 24/02/23 18:34, Carlos E. R. ha scritto:
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like
"plug and play", since I already tested several solutions which have
failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
Hi Carlos,
Thanks for the script, I'm testing it.
But, don't I need to enable it as a systemd service?
First attempt, just after creating the script and entering in suspend mode, without exiting or rebooting the system, has failed: brightness set to max!
Logger has wrote the following into my journal:
feb 25 09:55:29 linux-turion64.ddns.net mine-brightness[5433]: Restoring brightness after hibernating/suspend.
Then it is working as expected.
You just have to write the brightness you want it to set. It is your own line you posted previously:
echo -n 1 > /sys/class/backlight/acpi_video0/brightness
Experiment with different numbers till you get the brightness you prefer.
It does nothing on reboot.
Il 25/02/23 19:00, Carlos E. R. ha scritto:
On 2023-02-25 14:07, Marco Calistri wrote:
Il 24/02/23 18:34, Carlos E. R. ha scritto:
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like
"plug and play", since I already tested several solutions which have
failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
Hi Carlos,
Thanks for the script, I'm testing it.
But, don't I need to enable it as a systemd service?
First attempt, just after creating the script and entering in suspend mode, without exiting or rebooting the system, has failed: brightness set to max!
Logger has wrote the following into my journal:
feb 25 09:55:29 linux-turion64.ddns.net mine-brightness[5433]: Restoring brightness after hibernating/suspend.
Then it is working as expected.
You just have to write the brightness you want it to set. It is your own line you posted previously:
echo -n 1 > /sys/class/backlight/acpi_video0/brightness
Experiment with different numbers till you get the brightness you prefer.
It does nothing on reboot.
I would have to change your affirmation as follows:
The script works as expected by writing the comments on the system log, but in the reality it does not adjust the brightness to the same value (*which is 1*) set at boot by the script I added into my /etc/init.d/after.local:
#!/bin/sh #old script #echo -n 700 > /sys/class/backlight/intel_backlight/brightness #new script echo -n 1 > /sys/class/backlight/acpi_video0/brightness
To be more clear: the setting of acpi_video0 brightness works at boot but it does not work after suspend, in fact in this case it goes at very high intensity so that I need to adjust it manually.
In any case I thank you a lot for your attention!
Best regards,
On 26.02.2023 00:35, Marco Calistri wrote:
Il 25/02/23 05:17, Andrei Borzenkov ha scritto:
On 18.02.2023 04:31, Marco Calistri wrote:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
Hmm ... I actually wonder why ACPI is used for brightness at all. Default should be to prefer native (intel_backlight in this case) unless overridden by system-specific quirks or manually. Can you provide full dmesg output?
From what I read, this is a kernel issue started with 6.1 branch.
You read what?
Intel_backlight subfolder has simply disappeared from /sys/class/backlight:
I have no idea what you mean.
marco@linux-turion64:~> ls /sys/class/backlight/ acpi_video0
Attached dmesg---> https://drive.google.com/file/d/1bxutB4R1OzV1Qb5jWgEQEjJOxE-xn9q1/view?usp=s...
BIOS is from 2012 which means it probably predates Windows 8. In this case Linux kernel indeed will favor ACPI over native.
Try booting with acpi_backlight=native kernel parameter.
Please notice that I removed then the "y-uuid/4ff65e75-c664-43d8-ab25-25d85336f6b8 mitigations=auto quiet i915.enable_dpcd_backlight=1", since that do not produce the expected result.
Regards,
On 2023-02-26 05:04, Marco Calistri wrote:
Il 25/02/23 19:00, Carlos E. R. ha scritto:
On 2023-02-25 14:07, Marco Calistri wrote:
Il 24/02/23 18:34, Carlos E. R. ha scritto:
El 2023-02-19 a las 12:56 -0000, Marco Calistri escribió:
Not enough scripting skill may be.
I can help with that.
Besides that I want something "less experimental", something like
"plug and play", since I already tested several solutions which have
failed.
Inviato da Outlook per Android
Try (/usr/lib/systemd/system-sleep/mine-brightness):
#!/bin/bash
LOGGER=/usr/bin/logger
# $1: "pre" is hibernating. "post" is recovering.
case $1 in post) $LOGGER -t mine-brightness -p daemon.info "Restoring brightness after hibernating/suspend." echo -n 1 > /sys/class/backlight/acpi_video0/brightness ;; esac
I have not tested this.
If the script runs, you will see that message in the journal and/or syslog.
/usr/lib/systemd/system-sleep/mine-brightness must be marked executable, I understand.
Hi Carlos,
Thanks for the script, I'm testing it.
But, don't I need to enable it as a systemd service?
First attempt, just after creating the script and entering in suspend mode, without exiting or rebooting the system, has failed: brightness set to max!
Logger has wrote the following into my journal:
feb 25 09:55:29 linux-turion64.ddns.net mine-brightness[5433]: Restoring brightness after hibernating/suspend.
Then it is working as expected.
You just have to write the brightness you want it to set. It is your own line you posted previously:
echo -n 1 > /sys/class/backlight/acpi_video0/brightness
Experiment with different numbers till you get the brightness you prefer.
It does nothing on reboot.
I would have to change your affirmation as follows:
The script works as expected by writing the comments on the system log, but in the reality it does not adjust the brightness to the same value (*which is 1*) set at boot by the script I added into my /etc/init.d/after.local:
#!/bin/sh #old script #echo -n 700 > /sys/class/backlight/intel_backlight/brightness #new script echo -n 1 > /sys/class/backlight/acpi_video0/brightness
To be more clear: the setting of acpi_video0 brightness works at boot but it does not work after suspend, in fact in this case it goes at very high intensity so that I need to adjust it manually.
In any case I thank you a lot for your attention!
Well, just put there the value of brightness you want. If you want 700, put 700.
Notice also that it is possible that something alters the brightness later, after the script runs. In that case you could edit to:
post) $LOGGER -t mine-brightness -p ........ sleep 4 echo -n 700 > /sys/class/backlight/acpi_video0/brightness ;;
Il 17/02/23 22:31, Marco Calistri ha scritto:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
How could I resolve this? Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
Hello,
It follows how I have resolved my issue.
First of all, add the last parameter to /etc/default grub (in bold):
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/4ff65e75-c664-43d8-ab25-25d85336f6b8 mitigations=auto quiet *acpi_backlight=native*"
Then create the following file: */etc/X11/xorg.conf.d/20-intel.conf* with this content:
*Section "Device"** ** Identifier "Intel Graphics"** ** Driver "intel"** ** Option "Backlight" "intel_backlight"** **EndSection*
Finally, modify the startup script to adjust the initial brightness level:
*echo -n 700 > /sys/class/backlight/intel_backlight/brightness**
*Now my system starts with the right brightness level (the one I choose) and resume from suspend also by keeping the same brightness intensity.
Problem solved! *** *Best regards,
On 2023-02-26 15:32, Marco Calistri wrote:
Il 17/02/23 22:31, Marco Calistri ha scritto:
Hello,
I've been able to set a specific brightness intensity at evry boot, by using an /etc/init.d/after.local script, but anytime my system awakes from suspended mode, the brightness resets to a very high intensity.
from dmesg I see:
[ 3.128757] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 33.797331] ideapad_acpi VPC2004:00: Keyboard backlight control not available [28383.336476] video LNXVIDEO:00: Restoring backlight state
How could I resolve this? Which file is used by Tumbleweed for an after suspend brightness adjustment?
Thanks and regards,
Hello,
It follows how I have resolved my issue.
First of all, add the last parameter to /etc/default grub (in bold):
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/4ff65e75-c664-43d8-ab25-25d85336f6b8 mitigations=auto quiet *acpi_backlight=native*"
Then create the following file: */etc/X11/xorg.conf.d/20-intel.conf* with this content:
*Section "Device"** ** Identifier "Intel Graphics"** ** Driver "intel"** ** Option "Backlight" "intel_backlight"** **EndSection*
Finally, modify the startup script to adjust the initial brightness level:
*echo -n 700 > /sys/class/backlight/intel_backlight/brightness**
*Now my system starts with the right brightness level (the one I choose) and resume from suspend also by keeping the same brightness intensity.
Problem solved!
*Best regards,
Wonderful!
I think this does deserve a bugzilla.
Il 26/02/23 15:28, Andrei Borzenkov ha scritto:
On 26.02.2023 20:57, Carlos E. R. wrote:
I think this does deserve a bugzilla.
Yes, it may need quirks in kernel to prefer native backlight driver.
In case someone of you, or others here, would like to "bugzilling this experience", feel free to do it!
I'm not very good for these kind of reports.
Best regards!
On 2023-02-26 22:40, Marco Calistri wrote:
Il 26/02/23 15:28, Andrei Borzenkov ha scritto:
On 26.02.2023 20:57, Carlos E. R. wrote:
I think this does deserve a bugzilla.
Yes, it may need quirks in kernel to prefer native backlight driver.
In case someone of you, or others here, would like to "bugzilling this experience", feel free to do it!
I'm not very good for these kind of reports.
It is not rocket science... just describe the problem and your solution, that's all.
😁
Inviato da Outlook per Androidhttps://aka.ms/AAb9ysg
________________________________ Da: Carlos E. R. robin.listas@telefonica.net Inviato: domenica 26 febbraio 2023, 19:00 A: oS-sprt support@lists.opensuse.org Oggetto: Re: Resolved! (was) Re: Video Intel awaking w wrong Brightness level
On 2023-02-26 22:40, Marco Calistri wrote:
Il 26/02/23 15:28, Andrei Borzenkov ha scritto:
On 26.02.2023 20:57, Carlos E. R. wrote:
I think this does deserve a bugzilla.
Yes, it may need quirks in kernel to prefer native backlight driver.
In case someone of you, or others here, would like to "bugzilling this experience", feel free to do it!
I'm not very good for these kind of reports.
It is not rocket science... just describe the problem and your solution, that's all.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 26. 02. 23, 22:40, Marco Calistri wrote:
Il 26/02/23 15:28, Andrei Borzenkov ha scritto:
On 26.02.2023 20:57, Carlos E. R. wrote:
I think this does deserve a bugzilla.
Yes, it may need quirks in kernel to prefer native backlight driver.
In case someone of you, or others here, would like to "bugzilling this experience", feel free to do it!
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean cookies...
Bug open and closed at same time:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Best Regards,
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean cookies...
Bug open and closed at same time:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Best Regards,
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean any cookies...
Bug open and closed at same time:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Best Regards,
Il 28/02/23 00:37, Marco Calistri ha scritto:
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean any cookies...
Bug open and closed at same time:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Best Regards,
Very sorry for my repeated messages: I noticed my e-mail were not arriving/published on mailing list, then I sent it again.
Apologies!
On 2023-02-28 04:37, Marco Calistri wrote:
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean any cookies...
Bug open and closed at same time:
It is not closed. Jiri is asking you to attach a file.
Yes,
I've seen that. I will provide the dmidecode ASAP.
Regards,
Inviato da Outlook per Androidhttps://aka.ms/AAb9ysg
________________________________ Da: Carlos E. R. robin.listas@telefonica.net Inviato: mercoledì 1 marzo 2023, 08:40 A: oS-sprt support@lists.opensuse.org Oggetto: Re: Resolved! (was) Re: Video Intel awaking w wrong Brightness level
On 2023-02-28 04:37, Marco Calistri wrote:
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean any cookies...
Bug open and closed at same time:
It is not closed. Jiri is asking you to attach a file.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
Il 28/02/23 12:51, Marco Calistri ha scritto:
Il 28/02/23 00:37, Marco Calistri ha scritto:
Il 27/02/23 13:28, Carlos E. R. ha scritto:
On 2023-02-27 16:01, Marco Calistri wrote:
Il 27/02/23 05:17, Jiri Slaby ha scritto:
Noone else can do that for you. You ought to attach _your_ dmidecode output.
Bugzilla OpenSUSE does not works!
I get an error:
Internal server error during "passwordreset/get_registration_attributes".
Try deleting all opensuse.*, suse.* novell.* cookies first.
I resolved but I had not to clean any cookies...
Bug open and closed at same time:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Best Regards,
Very sorry for my repeated messages: I noticed my e-mail were not arriving/published on mailing list, then I sent it again.
Apologies!
Despite much time has passed and newer updates have been released, this bug has not yet been resolved for my system:
https://bugzilla.opensuse.org/show_bug.cgi?id=1208724
Regards,
-
Andrei Borzenkov -
Carlos E. R. -
Jiri Slaby -
Marco Calistri