search

meh / dux

DUX MEA LUX
GNU General Public License v3.0
88 stars 2 forks source link

Permission error crash when starting up #7

Open guyzmo opened 7 years ago

guyzmo commented 7 years ago

Here's the full stacktrace (with RUST_BACKTRACE=1) of the error I had:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 13, message: "Permission denied" } })', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:870
stack backtrace:
   1:     0x563da7a0f03c - std::sys::imp::backtrace::tracing::imp::write::h9c41d2f69e5caabf
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x563da7a1277e - std::panicking::default_hook::{{closure}}::hcc803c8663cda123
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x563da7a12384 - std::panicking::default_hook::hd5bda4e453dfb4be
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x563da7a12c1b - std::panicking::rust_panic_with_hook::hffbc74969c7b5d87
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x563da7a12ab4 - std::panicking::begin_panic::hc4c5d184a1e3fb7c
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x563da7a129d9 - std::panicking::begin_panic_fmt::h34f5b320b0f94559
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:501
   7:     0x563da7a12967 - rust_begin_unwind
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:477
   8:     0x563da7a3ef1d - core::panicking::panic_fmt::h1016b85b51d1931f
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/panicking.rs:69
   9:     0x563da7922659 - core::result::unwrap_failed::h3fc6bfb18651481f
  10:     0x563da794d5dc - dux::adaptive::h12f1e42559e88c9a
  11:     0x563da793ee63 - dux::main::hfe7c8f89931471b4
  12:     0x563da7a19ada - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  13:     0x563da7a13386 - std::rt::lang_start::ha0568cc91d8c5b09
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:436
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panic.rs:361
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/rt.rs:57
  14:     0x7fd979452290 - __libc_start_main
  15:     0x563da79062c9 - _start
  16:                0x0 - <unknown>
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:870
stack backtrace:
   1:     0x563da7a0f03c - std::sys::imp::backtrace::tracing::imp::write::h9c41d2f69e5caabf
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x563da7a1277e - std::panicking::default_hook::{{closure}}::hcc803c8663cda123
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x563da7a12384 - std::panicking::default_hook::hd5bda4e453dfb4be
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x563da7a12c1b - std::panicking::rust_panic_with_hook::hffbc74969c7b5d87
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x563da7a12ab4 - std::panicking::begin_panic::hc4c5d184a1e3fb7c
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x563da7a129d9 - std::panicking::begin_panic_fmt::h34f5b320b0f94559
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:501
   7:     0x563da7a12967 - rust_begin_unwind
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:477
   8:     0x563da7a3ef1d - core::panicking::panic_fmt::h1016b85b51d1931f
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/panicking.rs:69
   9:     0x563da7922c3d - core::result::unwrap_failed::hbc2f19648e8de36a
  10:     0x563da790fb03 - std::panicking::try::do_call::ha44fd8fa6e3c529b
  11:     0x563da7a19ada - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  12:     0x563da792c276 - <F as alloc::boxed::FnBox<A>>::call_box::haa2d2e0a400f9586
  13:     0x563da7a11ac4 - std::sys::imp::thread::Thread::new::thread_start::h76badbf9b0ecaf58
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/liballoc/boxed.rs:615
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys_common/thread.rs:21
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/thread.rs:84
  14:     0x7fd9799ee453 - start_thread
  15:     0x7fd97951a7de - __GI___clone
  16:                0x0 - <unknown>
guyzmo commented 7 years ago

After reading some other issue, I found out that dux needs access to /sys, so I looked at the source to find the exact full path it needs to access.

So I did a hack to solve it, which was to chown the files within the directory pointed by the link:

sudo chown $USER:root /sys/class/backlight/*

it's far from perfect, but does the job.

I believe there should be a more appropriate way to control brightness settings, using either xset or DBUS… At least, if the /sys path is the way to go, then maybe starting as root to open the fds, and downgrading the daemon to user mode could do the job.

Also, like others around, even if inc and dec work, I can't get a profile to work, I tried all three window, desktop and luminance with no success. I'd rather follow up on this on the other issues #3 and #6.

meh commented 7 years ago

The sysfs interface is only used if XRandr is not found, recent enough, or broken.

guyzmo commented 7 years ago

xrandr definitely works, and here's its version:

% xrandr --version
xrandr program version       1.5.0
Server reports RandR version 1.5
guyzmo commented 7 years ago

I guess I'll have another look at some point, and try to input debug printouts in the code to check why it's not using xrandr. I've never done any rust, and TBH, it makes me feel a coding newbie again ☺

Thank you for this code, BTW! ☺

meh commented 7 years ago

I'll try to investigate, it may be happening on my system too but I never noticed because I had the right permissions for testing the sysfs code.

If I can't reproduce it then yeah, good luck 🐼

guyzmo commented 7 years ago

maybe a nice thing would be to document what would be needed for having xrandr actually working :-s

helq commented 5 years ago

I think the problem is that xcb::intern_atom returns a xcb::ATOM_NONE for both "Backlight" and "BACKLIGHT" (https://github.com/meh/dux/blob/master/src/backlight/randr.rs#L36).

What is very weird is that this also occurs with "xbacklight", the tool from where, I think, the randr method for dux comes from.

Anyway, dux cannot use randr, so it defaults to using /sys/class/backlight/, but it fails in my machine as only root can modify files under that path. The solution I found was copy-pasting some Udev rules other backlight tools have implemented, so that my user gets some rights to modify files under the path. The procedure was:

  1. Download and rename file https://github.com/Ventto/lux/blob/master/99-lux.rules
  2. Copy file to /etc/udev/rules.d/
  3. Restart computer for rules to be reloaded

Dux works without any problem after restarting.

If anyone is curious on how changing the backlight works, I suggest you go take a look at other tools that do the same in other languages. Some of them are: https://wiki.archlinux.org/index.php/Backlight#Backlight_utilities. Btw, nobody cares about randr. All other tools modify /sys/class/backlight and have some udev rules.