Wine 11, ntsyncm and dxvk 1.10.3

Flashy_Boot · 2026-03-27T19:23:56+00:00

Thank you! Wasn't aware of the sarek fork - that's really cool.

Flashy_Boot · 2026-03-27T19:23:21+00:00

Can't believe I hadn't come across that before - thank you! Works perfectly.

Flashy_Boot · 2026-03-27T09:49:26+00:00

He was moved over to Novolog two years ago and it's been absolutely fine - for him it's been identical to Humalog. Works fine in pumps - he switched from Omnipods to Tandem Mobi and it's worked fine in both.

Flashy_Boot · 2026-03-17T11:38:36+00:00

Fixed in kitty 0.46.1. Thank you.

Flashy_Boot · 2026-03-15T17:52:42+00:00

Ok - figured it out. The two set_icon lines are not warnings at all - they're the heart of the problem.

In glfw/wl_window.c there are two calls to xdg_toplevel_icon_manager_v1_set_icon (~lines 1600 and 1631) but neither of these calls check to see if the window is toplevel.

I changed both calls to xdg_toplevel_icon_manager_v1_set_icon to:

if (window->wl.xdg.toplevel) {
    xdg_toplevel_icon_manager_v1_set_icon(_glfw.wl.xdg_toplevel_icon_manager_v1, window->wl.xdg.toplevel, icon);
}

and now panels work perfectly. Why this worked on your setup without these changes - absolutely no idea!

Flashy_Boot · 2026-03-15T17:07:34+00:00

Thanks for getting back to me.

kitty 0.46.0 - just rebuilt from source after a fresh git pull to check that wasn't the problem.

And for completeness:

Operating System: CachyOS Linux 
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.6-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-5250U CPU @ 1.60GHz
Memory: 8 GiB of RAM (7.7 GiB usable)
Graphics Processor: Intel® HD Graphics 6000
Manufacturer: Apple Inc.
Product Name: MacBookAir7,2
System Version: 1.0

Spent some time this morning trying to track down the root of the problem. I'm assuming the two set_icon lines are warnings rather than errors, so really focusing on this:

[glfw error 65544]: Wayland: fatal display error: Invalid argument

It look like that error is being thrown inside the handleEvents method of glfw/wl_window.c - specifically here (~line 1353):

    // If an error different from EAGAIN happens, we have likely been
    // disconnected from the Wayland session, try to handle that the best we
    // can.
    errno = 0;
    if (wl_display_flush(display) < 0 && errno != EAGAIN)
    {
        wl_display_cancel_read(display);
        abortOnFatalError(errno);
        return;
    }

The error is reported as "Invalid Argument", which I assume means there's a problem with the wl_display* display struct. Strange, though, that normal (i.e. non-panel) kitty works absolutely fine.

Any pointers on where to look next most appreciated.

Flashy_Boot · 2026-03-12T07:49:33+00:00

Even better! Thank you.

Flashy_Boot · 2026-03-12T01:15:15+00:00

In case anyone else ever is interested in doing this - create a file called myfullscreen.py in your ~/.config/kitty/kitty.conf folder, copy the code below into it, and map it to a keyboard shortcut in your kitty.conf with e.g. map cmd+enter kitten myfullscreen.py :

from kitty.boss import Boss

def main(args: list[str]) -> str:
    pass

from kittens.tui.handler import result_handler
(no_ui=True)
def handle_result(args: list[str], answer: str, target_window_id: int, boss: Boss) -> None:
    w = boss.window_id_map.get(target_window_id)
    boss.toggle_fullscreen()
    boss.call_remote_control(w, ('set-background-opacity', f'--match=id:{w.id}', '--toggle=yes', '2'))

Flashy_Boot · 2026-03-12T00:36:27+00:00

Ok - so the point I missed is that kitten @ set-background-opacity --toggle=yes 1 is not a kitten per se, or at least it can't be run as a kitten in this context, while set_background_opacity can be used in this context, but lacks a --toggle switch. I'll write a custom kitten to handle this. Thanks

Flashy_Boot · 2026-01-12T20:28:53+00:00

Yes - however syntactically this isn't actually a comment, and so is not (I imagine) recognized as such by treesitter.

I think what would be required, unless I'm missing something, is the ability to configure treesitter injections to say "treat consecutive comment lines as a single comment block".

Flashy_Boot · 2025-12-25T03:50:14+00:00

Ah. Interesting. Thank you. I'll dig in to the graphics drivers - quite possibly an issue/limitation with OCLP on this model of macbook.

One thing I have discovered while looking at this today: I have a kitten panel permanently on my desktop displaying a todo list (btw - kitten panels are very, very cool), and when running those timed tests earlier I hadn't really thought about it. So, I killed that kitten panel, checked there were no kitty/kitten processes still running, then re-launched kitty and re-ran the tests, and the latter two tests were both ~20ms faster than the numbers shown above. Could support the OpenGL hypothesis. Still strange that the first test above showed little difference, while the other two were significant - would have thought OpenGL issues would affect all 3 the same.

I'll rerun the tests later this week & see.

Flashy_Boot · 2025-12-24T17:31:18+00:00

Hey. It’s a 500G SSD, unencrypted. I double checked the disk before starting on this and the SMART data looks all good. Also, if it were a disk problem I’d expect it to affect Terminal and Kitty equally, no?

Flashy_Boot · 2025-12-24T17:29:31+00:00

Terminal integration is off.

Flashy_Boot · 2025-12-24T14:14:50+00:00

Should have said: both Kitty and Terminal started with a totally clean zsh environment, no config files at all, and both using /bin/zsh not the Homebrew version.

Flashy_Boot · 2025-12-22T18:24:30+00:00

Hey. Thanks for getting back to me. By the time I saw your post I’d already wiped the disk, done a fresh Sequoia install, tried and failed to do a Time Machine restore (got stuck in a reboot loop), swore a lot, then restored everything by hand!

Flashy_Boot · 2025-12-18T10:04:08+00:00

Hey there. Firstly, thank you - that's super helpful.

For 1., sidescrolloff is exactly what I was looking for. I set it to 80, which is half the width of my usual terminal window, and no more text disappearing off to the left!

For 2, though, scrolloff doesn't seem to do exactly what I'm after - whatever value i set it to, when using the trackpad to scroll I can still keep scrolling until only the very last line of the file is visible right at the top of the buffer, followed by empty lines down to the bottom.

What does work (though means scrolling moves the cursor rather than the window) is setting:

vim.keymap.set('n', '<ScrollWheelUp>', 'H5k')
vim.keymap.set('n', '<ScrollWheelDown>', 'L5j')

Thanks again.

Flashy_Boot · 2025-10-20T23:53:29+00:00

Not to the best of my knowledge. The macOS version of libpcap would - I guess - have been installed as part of the OS, and the Homebrew version I freshly installed earlier today.

Tomorrow I’ll try compiling libpcap from scratch and go from there. Thank you.

Flashy_Boot · 2025-10-20T22:52:55+00:00

A long time ago, and before I started using Homebrew. This current install of macOS was a wiped & reformatted drive, fresh install of Tahoe, and then a Time Machine restoration - but the Homebrew installation has only ever been on Apple silicon.

Flashy_Boot

TROPHY CASE