Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windows 10 support? #640

Closed
koenverburg opened this issue Jun 15, 2018 · 49 comments
Closed

windows 10 support? #640

koenverburg opened this issue Jun 15, 2018 · 49 comments

Comments

@koenverburg
Copy link

No description provided.

@kovidgoyal
Copy link
Owner

IIRC you can run kitty via WSL. As for making it a native windows executable, not somthing I am interested in, but contributions are welcome.

@Luflosi
Copy link
Contributor

Luflosi commented Nov 28, 2018

I will be personally interested in kitty on Windows 10 without WSL in the future. I have to use Windows at work. I don't have admin rights so I can't install WSL. Unfortunately most computers there still run Windows 7 and it will probably take many more months for more machines, especially mine, to be upgraded. I don't particularly like any of the current terminal emulators available on Windows (that I know of) and I think kitty would be great addition. kitty would also truly be "cross-platform" IMHO as my definition of "cross-platform" includes Linux, macOS and Windows.

What would have to be done to work towards supporting Windows?

@kovidgoyal
Copy link
Owner

see #947

@Asheq
Copy link

Asheq commented Apr 11, 2019

Are there instructions somewhere for running kitty in WSL?

I'm trying this on Ubuntu 18.04 in WSL:

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin
~/.local/kitty.app/bin/kitty

I'm getting this error:

[101 16:34:27.269719] [glfw error 65543]: GLX: Forward compatibility requested but GLX_ARB_create_context_profile is unavailable
[101 16:34:27.270617] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.

@krishnakumarg1984
Copy link

Is there any word on Windows support yet?

@creallfluharty
Copy link

@Asheq I had a similar issue while using XMing 6.9. I'm not entirely sure what the issue was, but using XLaunch (vcxsrv) with the configuration described here I was able to successfully launch kitty. The result wasn't exactly pretty though:
image

@ctrlcctrlv
Copy link
Contributor

@creallfluharty Certainly, with further tinkering, that can be fixed. Fontconfig is in use on Windows it seems, so start there.

@erikli
Copy link

erikli commented Feb 21, 2020

Got this working on WSL and figured people would be interested in how. YMMV but what worked for me is:

