| 2026-02-16 00:07:46 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2026-02-16 02:37:54 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:06:44 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) (Remote host closed the connection) |
| 2026-02-16 03:07:02 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:23:06 +0100 | hightower4 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:25:20 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) (Ping timeout: 245 seconds) |
| 2026-02-16 04:11:51 +0100 | td_ | (~td@i53870902.versanet.de) (Ping timeout: 244 seconds) |
| 2026-02-16 04:14:01 +0100 | td_ | (~td@i5387093C.versanet.de) td_ |
| 2026-02-16 04:17:42 +0100 | <ghormoon> | can i somehow ban window border based on window name? or even on that a window pro "STEAM_GAME(CARDINAL)" exists in general? I have an issue with som fullscreen windows that the border blinks ... even if set the layout to a borderless variant before moving the window there |
| 2026-02-16 04:21:03 +0100 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Hooks-BorderPerWindow.html |
| 2026-02-16 04:25:23 +0100 | <geekosaur> | matching on a property of type CARDINAL will probably require custom code, I think there's only a canned version for strings |
| 2026-02-16 04:28:32 +0100 | <ghormoon> | i'll do it by the name for now ... but I'm missing some syntax sugar, i tried to edit my main line, but that won't work: main = xmonad $ actionQueue =<< myStatusBar (withUrgencyHook NoUrgencyHook defaults) |
| 2026-02-16 04:28:43 +0100 | <ghormoon> | previously it was just: main = xmonad =<< myStatusBar (withUrgencyHook NoUrgencyHook defaults) |
| 2026-02-16 04:34:08 +0100 | <geekosaur> | correct, the precedences are wrng for what ypu were doing. `main = xmonad =<< actionQueue <$> myStatusBar (withUrgencyHook NoUrgencyHook defaults)` |
| 2026-02-16 04:37:05 +0100 | <ghormoon> | thanks, that helps |
| 2026-02-16 04:39:50 +0100 | <ghormoon> | ok, minor thing, the specific cborder settings get forgotten if i restart xmonad, but that's not gonna happen often unless i'm trying to tweak something, so it's not improtant to fix :D |
| 2026-02-16 04:41:26 +0100 | <geekosaur> | report that; there might be a way around it |
| 2026-02-16 04:42:40 +0100 | <ghormoon> | yeah the per-window action obviously doesn't run again |
| 2026-02-16 04:43:13 +0100 | <ghormoon> | but the other tasks like doShift don't run either |
| 2026-02-16 04:44:09 +0100 | <geekosaur> | yeh, but I'm thinking we save them by ID in persistent XS and reapply them on restart. also would require a delete-window hook to clean up, but conveniently `actionQueue` is a combinator so we can hide it in there without changing types or usage ☺ |
| 2026-02-16 04:47:34 +0100 | <geekosaur> | and yes, none of the manageHook things run on restart, they only run when a new window is mapped |
| 2026-02-16 04:48:12 +0100 | <geekosaur> | there are things you don't want to get repeated on restart, for example a manageHook moves a window to some workspace but then you manually move it somewhere else |
| 2026-02-16 04:48:26 +0100 | <geekosaur> | you don't want that to get undone on restart |
| 2026-02-16 04:50:01 +0100 | <ghormoon> | yeah so the question is, if this should be re-run or not, but it would make sense to, right |
| 2026-02-16 04:51:02 +0100 | <ghormoon> | btw theoretically, xmonad can run only one x session or more? thinking if i could possibly have some way to switch around some windows to dgpu without some heavy pains |
| 2026-02-16 04:52:11 +0100 | <geekosaur> | it's the other way around. an X session can only run a single window manager |
| 2026-02-16 04:52:48 +0100 | <geekosaur> | you could arrange to run a second X session via a display manager, but it's not possible to move windows between X sessions (X server limitation) |
| 2026-02-16 04:53:37 +0100 | <ghormoon> | yeah not to move windows between, but to be able to switch to desktops that have windows in the other x session |
| 2026-02-16 04:54:18 +0100 | <ghormoon> | have both sets of workspaces in one xmonad ... not important, just thinking :D |
| 2026-02-16 04:56:29 +0100 | <ghormoon> | but i guess i'd have to have two separate xmonad instances running and just switch around those some other way |
| 2026-02-16 05:06:41 +0100 | <geekosaur> | right |
| 2026-02-16 05:07:53 +0100 | <geekosaur> | and "some other way" is CTRL-ALT-Fn (beware of modern keyboards which require an extra keypress for the function keys) where the first X session is F1 (or F2 if Wayland is also running) and the second F2 (resp. F3) |
| 2026-02-16 05:08:43 +0100 | <geekosaur> | although with Xkb you can redefine those keys, but you'll probably have to write your own Xkb modifier and install it manually |
| 2026-02-16 05:14:52 +0100 | <geekosaur> | I don't think any existing window mnager has the ability to connect to multiple display servers and keep track of what's running on each display server. in xmonad's case it would mean multiple StackSets and some way to switch between them (and lose compatibility, since switching between them would be Linux specific but we have users on NetBSD (where xmonad originated) and FreeBSD |
| 2026-02-16 05:22:05 +0100 | <geekosaur> | there was at one point a proof of concept ov moving windows between display servers. they discovered that the only way to do it reliably was to save the entire event stream sent to the display server and replay it when moving (recreating, really) the window. this got very slow for long-lived windows and used a lot of memory/disk for the saved event stream |
| 2026-02-16 06:05:02 +0100 | <ghormoon> | well, apart of the ctrl-alt-fn, i'd somehow need to hook in muxing the display, so it won't be that trivial i guess :D |
| 2026-02-16 08:02:35 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) Enrico63 |
| 2026-02-16 08:36:57 +0100 | ft | (~ft@p4fc2afab.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-02-16 08:38:04 +0100 | coldpress | (~coldpress@223.205.212.35.bc.googleusercontent.com) coldpress |
| 2026-02-16 08:58:39 +0100 | werneta | (~werneta@71.83.160.242) (Quit: Lost terminal) |
| 2026-02-16 09:13:31 +0100 | mkoskar | (hal9000@user/mkoskar) (Ping timeout: 264 seconds) |
| 2026-02-16 09:20:09 +0100 | mkoskar | (mkoskar@user/mkoskar) mkoskar |
| 2026-02-16 09:33:45 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) (Quit: Client closed) |
| 2026-02-16 10:15:30 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) Enrico63 |
| 2026-02-16 10:53:27 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) (Quit: Client closed) |
| 2026-02-16 11:20:05 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 11:23:39 +0100 | hightower4 | (~hightower@dh207-112-152.xnet.hr) (Ping timeout: 245 seconds) |
| 2026-02-16 13:35:13 +0100 | <liskin> | ghormoon: what kind of hardware do you have? have you heard of https://github.com/felixdoerre/primus_vk ? |
| 2026-02-16 13:37:42 +0100 | <liskin> | That being said, my setup (dotfiles on github) does have support for running a separate X session on the dGPU and it worked relatively well. But it's been years since I last used it - no point even trying these days as that nvidia is so old it won't run any games anyway. |
| 2026-02-16 14:46:51 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) Enrico63 |
| 2026-02-16 15:14:46 +0100 | Enrico63 | (~Enrico63@host-82-63-21-32.business.telecomitalia.it) (Quit: Client closed) |
| 2026-02-16 16:23:49 +0100 | Miroboru | (~myrvoll@84.214.174.190) (Quit: Lost terminal) |
| 2026-02-16 21:13:21 +0100 | ft | (~ft@p4fc2afab.dip0.t-ipconnect.de) ft |
| 2026-02-16 21:20:23 +0100 | <ghormoon> | liskin: igpu in i9-13900hx, dgpu 4070, dell g16 7630 (should have mux switch) |
| 2026-02-16 21:21:56 +0100 | <ghormoon> | looking on the link, that would work for most of my linux gaming usecases i think ... the performance hit of that instead of mux should be pretty low. but in the end, i'd be kinda insterested if i could much it manually, so i cah also have gaming windows vm and use somo hotkey to mux/demux into it and keep it runinng, but that's way offtopic here :) |
| 2026-02-16 21:24:36 +0100 | <ghormoon> | did you use oss or proprietary nvidia drivers? |
| 2026-02-16 22:26:37 +0100 | hightower4 | (~hightower@dh207-83-96.xnet.hr) hightower2 |
| 2026-02-16 22:28:59 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) (Ping timeout: 252 seconds) |
| 2026-02-16 22:46:01 +0100 | <liskin> | ghormoon: oh, I see - I never had a laptop with an actual mux so my experience is limited |
| 2026-02-16 22:46:32 +0100 | <liskin> | Suppose you could pass the whole dGPU to qemu if there's a hardware mux |
| 2026-02-16 22:47:20 +0100 | <liskin> | I used proprietary because that was the only thing that worked back then. Nouveau was useless and there was nothing else |
| 2026-02-16 23:20:42 +0100 | <ghormoon> | yeah i tried proprietary and it gets kernel panics every 10min or so even when i use igpu :D just by being loaded :D |
| 2026-02-16 23:21:15 +0100 | <ghormoon> | but yeah that's the general idea. the question is, if i'll manage to control the mux somehow to only switch display and not turn off the gpu |
| 2026-02-16 23:21:25 +0100 | <ghormoon> | but that's a task for another day |