This bug was fixed in the package policykit-1 - 0.105-16git1
---
policykit-1 (0.105-16git1) yakkety; urgency=medium
Upload current Debian packaging git.
[ Michael Biebl ]
* Use https:// for the upstream homepage.
* Update Vcs-Browser to use cgit.
[ Simon McVittie ]
*
** Tags added: systemd-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness keys are handled slower in Yakkety than Xenial
To manage notifications about this bug go to:
https://anonscm.debian.org/cgit/pkg-
utopia/policykit.git/commit/?id=4299fc41
** Changed in: policykit-1 (Ubuntu)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> Thus I am much more convinced now that switching to common-session-
noninteractive is not only correct (and also fixing this bug), but also
not actually that regression prone.
To prove this:
$ diff -u /etc/pam.d/common-session{-noninteractive,}
@@ -27,5 +27,6 @@
session optional
The reason why it is fast under upstart is that with upstart the entire
session is running in the logind scope/session, in particular unity-
settings-daemon; and then pkexec causes
Okt 06 22:10:46 donald pkexec[9943]: pam_systemd(polkit-1:session):
Cannot create session: Already running in a
The flurry of uevents like
KERNEL[2471.462139] add
/kernel/slab/:atA-192/cgroup/dentry(4399:user@0.service) (cgroup)
ACTION=add
DEVPATH=/kernel/slab/:atA-192/cgroup/dentry(4399:user@0.service)
SEQNUM=4916
SUBSYSTEM=cgroup
are new with kernel 4.8. This can easily be
I'm back to testing u-s-d started under systemd, and I found some
serious wackiness observing `sudo journalctl -f` when I use the
brigtness up/down hotkeys.
The attached "wacky-journalctl.txt" file has the output of `sudo
journalctl -f` during which I used the brightness hotkeys *twice*, and
`sudo forkstat -D 4` when u-s-d is started under systemd and I press the
brightness up hotkey.
** Attachment added: "with-systemd.txt"
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4756099/+files/with-systemd.txt
--
You received this bug
Okay, an interesting hint is that this problem seems to be fixed if
u-s-d is started under the Upstart user session instead of the systemd
user session.
If anyone wants to try this, just comment out these three lines in
/etc/X11/Xsession.d/00upstart:
if [ "${1#*.target}" != "$1" ]; then
In contrast this is what is happening with Xenial, which works perfectly.
evtest:
Event: time 1475641421.193234, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP),
value 1
Event: time 1475641421.193234, -- SYN_REPORT
Event: time 1475641421.193306, type 1 (EV_KEY), code 225
** Attachment added: "evdtest.txt"
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4754481/+files/evdtest.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I have similar problem on Dell XPS 15 (l521x). It is not quick and it seems
that for every key-press it's trying to change brightness twice.
I'll attach evtest and udev monitor outputs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: "udev.txt"
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4754480/+files/udev.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Confirm on Yakkety 16.10 on notebook HP Pavilion g7 smbios-2.7 dmi-2.7 smp
vsyscall32
Very very slow and inert reaction on pressing brightness keys
$ uname -r
4.8.0-17-generic
$ lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
00:01.0 PCI bridge:
I just dist-upgraded again, and with 4.8.0-14 my brightness keys work
again (bug 1626429). Under i3 (no unity-settings-daemon), I get a tame
and immediate reaction:
UDEV [38372.886325] change
/devices/pci:00/:00:02.0/backlight/acpi_video0 (backlight)
ACTION=change
On the u-s-d side there is some potential optimization: Ideally the
brightness would always be set through xrandr XBACKLIGHT, which works
unprivileged, and only fall back to the helper if that is not available
and the brightness needs to be set via sysfs properties. However, even
then there is no
Changing tasks as this is somewhere between unity-settings-daemon and
polkit.
** Package changed: linux (Ubuntu) => unity-settings-daemon (Ubuntu)
** Changed in: unity-settings-daemon (Ubuntu)
Status: Incomplete => Triaged
** Package changed: systemd (Ubuntu) => policykit-1 (Ubuntu)
**
This seems to trigger gnome-settings-daemon to do the following execs:
24323 execve("/usr/lib/unity-settings-daemon/usd-backlight-helper",
["/usr/lib/unity-settings-daemon/u"..., "--get-max-brightness"], [/* 47 vars
*/]
24323 <... execve resumed> )= 0
24324
** Attachment added: "FORK"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626651/+attachment/4746405/+files/FORK
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness
Ok this is not the same system but a similar lenovo with lagging
brightness. I could not get evtest to tell me about the event on any
sensible channel. But I am attaching the udev monitor and forkstat
output. This shows a single kernel backlight event and a single
synthetic udev event for the
** Attachment added: "UDEV"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626651/+attachment/4746404/+files/UDEV
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness
Oh, forgot: for evtest you might need to try with several devices, such
as "ThinkPad Extra Buttons" and the actual keyboard.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness
This looks like one keypress would cause a massive spew of uevents
and/or evdev events. Can you please run "sudo evtest" and "udevadm
monitor -e", then press a brightness key once, then ^C both and
copy the output?
I don't get this on my ThinkPad X230, I have the opposite problem
(brightness
OK, a bit more data:
Xenial with 4.4 and 4.8 kernels - works fine (so not a 4.8 kernel regression)
Yakkety with 4.4 and 4.8 kernels - shows the slow behavior (so not a kernel
issue)
So I think this is a problem in the plumbing layer.
** Changed in: systemd (Ubuntu)
Assignee: (unassigned)
I think this is a systemd/udevd kinda bug isn't it?
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Tags added: kernel-4.8
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness keys are handled slower in Yakkety than Xenial
To manage notifications about this bug go to:
26 matches
Mail list logo