VcXSrv (I'm on 1.20.1.4)

  • Multiple Windows
  • Native GL unselected

Launch Kitty with wsl cd ~;LIBGL_ALWAYS_INDIRECT=0 DISPLAY=:0 kitty

Results of LIBGL_ALWAYS_INDIRECT=0 glxinfo|grep -i version on my machine are:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 19.3.3
    Max core profile version: 3.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.3.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.1 Mesa 19.3.3
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 

@ctrlcctrlv
Copy link
Contributor

Hello friends!

I want to report my progress/research on this issue before I forget it.

I want to say two things right away:

  • It is my opinion that WSL is not a good solution. WSL provides no access to the graphics hardware. @erikli's solution will use Mesa's "software rendering", i.e., it will emulate a GPU on the CPU. This in my opinion defeats the purpose of using an OpenGL terminal like Kitty, and will be very slow compared to normal Kitty. Therefore, a palatable solution (meaning, a solution that is worthy of being included in the documentation, even as unofficially supported) must not use LIBGL_ALWAYS_INDIRECT. I decided to try to build on MSYS2 subsystem.

  • I was able to build, but not run Kitty. I hope @kovidgoyal will read my post and perhaps give me tips, should he have any.

Recipe

  1. First roadblock was dependencies. pkg-config was a PITA. Install mingw-w64-x86_64-pkg-config. Of course you also need Harfbuzz. Note I am using an existing MSYS2 installation which I use to build FontForge!!! you may need to figure out what other deps are needed, e.g. gettext-devel, libcrypt-devel.
  2. Apply patch:
    diff --git a/setup.py b/setup.py
    index 917d29e6..db86080e 100755
    --- a/setup.py
    +++ b/setup.py
    @@ -311,7 +311,8 @@ def kitty_env() -> Env:
         cflags.extend(pkg_config('harfbuzz', '--cflags-only-I'))
         font_libs.extend(pkg_config('harfbuzz', '--libs'))
         pylib = get_python_flags(cflags)
    -    gl_libs = ['-framework', 'OpenGL'] if is_macos else pkg_config('gl', '--libs')
    +    #gl_libs = ['-framework', 'OpenGL'] if is_macos else pkg_config('gl', '--libs')
    +    gl_libs = ["-lgdi32", "-lopengl32"]
         libpng = pkg_config('libpng', '--libs')
         ans.ldpaths += pylib + font_libs + gl_libs + libpng
         if is_macos:
    @@ -596,7 +597,7 @@ def find_c_files() -> Tuple[List[str], List[str]]:
    
    
     def compile_glfw(compilation_database: CompilationDatabase) -> None:
    -    modules = 'cocoa' if is_macos else 'x11 wayland'
    +    modules = 'cocoa' if is_macos else 'win32'
         for module in modules.split():
             try:
                 genv = glfw.init_env(env, pkg_config, at_least_version, test_compile, module)
    
    
    What this patch does? It provides the OpenGL linker options Windows expects, instead of linking against the system libGL. It also does one other thing, explained in next step...
  3. Pull normal master GLFW to glfw_git. This is why we modified compile_glfw. Move kitty's GLFW to glfw_bak first, then move glfw_git/src to glfw. Copy also glfw_git/include to .. Copy files from kitty's version until compiler stops complaining. I needed glfw.py, source-info.json and monotonic.c.
  4. Apply patch:
    diff --git a/Makefile b/Makefile
    index bfdcfb0e..7f38252e 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -6,30 +6,30 @@ ifdef VERBOSE
     endif
    
     all:
    -       python3 setup.py $(VVAL)
    +       /usr/bin/python3 setup.py $(VVAL)
    
     test:
    -       python3 setup.py $(VVAL) test
    +       /usr/bin/python3 setup.py $(VVAL) test
    
     clean:
    -       python3 setup.py $(VVAL) clean
    +       /usr/bin/python3 setup.py $(VVAL) clean
    
     # A debug build
     debug:
    -       python3 setup.py build $(VVAL) --debug
    +       /usr/bin/python3 setup.py build $(VVAL) --debug
    
     debug-event-loop:
    -       python3 setup.py build $(VVAL) --debug --extra-logging=event-loop
    +       /usr/bin/python3 setup.py build $(VVAL) --debug --extra-logging=event-loop
    
     # Build with the ASAN and UBSAN sanitizers
     asan:
    -       python3 setup.py build $(VVAL) --debug --sanitize
    +       /usr/bin/python3 setup.py build $(VVAL) --debug --sanitize
    
     profile:
    -       python3 setup.py build $(VVAL) --profile
    +       /usr/bin/python3 setup.py build $(VVAL) --profile
    
     app:
    -       python3 setup.py kitty.app $(VVAL)
    +       /usr/bin/python3 setup.py kitty.app $(VVAL)
    
     man:
            $(MAKE) FAIL_WARN=$(FAIL_WARN) -C docs man
    
    
    Why? We want to build with MSYS2 Python and not MINGW Python. Why? Kitty's build system requires os.wait() which only exists via MSYS2 Python which is posix not nt.
  5. CFLAGS="-Wno-error -Wno-pedantic" make. It works on my system, I receive a kitty/launcher/kitty.exe and a kitty/fast_data_types.so!!
  6. Simply copy kitty/fast_data_types.so to kitty/fast_data_types.dll

Final hurdle

Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/kitty
$ kitty/launcher/kitty.exe
[085 12:33:39.154547] Traceback (most recent call last):
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 322, in main
    _main()
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 310, in _main
    init_glfw(opts, cli_opts.debug_keyboard)
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 100, in init_glfw
    init_glfw_module(glfw_module, debug_keyboard)
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 94, in init_glfw_module
    if not glfw_init(glfw_path(glfw_module), debug_keyboard):
RuntimeError: Failed to dlopen /home/Fred/Workspace/kitty/kitty/glfw-x11.so with error: No such file or directory

Why it happens? Well because we copied regular GLFW in, and we built GLFW win32 stuff (win32_monitor.c etc.), but Kitty still expecting X11 for some reason.

If we try quick hack:

diff --git a/kitty/main.py b/kitty/main.py
index bc7bf8ce..0f482fe3 100644
--- a/kitty/main.py
+++ b/kitty/main.py
@@ -96,7 +96,7 @@ def init_glfw_module(glfw_module: str, debug_keyboard: bool = False) -> None:


 def init_glfw(opts: OptionsStub, debug_keyboard: bool = False) -> str:
-    glfw_module = 'cocoa' if is_macos else ('wayland' if is_wayland(opts) else 'x11')
+    glfw_module = 'cocoa' if is_macos else 'win32'
     init_glfw_module(glfw_module, debug_keyboard)
     return glfw_module

We get:

Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/kitty
$ kitty/launcher/kitty.exe
[085 12:35:54.270317] Traceback (most recent call last):
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 322, in main
    _main()
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 310, in _main
    init_glfw(opts, cli_opts.debug_keyboard)
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 100, in init_glfw
    init_glfw_module(glfw_module, debug_keyboard)
  File "/home/Fred/Workspace/kitty/kitty/launcher/../../kitty/main.py", line 94, in init_glfw_module
    if not glfw_init(glfw_path(glfw_module), debug_keyboard):
RuntimeError: Failed to load glfw function glfwRunMainLoop with error: No such process

Further investigation is needed. But before I try, I wonder what @kovidgoyal thinks about this method, so I wrote this post.

@kovidgoyal
Copy link
Owner

There will be a whole bunch of stuff that wont work this way. kitty's fork of glfw has totally different keyboard handling API for instance, and the run loop API, which is what your final hurdle error is about. You cant just drop in glfw upstream into kitty's fork and expect things to work. Somebody has to do the work of porting the various changes kitty has made to glfw to the windows glfw backends.

In addition there are unixisms all over kitty's code base, such as using fork to launch child processes, and os.wait() which you discovered for yourself.

@ctrlcctrlv
Copy link
Contributor

Thanks for quick reply.

Unixisms are not a problem if using MSYS which implements POSIX. So, those can be overcome as shown.

Somebody has to do the work of porting the various changes kitty has made to glfw to the windows glfw backends.

I will look into this :-) How hard do you think it would be?

