help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rule from `udev-rules-service' not applied -- how to debug?


From: Timo Wilken
Subject: Rule from `udev-rules-service' not applied -- how to debug?
Date: Mon, 23 Jan 2023 18:37:58 +0100

Hi Guix,

I'd like to configure udev on my GuixSD system such that I can adjust
my laptop display's backlight without having to use "sudo". This
doesn't seem to work, as I can't figure out how to make udev pick up
my custom *.rules file -- see below. I would appreciate any hints on
how to debug this.

I've declared my laptop's system using "guix system", added my user to
the "video" group and added the following to my `operating-system''s
`services' field:

  (define backlight-udev-rules
    (udev-rule "90-backlight.rules" "\
  ACTION!=\"remove\", SUBSYSTEM==\"backlight\", GROUP=\"video\", MODE=\"0664\"
  ACTION!=\"remove\", SUBSYSTEM==\"leds\", GROUP=\"video\", MODE=\"0664\"
  "))

  (operating-system
   ...
   (services
    (cons* ... (udev-rules-service
                'backlight backlight-udev-rules
                #:groups '("video"))
           %desktop-services)))

This produces "/etc/udev/rules.d/90-backlight.rules" on my system,
which looks perfectly valid.

However, when I reboot my machine, every file in
/sys/class/backlight/intel_backlight is owned by root:root with 0644
or 0444 permissions, not by root:video as I'd like.

I've also tried the following "90-backlight.rules" content, which also
had no effect:

  ACTION=="add", SUBSYSTEM=="backlight", RUN+="/usr/bin/env chgrp video 
/sys/class/backlight/%k/brightness"
  ACTION=="add", SUBSYSTEM=="backlight", RUN+="/usr/bin/env chmod g+w 
/sys/class/backlight/%k/brightness"
  ACTION=="add", SUBSYSTEM=="leds", RUN+="/usr/bin/env chgrp video 
/sys/class/leds/%k/brightness"
  ACTION=="add", SUBSYSTEM=="leds", RUN+="/usr/bin/env chmod g+w 
/sys/class/leds/%k/brightness"

The above is slightly adapted from what ships with programs like
"light" and "brightnessctl" -- see:
https://github.com/haikarainen/light/blob/master/90-backlight.rules
https://github.com/Hummer12007/brightnessctl/blob/master/90-brightnessctl.rules

Running "udevadm test -a add /sys/class/backlight/intel_backlight"
gives the following output -- it does not seem to load any *.rules
files from /etc/udev/rules.d. Is that expected?

  # udevadm test -a add /sys/class/backlight/intel_backlight
  calling: test
  version 3.2.11
  This program is for debugging only, it does not run any program
  specified by a RUN key. It may show incorrect results, because
  some values may be different, or not available at a simulation run.
  === trie on-disk ===
  tool version:          3
  file size:         9463331 bytes
  header size             80 bytes
  strings            2374563 bytes
  nodes              7088688 bytes
  Load module index
  timestamp of 
'/gnu/store/g29xglzwnnlf5ghha9084wr0iy365zfg-eudev-3.2.11/etc/udev/rules.d' 
changed
  Reading rules file: 
/gnu/store/g29xglzwnnlf5ghha9084wr0iy365zfg-eudev-3.2.11/lib/udev/rules.d/50-udev-default.rules
  [lots of "reading rules file" lines omitted, all mentioning 
/gnu/store/g29xglzwnnlf5ghha9084wr0iy365zfg-eudev-3.2.11/lib/udev/rules.d/*.rules]
  Reading rules file: 
/gnu/store/g29xglzwnnlf5ghha9084wr0iy365zfg-eudev-3.2.11/lib/udev/rules.d/80-net-name-slot.rules
  rules contain 24576 bytes tokens (2048 * 12 bytes), 9516 bytes strings
  1082 strings (16595 bytes), 679 de-duplicated (7483 bytes), 404 trie nodes 
used
  ACTION=add
  DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight
  SUBSYSTEM=backlight
  USEC_INITIALIZED=5264579
  Unload module index

The "udev" system service is running:

  # herd status udev                                        
  Status of udev:
    It is started.
    Running value is 205.
    It is enabled.
    Provides (udev).
    Requires (root-file-system).
    Conflicts with ().
    Will not be respawned.

Sorry about this long email. I'd be very grateful for any hints on how
I could debug this problem further!

Cheers,
Timo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]