I have a custom cursor theme, and configuring cosmic to use it results in the compositor panicking with the following backtrace:
thread 'main' panicked at 'attempt to calculate the remainder with a divisor of zero':>
0: <backtrace::capture::Backtrace as core::default::Default>::default
1: log_panics::Config::install_panic_hook::{{closure}}
2: std::panicking::rust_panic_with_hook
3: std::panicking::begin_panic_handler::{{closure}}
4: std::sys_common::backtrace::__rust_end_short_backtrace
5: rust_begin_unwind
6: core::panicking::panic_fmt
7: core::panicking::panic
8: cosmic_comp::backend::render::cursor::Cursor::get_image
9: cosmic_comp::backend::render::cursor::draw_cursor
10: cosmic_comp::backend::render::workspace_elements
11: cosmic_comp::backend::kms::Surface::render_output
12: <core::cell::RefCell<calloop::sources::DispatcherInner<S,F>> as calloop::sources>
13: calloop::loop_logic::EventLoop<Data>::run
14: cosmic_comp::main
15: std::sys_common::backtrace::__rust_begin_short_backtrace
16: main
17: __libc_start_call_main
18: __libc_start_main@@GLIBC_2.34
19: _start
My cursor scheme has static cursors with delay set to zero. Is that a bug in the cursor scheme? (I couldn't find any xcursor spec saying that delay can't be zero.) Even if it is, I think the compositor shouldn't crash on an invalid cursor.
I don't know, if this is against the cursor-spec, though it certainly is an uncommon value. That said cosmic-comp definitely shouldn't crash, thanks for bringing this to my attention.
I have a custom cursor theme, and configuring cosmic to use it results in the compositor panicking with the following backtrace:
My cursor scheme has static cursors with
delay
set to zero. Is that a bug in the cursor scheme? (I couldn't find any xcursor spec saying thatdelay
can't be zero.) Even if it is, I think the compositor shouldn't crash on an invalid cursor.