kovidgoyal commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

see #947

Asheq commented 5 years ago

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 commented 5 years ago

Is there any word on Windows support yet?

creallfluharty commented 4 years ago

@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:

ctrlcctrlv commented 4 years ago

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

erikli commented 4 years ago

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 commented 4 years ago

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

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.

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...

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.

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.

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!!
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Luflosi commented 4 years ago

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

ctrlcctrlv commented 4 years ago

@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 commented 4 years ago

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

kovidgoyal commented 4 years ago

On Wed, Mar 25, 2020 at 12:52:15PM -0700, Fredrick Brennan wrote:

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!!)

glfw's keyboard handling was insufficient no support for input methods, dead keys, etc. (and is still insufficient see open keyboard issues).

And a run loop was added because glfw's design is fundamentally incompatible with cocoas design, which asumes cocoa is running the applications main loop and calling callbacks. This leads to various impossible to fix issues, just search for issues I have opened in upstream glfw to see details.

kovidgoyal commented 4 years ago

On Wed, Mar 25, 2020 at 12:52:56PM -0700, Fredrick Brennan wrote:

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

You're welcome I always like to encourage people that wish to hack on kitty.

ctrlcctrlv commented 4 years ago

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 commented 3 years ago

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

Luflosi commented 3 years ago

There hasn't been any progress on this.

ndavd commented 3 years ago

That's unfortunate.

clo-yunhee commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

There hasn't been any progress on this.

@Luflosi any progress ?

xiangpeng2008 commented 2 years ago

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 commented 2 years ago

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

xiangpeng2008 commented 2 years ago

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

Thanks !

ctrlcctrlv commented 2 years ago

@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 commented 2 years ago

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

xiangpeng2008 commented 2 years ago

@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 commented 2 years ago

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

Authors: Please remove the comment if out of place.

Thank you.

danielbisar commented 2 years ago

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 commented 2 years ago

hi, any update on this ?

xiangpeng2008 commented 2 years ago

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 commented 2 years ago

It won't work on WSL 1.

xiangpeng2008 commented 2 years ago

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 commented 2 years ago

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

danielbisar commented 2 years ago

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

sbradnick commented 2 years ago

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 commented 2 years ago

@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 :(

sbradnick commented 2 years ago

@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 :(

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 commented 2 years ago

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 commented 2 years ago

(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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 10 months ago

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

Kreijstal commented 9 months ago

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 commented 7 months ago

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.

kovidgoyal / kitty

windows 10 support? #640

Recipe

Final hurdle