JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 12:15:22 +01:00

[GH-ISSUE #866] sway: bar panics when changing keyboard layout #8693

New issue

Closed

opened 2026-05-23 03:53:48 +01:00 by JakeStanger · 6 comments

JakeStanger commented

2026-05-23 03:53:48 +01:00

Owner

Originally created by @quietvoid on GitHub (Feb 8, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/866

Describe the bug
When changing the keyboard layout, the bar panics. The layout does seem to change though.
I haven't looked much into it since it seems to fail at the channel send.

To Reproduce

Configure Sway with keybinds:

input * xkb_layout us,ca(multix)
input * xkb_options grp:alt_shift_toggle

Configure ironbar with keyboard type widget and run.
Press Alt+Shift to change layout.
ironbar panics

Backtrace: ironbar.log

Expected behavior
The bar should keep working.

System information:

Distro: Arch Linux
Compositor: Sway
Ironbar version: latest, commit 75375aa341

Configuration

Config

$keyboard_layout = {
    type = "keyboard" 
    show_scroll = false 
    icons.caps_on = "🄰"
}

Originally created by @quietvoid on GitHub (Feb 8, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/866 **Describe the bug** When changing the keyboard layout, the bar panics. The layout does seem to change though. I haven't looked much into it since it seems to fail at the channel send. **To Reproduce** - Configure Sway with keybinds: ``` input * xkb_layout us,ca(multix) input * xkb_options grp:alt_shift_toggle ``` - Configure `ironbar` with `keyboard` type widget and run. - Press Alt+Shift to change layout. - `ironbar` panics Backtrace: [ironbar.log](https://github.com/user-attachments/files/18716561/ironbar.log) **Expected behavior** The bar should keep working. **System information:** - Distro: Arch Linux - Compositor: Sway - Ironbar version: latest, commit 75375aa341ec154345a7f41d210c952d4ffe2002 **Configuration** <details> <summary>Config</summary> ```corn $keyboard_layout = { type = "keyboard" show_scroll = false icons.caps_on = "🄰" } ``` </details>

JakeStanger

2026-05-23 03:53:48 +01:00

closed this issue
added the
T:Bug
label

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@quietvoid commented on GitHub (Feb 16, 2025):

Tried testing with IRONBAR_LOG=trace IRONBAR_FILE_LOG=trace and for some reason adding the file trace logging makes the events work fine.
There might be a race condition somewhere.

Log: trace.txt

@quietvoid commented on GitHub (Feb 16, 2025): Tried testing with `IRONBAR_LOG=trace IRONBAR_FILE_LOG=trace` and for some reason adding the file trace logging makes the events work fine. There might be a race condition somewhere. Log: [trace.txt](https://github.com/user-attachments/files/18815648/trace.txt)

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@JakeStanger commented on GitHub (Feb 16, 2025):

I did update the sway IPC crate yesterday. I assume it's still broken according to the regular repro steps?

Seems it doesn't occur when you run sway inside another compositor. I've not had a chance to boot into sway to repro myself yet.

@JakeStanger commented on GitHub (Feb 16, 2025): I did update the sway IPC crate yesterday. I assume it's still broken according to the regular repro steps? Seems it doesn't occur when you run sway inside another compositor. I've not had a chance to boot into sway to repro myself yet.

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@quietvoid commented on GitHub (Feb 16, 2025):

I did update the sway IPC crate yesterday. I assume it's still broken according to the regular repro steps?

Yes, it is still broken on the latest commit.
I think there are duplicate events being sent somehow according to the logs, some of them aren't even from Keyboard input devices.

@quietvoid commented on GitHub (Feb 16, 2025): > I did update the sway IPC crate yesterday. I assume it's still broken according to the regular repro steps? Yes, it is still broken on the latest commit. I think there are duplicate events being sent somehow according to the logs, some of them aren't even from Keyboard input devices.

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@quietvoid commented on GitHub (Feb 16, 2025):

From what I can tell the receiver is being dropped somewhere, randomly.

2025-02-16T18:46:00.794565Z TRACE ironbar::clients::sway: 98: event: Ok(Input(InputEvent { change: XkbLayout, input: Input { identifier: "0:1:Power_Button", name: "Power Button", input_type: "keyboard", xkb_active_layout_name: Some("English (US)"), xkb_layout_names: ["English (US)", "Canadian (CSA)"], xkb_active_layout_index: Some(0), libinput: Some(Libinput { send_events: Some(Enabled), tap: None, tap_button_mapping: None, tap_drag: None, tap_drag_lock: None, accel_speed: None, natural_scroll: None, left_handed: None, click_method: None, middle_emulation: None, scroll_method: None, scroll_button: None, dwt: None, calibration_matrix: None }), vendor: Some(0), product: Some(1) } }))
2025-02-16T18:46:00.794572Z TRACE ironbar::clients::compositor::sway: 187: add_listener cb sender len 0, receiver count 0
2025-02-16T18:46:00.794580Z ERROR ironbar::logging: 49: The application panicked (crashed).
Message:  Failed to send message to channel: SendError(KeyboardLayoutUpdate("English (US)"))

I think what I'm running into is that more than 4 events are received in one layout change, making the channel full.
Which then returns an error: https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html#method.recv

If the Receiver handle falls behind, once the channel is full, newly sent values will overwrite old values. At this point, a call to recv will return with Err(RecvError::Lagged)

And the loop looks like this:

while let Ok(payload) = srx.recv().await {

Therefore the controller for KeyboardLayoutClient is silently dropping it.

@quietvoid commented on GitHub (Feb 16, 2025): From what I can tell the receiver is being dropped somewhere, randomly. ``` 2025-02-16T18:46:00.794565Z TRACE ironbar::clients::sway: 98: event: Ok(Input(InputEvent { change: XkbLayout, input: Input { identifier: "0:1:Power_Button", name: "Power Button", input_type: "keyboard", xkb_active_layout_name: Some("English (US)"), xkb_layout_names: ["English (US)", "Canadian (CSA)"], xkb_active_layout_index: Some(0), libinput: Some(Libinput { send_events: Some(Enabled), tap: None, tap_button_mapping: None, tap_drag: None, tap_drag_lock: None, accel_speed: None, natural_scroll: None, left_handed: None, click_method: None, middle_emulation: None, scroll_method: None, scroll_button: None, dwt: None, calibration_matrix: None }), vendor: Some(0), product: Some(1) } })) 2025-02-16T18:46:00.794572Z TRACE ironbar::clients::compositor::sway: 187: add_listener cb sender len 0, receiver count 0 2025-02-16T18:46:00.794580Z ERROR ironbar::logging: 49: The application panicked (crashed). Message: Failed to send message to channel: SendError(KeyboardLayoutUpdate("English (US)")) ``` I think what I'm running into is that more than 4 events are received in one layout change, making the channel full. Which then returns an error: https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html#method.recv > If the [Receiver](https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html) handle falls behind, once the channel is full, newly sent values will overwrite old values. At this point, a call to [recv](https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html#method.recv) will return with Err(RecvError::Lagged) And the loop looks like this: ```rs while let Ok(payload) = srx.recv().await { ``` Therefore the controller for `KeyboardLayoutClient` is silently dropping it.

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@quietvoid commented on GitHub (Feb 16, 2025):

I suppose the easy solution would be to just increase the channel capacity.

Though I don't know if there's a good reason every module loop is like that.
It might be better to just loop infinitely, ignoring receiver errors.

@quietvoid commented on GitHub (Feb 16, 2025): I suppose the easy solution would be to just increase the channel capacity. Though I don't know if there's a good reason every module loop is like that. It might be better to just loop infinitely, ignoring receiver errors.

JakeStanger commented

2026-05-23 03:53:49 +01:00

Author

Owner

@JakeStanger commented on GitHub (Feb 16, 2025):

I reckon both is probably the right call. If the buffer is filling up, it should be increased to be able to handle capacity.

Elsewhere I am looping and handling lag errors explicitly, so could do the same here if it's likely to be a recurring issue.

https://github.com/JakeStanger/ironbar/blob/master/src%2Fmacros.rs#L115

Ideally it should just throw an error and break in worst case scenarios too, rather than panicking and crashing the whole bar.

@JakeStanger commented on GitHub (Feb 16, 2025): I reckon both is probably the right call. If the buffer is filling up, it should be increased to be able to handle capacity. Elsewhere I am looping and handling lag errors explicitly, so could do the same here if it's likely to be a recurring issue. https://github.com/JakeStanger/ironbar/blob/master/src%2Fmacros.rs#L115 Ideally it should just throw an error and break in worst case scenarios too, rather than panicking and crashing the whole bar.