@kovidgoyal
Copy link
Owner

should take about a week of work for someone reasonably familiar with win32 APIs

@Luflosi
Copy link
Contributor

Luflosi commented Mar 25, 2020

@ctrlcctrlv If you want to work on this, I am willing to help you but I am not familiar with the win32 APIs.

@ctrlcctrlv
Copy link
Contributor

@Luflosi Thanks for your offer. I see that you know a lot about the GLFW stuff, and you've worked on it a lot.

It's hard for me to make a promise that I'll finish this, due to personal financial issues, and other obligations...but I am very interested in the possibility.

I guess my question for you would be: why were changes made? Why is glfwRunMainLoop necessary, and what does it really do? Keyboard handling should be simpler to fix than that, I feel (could be wrong!!)

@ctrlcctrlv
Copy link
Contributor

And BTW thanks @kovidgoyal for quick estimate. I always appreciate your willingness to engage contributors working on things you yourself won't use

@kovidgoyal
Copy link
Owner

kovidgoyal commented Mar 25, 2020 via email

@kovidgoyal
Copy link
Owner

kovidgoyal commented Mar 25, 2020 via email

@ctrlcctrlv
Copy link
Contributor

Hello friends,

I have another update.

While reading Phoronix today I came across this article:

https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-Writing-Wayland-Comp

For WSL2, Microsoft will be including a Wayland compositor. As Kitty already supports Wayland, it's my opinion that this will be the best way to fix this issue. Instead of me spending a lot of time to hack support into our GLFW fork, which someone will have to maintain in perpetuity, we can get it for free just by waiting for Microsoft to release their compositor, then forcing Wayland on Windows and not Xorg.

@ndavd
Copy link

ndavd commented Feb 8, 2021

Hi y'all. What's the status on this?

@Luflosi
Copy link
Contributor

Luflosi commented Feb 8, 2021

There hasn't been any progress on this.

@ndavd
Copy link

ndavd commented Feb 9, 2021

That's unfortunate.

@clo-yunhee
Copy link

clo-yunhee commented Jul 6, 2021

I can confirm that kitty runs with hardware acceleration using NVIDIA's WSL2 enabled drivers with Microsoft's WSLg preview builds.

EDIT: I have had to build Mesa from source in order to get the D3D12 backend working.

@vbn
Copy link

