We're getting a few more people who are actively requesting Linux support. The vast majority of our users are on Windows, so this is not something we can dedicate a significant amount of time to, but it is something that we can at least make some kind of effort to support.
The primary blocker that I can see is libobs-rs's support for Linux. They're working on it, so I don't expect this being an issue for much longer. Aside from that, we use a fair bit of Windows API functionality for input capture, window detection, hardware identification, and more; this is what I see giving us the most grief on our end (especially with Wayland...).
The subject of the interface has also been a bit contentious. @Clyde013's initial proposal was to disable the UI for Linux builds and set up a CLI instead. My concern with this is that it would add an additional, untested, codepath for interacting with OWL Control, and it risks going out of sync with the primary UI-based codepath.
There are two potential solutions here:
-
add a CLI codepath for everyone to use (which may also help with @exdysa's testing endeavour), and make sure that it shares as much with the UI as possible.
Getting this right (i.e. decoupling the existing code from the UI and harmonising the codepaths as much as possible) would take a fair bit of effort; I'm not ruling it out, but it doesn't seem like the best use of our time right now.
-
make the UI work on Linux. My suspicion is that this is not that much work: most of the libraries we're already using are cross-platform, so once we solve the first two problems, most of this should come for free.
Another alternative is to make OWL Control work in Wine. I haven't tested this and I don't know what the blockers are, but it would save us from having to redo all the Win32 stuff in a cross-platform way. I'm gonna hazard a guess and say that none of libobs's functionality will work under Wine, though, so support would have to come through a separate compiled-for-Linux shim or through use of the WebSocket recorder (which needs to be updated to sync up with the embedded recorder).
Given the amount of work involved here, I'm not going to prioritise this, but we should keep this in mind as we evolve the codebase to make sure that we don't make any future porting work more difficult.
We're getting a few more people who are actively requesting Linux support. The vast majority of our users are on Windows, so this is not something we can dedicate a significant amount of time to, but it is something that we can at least make some kind of effort to support.
The primary blocker that I can see is
libobs-rs's support for Linux. They're working on it, so I don't expect this being an issue for much longer. Aside from that, we use a fair bit of Windows API functionality for input capture, window detection, hardware identification, and more; this is what I see giving us the most grief on our end (especially with Wayland...).The subject of the interface has also been a bit contentious. @Clyde013's initial proposal was to disable the UI for Linux builds and set up a CLI instead. My concern with this is that it would add an additional, untested, codepath for interacting with OWL Control, and it risks going out of sync with the primary UI-based codepath.
There are two potential solutions here:
add a CLI codepath for everyone to use (which may also help with @exdysa's testing endeavour), and make sure that it shares as much with the UI as possible.
Getting this right (i.e. decoupling the existing code from the UI and harmonising the codepaths as much as possible) would take a fair bit of effort; I'm not ruling it out, but it doesn't seem like the best use of our time right now.
make the UI work on Linux. My suspicion is that this is not that much work: most of the libraries we're already using are cross-platform, so once we solve the first two problems, most of this should come for free.
Another alternative is to make OWL Control work in Wine. I haven't tested this and I don't know what the blockers are, but it would save us from having to redo all the Win32 stuff in a cross-platform way. I'm gonna hazard a guess and say that none of
libobs's functionality will work under Wine, though, so support would have to come through a separate compiled-for-Linux shim or through use of the WebSocket recorder (which needs to be updated to sync up with the embedded recorder).Given the amount of work involved here, I'm not going to prioritise this, but we should keep this in mind as we evolve the codebase to make sure that we don't make any future porting work more difficult.