Very slow response of brightness controls in gnome

Sadly this is still happening in [Testing] Manjaro Gnome 18.1.0 Juhraya pre2 ISO, which is keeping me from installing Manjaro.

It's not a minor bug and I haven't found something similar in months in:

  1. Ubuntu 19.04.
  2. Fedora 30.
  3. Arch Linux daily updated since I reported this.

It's clearly a bug in Manjaro Gnome edition.

Bug is still present in RC1 and also reproducible in Manjaro Budgie. Any news how to fix it?

@mmplx and @anon81571404 please can you test if this pkg fix the issue?

sudo pacman -U http://linux.rz.rub.de/archlinux/extra/os/x86_64/polkit-0.116-2-x86_64.pkg.tar.xz

Report back please.

Can confirm bug still present on Manjaro 18.04 + Gnome 3.32.2, tried the acpi_backlight kernel option with all possible values but unfortunately it didn't help.

@Ste74 tried the package you suggested - sadly the issue still persists.

Laptop is a Dell XPS 15 9570 4K.

Hi @Ste74, I have the same issue with slow brightness controls and other apps wher pkexec is used.

The easiest way to test is:

~ >>> time sudo pkexec echo "1"
1
sudo pkexec echo "1" 0.41s user 0.24s system 98% cpu 0.661 total

I have tried the newer polkit you suggested above but the bug is still there.

I have traced the command above (before trying new polkit), and it seems there is an endless loop of file operations which cause the delay:

clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=192998854}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=193319811}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=193631934}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=194109182}) = 0
futex(0x7f500cce6a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 7
write(7, "\1\0\0\0\0\0\0\0", 8)         = 8
write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x55563d1a7030, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55563d1a6d40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55563d19d078, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
read(7, "\1\0\0\0\0\0\0\0", 16)         = 8
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
read(7, "\1\0\0\0\0\0\0\0", 16)         = 8
clock_gettime(CLOCK_MONOTONIC, {tv_sec=20680, tv_nsec=277077310}) = 0
futex(0x7f500cce6a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(7, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x55563d1e32b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
close(7)                                = 0
getuid()                                = 0
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(8, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(9, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(10, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(11, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(12, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(13, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(14, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(15, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(16, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(17, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(18, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(19, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(20, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(21, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(22, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(23, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
*** goes on until
fcntl(1048556, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048557, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048565, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048566, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048567, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048568, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048569, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048570, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048571, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048572, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048573, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048574, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048575, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
stat("/etc/pam.d", {st_mode=S_IFDIR|0755, st_size=678, ...}) = 0
openat(AT_FDCWD, "/etc/pam.d/polkit-1", O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
read(7, "#%PAM-1.0\n\nauth       include   "..., 4096) = 155
openat(AT_FDCWD, "/etc/pam.d/system-auth", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=441, ...}) = 0
read(8, "#%PAM-1.0\n\nauth      required  p"..., 4096) = 441

Please find the full strace here (https://transfernow.net/73kb84s24zky) and let me know if you have any idea!

Looking at the code, it seems to be due to a loop through all file descriptors (see https://github.com/freedesktop/polkit/blob/master/src/programs/pkexec.c#L256)

Here is another strace with fnctl ignored and timestamps, you can see there is a 20s delay where that loop is running (https://transfernow.net/3593e1v4esj3)

I saw that on my system ulimit is set pretty high, : ~ >>> ulimit -n
1048576

Not sure that should be an issue - maybe i have a bigger I/O problem?

BTW, the limit is set when installing steam:

/etc/systemd/user.conf.d/40-fd-limits.conf

# Alter FD limis: is needed by Steam Play esync
[Manager]
DefaultLimitNOFILE=1048576

Update:
I've changed the limit to 1024, this improves the lag a lot, but it does not disappear completely. However the pkexec lag seems gone

~ >>> time sudo pkexec echo "1"
1
sudo pkexec echo "1" 0.05s user 0.02s system 89% cpu 0.082 total

Update #2:

Submitted issue to polkit: https://gitlab.freedesktop.org/polkit/polkit/issues/87

I have the same issue. let me know if there is any debug info i can supply to help fix this. Im running Manjaro gnome wayland on a Razer Blade Stealth. All function keys work fine and quickly except brightness. Changing the brightness from the slider in the settings screen is instant, only the keys are slow

Hi @kynrai if you want to check whether the issue is related to the max number of open files, check the setting with 'ulimit -n'. It was 1048576 and the delay is much better when the setting is back to 1024.

Interesting.. i don't have steam installed now so i never see this issue ..
btw you can provide a patch like the canonical iteration for fd to test in our packages?

Thanks, that did lower the lag a bit. Still some there but its a lot better to work with. Its still clearly a bug, and supports the debugging others have done related to the looping through file descriptors in part of the code.

Its a shame, this only seems to affect gnome as KDE was fine. Sometimes we need high file descriptor limits, like watching code repos for auto rebuild etc.

I can try to do that over the week end, it does not look to hard but it has been years since I've done some linux development :slight_smile:

Take your time and ping me when ready.. :+1:

Hey - I am seeing the same issue..
Shame that this has been on for so long now..

I am having the same issue on both of my ThinkPad E580 and ThinkPad X250. The delay isn't too bad though, maybe a second or two, I can live with that.

It worked on XFCE, now I am on Gnome (X11).

I'd offer help, but reading through the thread I doubt I'd be of much use.

Just wanted to thank everybody working on this longstanding unresolved issue. On thinkpad T480 and after changing the NOFILE limit to 1024 (not optimal) lag is still significant.

1 Like

Tried the last image with Gnome 3.34.1, the lag is worse than ever, brightness control is barely usable, each small increment takes like two seconds. I've seen this problem in Manjaro in three very different laptops, while no other distro I've used (Arch, Fedora, Ubuntu) ever showed it. I'm checking ulimit -n in Ubuntu and it's 1024. I don't think it's possible to change it in Manjaro live preview since it requires reboot, but will install, experiment and report here in the next few days.


i need to push it :wink:
little busy in this period

Now it seems to be fixed on both of my laptops after the last few updates, can anyone confirm?

Yes, much more responsive keyboard keys than before. As it should have been

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by