vbn commented Aug 8, 2021

I have been using kitty since at least 2017 on macos when iTerm started feeling sluggish. It has the best combination of feature set and performance.

A project change means that I need to be on Windows but can't use WSL. (Also macos has now become cartoonish🤮)

After trying various terminal emulators, I'm using https://github.com/microsoft/terminal. It works well but I miss all the features from kitty. It looks like a native windows port for kitty would be a non trivial undertaking, but it'd be awesome if we can get there.

Meanwhile, wezterm is promising and I might switch to it for all the features it provides, if it holds up perf wise. Alacritty doesn't have tabs, mux like support or even ligatures support so it fails miserably for my use. I don't even understand what it's good for, since kitty has better performance than it.

@xiangpeng2008
Copy link

There hasn't been any progress on this.

@Luflosi any progress ?

@xiangpeng2008
Copy link

If I need to install WSL ( which is a bit complicated because of security and admin issues ), should I ask WSL2 or WSL1 for a better support of kitty ?

@ctrlcctrlv
Copy link
Contributor

WSL2 has the GPU support and will therefore run much better due to kitty's abundance of GLSL shaders.

@xiangpeng2008
Copy link

WSL2 has the GPU support and will therefore run much better due to kitty's abundance of GLSL shaders.

Thanks !

@ctrlcctrlv
Copy link
Contributor

@kovidgoyal You've closed this issue, but with the very welcome news and effort from @clo-yunhee that WSLg preview is out and its Wayland GPU support is working, I was wondering whether or not you wanted me, or another interested party, (perhaps she if she wishes!) to pen a guide for its compilation and use. Then Kitty can say it supports all major desktop OS, a major win! I can't wait to make the .lnk Windows desktop icon file!

@kovidgoyal
Copy link
Owner

yes, by all means go ahead. I have nothing against windows support, I
just dont want to spend time on it.

@xiangpeng2008
Copy link

xiangpeng2008 commented Nov 11, 2021

@kovidgoyal You've closed this issue, but with the very welcome news and effort from @clo-yunhee that WSLg preview is out and its Wayland GPU support is working, I was wondering whether or not you wanted me, or another interested party, (perhaps she if she wishes!) to pen a guide for its compilation and use. Then Kitty can say it supports all major desktop OS, a major win! I can't wait to make the .lnk Windows desktop icon file!

My request for WSL2 is rejected by security team, is there still any chance to make kitty work on Windows 10 ?

@octavz
Copy link

octavz commented Dec 12, 2021

Not affiliated: https://github.com/wez/wezterm.

Authors: Please remove the comment if out of place.

Thank you.

@danielbisar
Copy link

Hey tried kitty on windows 11 today with wsl2 and wrote a short guide: https://github.com/danielbisar/settings/blob/main/guides/kitty-on-windows-with-wsl2.md

@xiangpeng2008
Copy link

hi, any update on this ?

@xiangpeng2008
Copy link

Are there instructions somewhere for running kitty in WSL?

I'm trying this on Ubuntu 18.04 in WSL:

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin
~/.local/kitty.app/bin/kitty

I'm getting this error:

[101 16:34:27.269719] [glfw error 65543]: GLX: Forward compatibility requested but GLX_ARB_create_context_profile is unavailable
[101 16:34:27.270617] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.

I just installed wsl 1, and I got same error.

@ctrlcctrlv
Copy link
Contributor

It won't work on WSL 1.

@xiangpeng2008
Copy link

It won't work on WSL 1.

It worked on wsl 1, my problem now is it doesn't work on CentOS 7.9

@ctrlcctrlv
Copy link
Contributor

OK, it won't work well on WSL 1. Of course you can hack around the limitations with software rendering.

@danielbisar
Copy link

Since the dev is not interested in support windows at all. Have a look at wezterm.

@sbradnick
Copy link

Since the dev is not interested in support windows at all. Have a look at wezterm.

That's an unfair statement, expecting a dev to 'just make it work on windows' is not taking into account the complexity between two completely different OSes.

As @clo-yunhee mentioned, kitty works great in WSL2 w/ D3D12 ; personally I use it daily and I have ZERO expectations that I should just be able to run kitty.exe.

2022-05-21-110011_677x662_scrot

@TanZng
Copy link

