From: Hans de Goede <hdegoede@redhat.com>
To: Ben Greening <bgreening@gmail.com>, stable@vger.kernel.org
Cc: regressions@lists.linux.dev, rafael@kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [Regression] ACPI: video: Change how we determine if brightness key-presses are handled
Date: Wed, 13 Jul 2022 11:43:37 +0200 [thread overview]
Message-ID: <02190bee-2e1b-bea3-b716-a7c7f5aa2ff0@redhat.com> (raw)
In-Reply-To: <CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com>
Hi Ben,
On 7/13/22 07:27, Ben Greening wrote:
> (resending because of HTML formatting)
> Hi, I'm on Arch Linux and upgraded from kernel 5.18.9.arch1-1 to
> 5.18.10.arch1-1. The brightness keys don't work as well as before.
> Gnome had 20 degrees of brightness, now it's 10, and Xfce went from 10
> to 5. Additionally, on Gnome the brightness keys are a little slow to
> respond and there's a bit of a stutter. Don't know why Xfce doesn't
> stutter, but halving the degrees of brightness for both makes me
> wonder if each press is being counted twice.
Author of the troublesome patch here, sorry that this broke things
for you.
So this sounds like you are getting duplicate key-events reported,
causing the brightness to take 2 steps on each key-press which is
likely also causing the perceived stutter.
This suggests that acpi_video_handles_brightness_key_presses()
was returning true on your system and is now returning false.
Lets confirm this theory, please run either evtest or evemu-record
as root and then record events from the "Video Bus" device and then
press the brightness up/down keys. Press CTRL+C to exit. After this
repeat selecting the "Dell WMI hotkeys" device as input device.
I expect both tests/recordings to show brightness key events with
the troublesome kernel, showing that you are getting duplicate events.
If this is the case then as a workaround you can add:
video.report_key_events=1
to the kernel commandline. This should silence the "Video Bus"
events. Also can you provide the output of:
ls /sys/class/backlight
please?
> Reverting commit 3a0cf7ab8d in acpi_video.c and rebuilding
> 5.18.10.arch1-1 fixed it.
> The laptop is a Dell Inspiron n4010 and I use "acpi_backlight=video"
> to make the brightness keys work. Please let me know if there's any
> hardware info you need.
Note needing to add a commandline argument like this to get things
to work is something which really should always be reported upstream,
so that we can either adjust our heuristics; or add a quirk for your
laptop-model so that things will just work when another user tries
Linux on the same model.
So while at it lets look into fixing this properly to.
When you do not pass anything on the kernel commandline, what
is then the output of:
ls /sys/class/backlight
And for each directory under there, please cd into the dir
and then (as root) do:
cat max_brightness # this gives you the range of this backlight intf.
echo $some-value > brightness
picking some-value in a range of 0-max_brightness, repeating the
echo with different values (e.g. half-range + max) and see if
the screens brightness changes. Please let me know which directories
under /sys/class/backlight result in working backlight control
and which ones do not.
Also what is the output of "ls /sys/class/backlight" when
"acpi_backlight=video" is present on the kernel commandline ?
Regards,
Hans
next prev parent reply other threads:[~2022-07-13 9:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 5:27 [Regression] ACPI: video: Change how we determine if brightness key-presses are handled Ben Greening
2022-07-13 5:54 ` Thorsten Leemhuis
2022-07-13 9:43 ` Hans de Goede [this message]
2022-07-13 13:08 ` Ben Greening
2022-07-13 13:29 ` Hans de Goede
2022-07-13 13:49 ` Hans de Goede
2022-07-13 23:56 ` Ben Greening
2022-07-14 19:38 ` Hans de Goede
2022-07-13 13:58 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02190bee-2e1b-bea3-b716-a7c7f5aa2ff0@redhat.com \
--to=hdegoede@redhat.com \
--cc=bgreening@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox