Logs: liberachat/#xmonad
| 2023-02-11 19:35:14 | ← | letztesendung parts (~letzte@2a00:d880:3:1::9567:bfa0) () |
| 2023-02-11 19:35:41 | <geekosaur> | so, Gaps says: |
| 2023-02-11 19:35:53 | <geekosaur> | To configure gaps differently per-screen, use XMonad.Layout.PerScreen. |
| 2023-02-11 19:35:53 | <geekosaur> | Warning: If you also use the avoidStruts layout modifier, it must come before any of these modifiers. See the documentation of avoidStruts for details. |
| 2023-02-11 19:36:34 | <geekosaur> | (it says "coming soon" for PerScreen, but it exists now. with the downside that it works by screen size, not screen ID) |
| 2023-02-11 19:44:35 | <ectospasm> | OK, so I include PerScreen, and is there anything else I need to do for that? |
| 2023-02-11 19:46:38 | <ectospasm> | So I have to know my total screen geometry, I believe I have three screens at 1920x1080 when I have all my external monitors connected. |
| 2023-02-11 19:47:07 | <ectospasm> | The primary is in the middle, so I'd need x=1920-3840 to have the gap. |
| 2023-02-11 19:47:41 | <ectospasm> | That would need to be adjusted for when I only have one screen (like I have right now, I need to be in the room with the baby in the playpen) |
| 2023-02-11 19:54:18 | <geekosaur> | sadly, that's not how it works. it uses `ifWidth` and it sounds like the width is 1080 for all of them |
| 2023-02-11 19:55:03 | <geekosaur> | that said, the module really should be done better; I think a layout actually has the information needed to determine the actual screen number |
| 2023-02-11 20:32:33 | <ectospasm> | I thought 1920 was the width. |
| 2023-02-11 20:33:22 | <ectospasm> | Anyhow, isn't the width 5760 when I have three monitors, if they're all 1920x1080? |
| 2023-02-11 20:33:48 | <geekosaur> | sorry, I even thought I checked that, whoops |
| 2023-02-11 20:34:13 | <geekosaur> | that's the size of the root window, not the size of the screen rectangle passed to the layout |
| 2023-02-11 20:34:20 | <ectospasm> | I guess 1080 could be the width if the screen is in portrait orientation. |
| 2023-02-11 20:34:34 | <geekosaur> | (note that the layout doesn't get a position. I think) |
| 2023-02-11 20:35:13 | <geekosaur> | hm, actually it might. but it still wouldn't show in the width, only in the x value |
| 2023-02-11 20:35:46 | <geekosaur> | which would then have to be compared against all the ScreenDetail rectangles |
| 2023-02-11 20:36:59 | <ectospasm> | Is the x value the leftmost pixel of the screen? |
| 2023-02-11 20:38:38 | <geekosaur> | should be, yes |
| 2023-02-11 20:41:46 | <geekosaur> | okay, yes, the layout is passed the full screen rectangle including its position, so in particular the first/outermost layout receives the screenRect from the ScreenDetail including x value |
| 2023-02-11 20:42:12 | <geekosaur> | we should really rewrite PerScreen to use that intead of (or in addition to) the ifWidth hack |
| 2023-02-11 20:45:15 | <vrs> | I have an odd problem - I have XF86AudioMute bound to "amixer set Master toggle", but whenever I do that xmonad goes into a loop of calling it and I have to restart it to regain proper function |
| 2023-02-11 20:45:26 | <vrs> | xev doesn't see anything out of the ordinary, it's not the keyboard repeating keys |
| 2023-02-11 20:46:04 | <vrs> | it doesn't happen with anything else, such as XF86AudioMicMute |
| 2023-02-11 20:46:25 | <vrs> | (which calls amixer set Capture toggle") |
| 2023-02-11 20:47:11 | <vrs> | when I disable the keybinding nothing happens, so nothing else is grabbing that |
| 2023-02-11 20:48:51 | <vrs> | why would specifically XF86AudioMute do that to my xmonad? |
| 2023-02-11 20:49:08 | <geekosaur> | no idea |
| 2023-02-11 20:49:11 | <geekosaur> | @where paste |
| 2023-02-11 20:49:11 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2023-02-11 20:56:20 | <vrs> | not sure what I could paste, it's a pretty standard ezconfig as far as that is concerned |
| 2023-02-11 21:07:45 | <vrs> | it's not deterministic and inserting even a sleep 0.01 seems to make a difference |
| 2023-02-11 21:08:09 | <liskin> | vrs: can you reproduce that in an empty X session where literally nothing else runs? |
| 2023-02-11 21:08:20 | <liskin> | Like not even pulseaudio/pipewire |
| 2023-02-11 21:08:49 | <liskin> | These things synthesise keypresses |
| 2023-02-11 21:09:02 | <vrs> | do they? |
| 2023-02-11 21:09:32 | <vrs> | I mean that would explain it |
| 2023-02-11 21:09:32 | <liskin> | Well I haven't seen them do AudioMute before |
| 2023-02-11 21:09:55 | <liskin> | But AudioPause in response to headphones disconnect, yeah |
| 2023-02-11 21:17:04 | <ectospasm> | why are you using amixer if you're using pulseaudio/pipewire? Don't those have CLI utilities to mute sinks, etc.? |
| 2023-02-11 21:17:21 | <vrs> | do they have toggle? amixer is purely a habit thing |
| 2023-02-11 21:17:55 | <vrs> | (and because it worked on freebsd I think back when I had a freebsd desktop) |
| 2023-02-11 21:19:52 | <ectospasm> | Yeah, it might behave better if use say pamixer --toggle-mute, you might need to provide which sink you want to mute. |
| 2023-02-11 21:20:19 | <ectospasm> | I know nothing of pipewire, but I'd be surprised if it doesn't have a similar mixer command. |
| 2023-02-11 21:20:38 | <vrs> | anyway the bug goes like this for me: I hit XF86AudioMute a few times, then at some point xmonad starts repeatedly calling the commend at about 20 times per second and my windows stop responding to input. xmonad commands are still accepted and I can recover by hitting either hitting mute at the correct time, or restarting xmonad |
| 2023-02-11 21:21:12 | <vrs> | after that applications accept input again |
| 2023-02-11 21:21:29 | <geekosaur> | weird. that sounds like something wrong with event handling |
| 2023-02-11 21:21:40 | <geekosaur> | hm, what version of xmonad and what version of ghc |
| 2023-02-11 21:21:41 | <geekosaur> | ? |
| 2023-02-11 21:21:58 | <vrs> | 0.17.1 + 9.0.2 |
| 2023-02-11 21:22:07 | <vrs> | (debian testing) |
| 2023-02-11 21:22:48 | <geekosaur> | mm. I'm still unclear on whether 9.0.2 is affected, but this might be a new manifestation of the join point bug |
| 2023-02-11 21:23:09 | <geekosaur> | is there a way you can try ghc 9.2.5? or xmonad from git? |
| 2023-02-11 21:24:00 | <geekosaur> | the join point bug is a ghc code generation error that leads to the memory we allocate for X events becoming corrupted and/or corrupting the heap |
| 2023-02-11 21:24:49 | <vrs> | hm if so then it's pretty localized because all I'm seeing is odd behavior for audiomute specifically, and no crashes/segfaults |
| 2023-02-11 21:24:51 | <geekosaur> | supposedly it only affected 9.2.x, except we have some very similar bug reports involving 9.0.x |
| 2023-02-11 21:25:05 | <geekosaur> | yes, it behaves very oddly and inconsistently |
| 2023-02-11 21:25:49 | <geekosaur> | I think bgamari had to experiment to find a combination of settings and environment that made it show up and behave reliably |
| 2023-02-11 21:27:20 | <vrs> | hm. it's not amixer at least, I managed to repro with a version that was just sleep 0.1 |
| 2023-02-11 21:29:44 | × | tremon quits (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2023-02-11 21:30:11 | <geekosaur> | anyway, 9.2.4 and later have a fix for the bug and xmonad git has a workaround |
| 2023-02-11 21:30:25 | <vrs> | it could be a hardware bug (keyboard being wonky or so) but then I can't explain why xmonad still processes commands and applications don't |
| 2023-02-11 21:31:28 | <geekosaur> | xmonad commands follow a different code path in the X server (keyboard grabs) although it'd still be pretty weird |
| 2023-02-11 21:32:07 | <geekosaur> | although come to think of it, if xmonad is still processing commands then event pointer corruption seems unlikely |
| 2023-02-11 21:39:50 | <vrs> | hm. since this keyboard generates an XF86WakeUp when I press Fn, I suspected grab weirdness and bound XF86WakeUp to return() |
| 2023-02-11 21:40:08 | <vrs> | which, as expected, makes XF86WakeUp not show up in xev anymore |
| 2023-02-11 21:44:23 | <vrs> | now if I do fn-down mute-down fn-up mute-up (note the interleaving), I can reliably reproduce the problem |
| 2023-02-11 21:45:12 | <vrs> | I had a few cases where XF86WakeUp would end up in xev (outside the grab, even though it should be grabbed) but I can't reproduce that right now |
| 2023-02-11 21:46:46 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-11 21:48:37 | <vrs> | okay it is a bug somewhere below xmonad, without the xmonad keybinds I can still get mute to repeat with that sequence |
| 2023-02-11 21:48:50 | <vrs> | so either X or the keyboard get something wrong here |
| 2023-02-11 21:49:18 | <vrs> | xmonad afaict just sees a key that it has bound staying pressed, and that's why it keeps the grab |
| 2023-02-11 21:52:02 | <geekosaur> | with keys like that it's also possible for it to be an ACPI bug (BIOS or, much less likely, Linux) |
| 2023-02-11 21:53:05 | <vrs> | yeah I suspect that the fn key here is doing something nonstandard (it's already decidedly odd for it to generate XF86WakeUp but that's apparently just a thing with these models) |
| 2023-02-11 22:02:49 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2023-02-11 22:11:07 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-11 22:15:03 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2023-02-11 23:21:01 | × | patrl quits (~patrl@user/patrl) (Ping timeout: 252 seconds) |
| 2023-02-11 23:39:06 | → | Hmmf joins (~Hmmf@2a01:e0a:582:bb40:e5c6:f484:7015:1722) |
| 2023-02-11 23:58:31 | <galactic_starfis> | why exactly is the shrinker paradigm in X.L.Decoration implemented as it is? running `init` like that just seems like a foolish idea... why not just calculate the desired width, and pass that into a "shrinker" function? a simple `take x` would suffice and not be atrociously imperformant... |
| 2023-02-11 23:58:56 | <galactic_starfis> | I could be misunderstandings it's exact purpose, but it seems like it's just wasting performance for no good reason |
| 2023-02-11 23:59:19 | <galactic_starfis> | s/performance/cycles |
| 2023-02-12 00:04:54 | <geekosaur> | you'd have to ask Andrea Rossato… if you can find him, at least |
| 2023-02-12 00:09:25 | <geekosaur> | the Shrinker impl just gives me a headache |
| 2023-02-12 00:09:25 | × | [Leary] quits (~Leary]@user/Leary/x-0910699) (Remote host closed the connection) |
| 2023-02-12 00:09:52 | → | [Leary] joins (~Leary]@user/Leary/x-0910699) |
| 2023-02-12 00:23:46 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-02-12 00:37:32 | <galactic_starfis> | hm |
| 2023-02-12 00:39:59 | <geekosaur> | this is the downside of contribs, we rarely know the logic behind some of the implementation decisions |
| 2023-02-12 01:06:05 | × | Natch quits (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 252 seconds) |
| 2023-02-12 01:06:06 | × | iffsid quits (~iffsid@2001:470:69fc:105::a3e) (Ping timeout: 252 seconds) |
| 2023-02-12 01:06:11 | × | adramelech[m] quits (~adramelec@2001:470:69fc:105::2:5198) (Ping timeout: 252 seconds) |
| 2023-02-12 01:08:17 | → | Natch joins (~natch@92.34.7.158) |
| 2023-02-12 01:09:29 | → | iffsid joins (~iffsid@2001:470:69fc:105::a3e) |
| 2023-02-12 01:14:47 | → | adramelech[m] joins (~adramelec@2001:470:69fc:105::2:5198) |
| 2023-02-12 01:16:46 | <galactic_starfis> | yeah, and looking more closely at the whole contrib file just made me realize how utterly messy that implementation is |
| 2023-02-12 01:17:48 | <galactic_starfis> | the overarching explanation is OK, but not enough detail is given on subcomponents... it's not immediately obvious what each part does... |
| 2023-02-12 02:49:26 | × | jludwig quits (~justin@li657-110.members.linode.com) (Ping timeout: 268 seconds) |
All times are in UTC.