TanZng commented Jul 13, 2022

@sbradnick how you manage to show the kitty with the window decoration in WSL2? When I open kitty it's open with some ugly "default" window decoration :(

image

@sbradnick
Copy link

@sbradnick how you manage to show the kitty with the window decoration in WSL2? When I open kitty it's open with some ugly "default" window decoration :(

image

I use VcXsrv vs. the :0 default for WSL2 (which, I believe, is based off Wayland for the backend virtualization which makes it all work); basically ignoring what makes WSLg an actual thing.

@ctrlcctrlv
Copy link
Contributor

I don't see why we can't consider better documentation and perhaps a command for running on Windows, but I'd say you're all right that WSLg is the way to go with this. I mean, making it work in D3D otherwise is…very complicated technically, I know, I have tried.

@ctrlcctrlv
Copy link
Contributor

(Kitty does not just have one developer, it has a very devoted maintainer, so writing "the dev" is a misunderstanding of how free software even works. It's not like Kovid tried and then everyone gave up. I know of at least one other besides myself who tried, until everyone agreed that WSLg is the best solution given the technical barriers.)

@FrostKiwi
Copy link

FrostKiwi commented Mar 27, 2023

Here are my 2 cents: I think neither D3D, nor WSL is required and huge mountain of work, whilst creating a rather heavy dependency.

A lot of projects were ported to Windows via Msys2 + MinGW64. Once ported and linked natively, they are native win32 applications, requiring neither WSL nor other .dlls to run. GLFW runs perfectly well and I have written multiple applications, statically compiled and dependency free with GLFW via MinGW64. I imagine porting that custom GLFW version as mentioned by @kovidgoyal, wouldn't be particularly hard considering we have rolling GLFW releases for years in the package manager now now and threading is supported via pthreads.

On the flip side, I'm sure there are painful platform dependent details a port would entail. Especially if if kitty makes heavy use of the fork() system call, since that entails a couple annoying workarounds with performance penalties...

@Tachi107
Copy link

Tachi107 commented Jun 18, 2023

Especially if if kitty makes heavy use of the fork() system call, since that entails a couple annoying workarounds with performance penalties...

After a quick search I saw that Kitty only uses fork() in child.c. That being said, it does a non-trivial amount of work in the child after forking, a thing that would be non trivial to replicate using spawn-style APIs, like posix_spawn().

@FrostKiwi, do you know if minGW implements posix_spanw() efficiently, or is it just a thin wrapper around fork() + exec()?

@FrostKiwi
Copy link

@FrostKiwi, do you know if minGW implements posix_spanw() efficiently, or is it just a thin wrapper around for() + exec()?

posix_spawn is definitely available, but I don't know how the implementation details are. That being said, maybe I chose my words too harshly. The performance of fork() is really not that bad. It's just, that there are programs which makes heavy use of it and there was a performance degradation when switching to MSYS2 + MinGW64 + libwinpthread. Shouldn't be too bad.

@mxaddict
Copy link

mxaddict commented Dec 1, 2023

Do any of you know how to make a shortcut to launch kitty without having to launch wsl terminal first?

@Kreijstal
Copy link

Thanks for quick reply.

Unixisms are not a problem if using MSYS which implements POSIX. So, those can be overcome as shown.

Somebody has to do the work of porting the various changes kitty has made to glfw to the windows glfw backends.

I will look into this :-) How hard do you think it would be?

if you are not going to port the unixism, cygwin is the only choice, msys is just a disabled cygwin fork to "cross-compile" from cygwin to real windows (no cygwin)

@linrongbin16
Copy link

linrongbin16 commented Mar 7, 2024

Thanks for quick reply.
Unixisms are not a problem if using MSYS which implements POSIX. So, those can be overcome as shown.

Somebody has to do the work of porting the various changes kitty has made to glfw to the windows glfw backends.

I will look into this :-) How hard do you think it would be?

if you are not going to port the unixism, cygwin is the only choice, msys is just a disabled cygwin fork to "cross-compile" from cygwin to real windows (no cygwin)

Besides, solutions rely on cygwin/msys will not be performant, performance is always a key feature for kitty terminal.

If we want kitty as performant as how it behaves on macos/linux, we have to rewrite the infrastructure & GPU rendering in a Windows way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests