## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Well, we figured out the first part(PR TITLE) and forgot about the
labelling part. 😅 Consult #87 for more info
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
We are using my personal account key to do autolabelling. This used to
work when the project was under my personal, but now it breaks whenever
some 3rd party tries to open a PR
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Supervisord fails to run as user `netris` no longer exists. So we are
renaming all occurrences of old username with new username `nestri`
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
This PR is the first in a series of PRs trying to solve the issue #48 by
renaming `Netris` to `Nestri` to avoid Trademark legal issues.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Update the README to show how to how to run Netris.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
This is a catch all PR that tries to smooth out the creases found while
playing using Netris.
What i have found so far:
1. Change `NAME` environment to `SESSION_ID` for warp server.
2. Run `entrypoint.sh` and `warp-input` as user `netris`
3. Netris-proton is broken, it quits prematurely. I think it has to be a
problem with a missing wine installation
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
`Warp-input` server errors out when the namespace or `session_id` has
not yet been created on our relay.
This is a problem, as we do not know when the user will start playing.
The idea is to have the bin/input run both a server and a client at the
same time. Which can be used to then transmit bidirectional information.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
We need to remove the inputtino server, and replace it with `warp-input`
server, which is developed in-house and it works.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
We start the container using supervisord, which is limiting as the user
has no way of telling the container what game to run. So, the idea is to
run like so: `docker run... ghcr.io/netrisdotme/netris/server:<tag>
netris-proton /game/yourgame.exe`
Co-authored by @djpremier
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Currently, the container fails when trying to download drivers for a
container running non-proprietary Nvidia drivers. So, this is a fix
which searches for numbers rather than a fixed point in the string.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
With help from @djpremier, rename `/usr/bin/netris/proton` as "the
script cannot be found in bash `(eg.: $ proton -r /games/AlanWake.exe)`
if it is in the subdirectory of /usr/bin, probably because it is found
in a subdir inside `/usr/bin` "
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
There is a bug whereby `netris/warp-input` does not build and deploy a
new nightly docker image when a pr is merged. This happens when there
are changes in `bin/input/**` directory, and this is not the expected
behaviour. So i added the directory back into the `warp-input.yml`
workflow file.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
I am having issues trying to append `input` to the session_id using
bash. Most probably because supervisord is using the ENV variables
already available in the container. So, here we append the `input` part
inside the rust binary instead. This is much cleaner and it works.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
`warp-input.yml` workflow was not getting invoked on push. So, I change
the `Github Token` which has broader permissions.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Well, I tried doing a release and it did not go as expected, due to some
issues with the git_token plus concurrency. So, i have fixed that... let
us do a re-release.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
So, we need a README.md at the root of the project, to at least welcome
anyone who might be interested in the project.
It should have:
- [ ] link to the `/play` endpoint to get a `session_id` for starting up
the server.
- [ ] (basic) info about how it works
- [ ] features
- [ ] images and/or gifs showcasing the project
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
There seems to be a problem with auto-labeler labelling `type:docs`. So
i am adding to check on the `docs/**` branch too and label that
accordingly.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
We cannot use golang for our input binary as we will be redoing the
Webtransport stack, plus we will have to use CGO in-order to hook into
X11. Like what [neko](https://github.com/m1k1o/neko) does.
However, we could go down the Rust route, where X11 mouse/keyboard
drivers are in pretty, and moq-rs (the MoQ library using Webtransport)
works really well. So, that is what am trying to do here; implement
input using rust.
## Description
**What issue are you solving (or what feature are you adding) and how
are you doing it?**
Doing some ground work for the input server, here I am initializing a go
project. That's all
## Description
**What(what issue does this code solve/what feature does it add):**
Dependabot does not have a `build` semver type and it keeps triggering
the autolabeller. So, i added that in there, plus slimmed down the
pull_request_template as it required too much info, which made it too
cumbersome filling it
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
…devices
## Description
**What(what issue does this code solve/what feature does it add):**
Currently we get a permission error when trying to create a mouse.
On further investigation, we realise that we have to run
`/inputtino/input-server` as sudo/root.
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
Update the moq-server submodule to support audio
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We need to support feedback for mouse and keyboard.
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
Build times for netris:server are way too long. so the idea is to move
warp into it's own container then build from there.
Later on first release we might drop this for a better solution.
**How(how does it solve it):**
1. Added the very own netris:warp
## Required Checklist:
- [x] I have added any necessary documentation and comments in my code
(where appropriate)
- [x] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
Docker build server fails because `supervisord.conf` is getting copied
to a different directory other than `/etc`
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We do not need the ffmpeg and recorder all sitting differently, as this
will increase our docker image size
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
`Warp` will be used to "trasmit" the video and audio from the container
to the user/viewer wherever they are.
**How(how does it solve it):**
1. Add a Github worker that builds warp on pr, and one that builds and
pushes on release
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
**How(how does it solve it):**
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We succesfully built the gpu-screen-recorder in a separate container...
now we need to add it into the main container
**How(how does it solve it):**
1. Copy the relevant user/bin files from the separate docker image
2.
## Required Checklist:
- [x] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We do not have a way to capture sound inside the container.
**How(how does it solve it):**
1. Install pulseaudio inside the container
2. Add an entrypoint.sh where we start the pulseaudio
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
So, we have our simple compositor (`gamescope`), now we need a way to
capture audio and video.
And i have found this "performant" **_citation needed_ ** and minimal
screen recorder, which has the capability to even capture 30 second
screen snippets.
**How(how does it solve it):**
1. Add a minimal step inside the DockerFile to build and install the
gpu-screen-recorder
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We are adding mangohud (to show GPU usage), gamemode (for optimisations)
and gamescope (as our compositor)
**How(how does it solve it):**
1. Apt install mangohud
2. Install gamescope from flatpak
3. And then build gamemode
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We have no display server inside the container, nor Vulkan which will
later be required by dxvk/d3d11/d3d12 in order to play games using
Proton.
**How(how does it solve it):**
1. We added vulkan and Xwayland packages into `server.Dockerfile` , then
tested with running `vkcube` and `vulkaninfo` after running an
interactive bash shell inside the container.
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
Currently on `docker run --gpus 1 netris:server` and run `nvidia-smi`
you get an error.
**How(how does it solve it):**
We add the relevant NVIDIA_* env variables to allow for gpu passthrough.
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
Co-authored-by: Wanjohi <71614375+wanjohiryan@usersnoreply.github.com>
## Description
**What(what issue does this code solve/what feature does it add):**
Add a qwik project where we can add API(s) and a frontend which will be
used to review and deploy to AWS our docker containers for testing.
**How(how does it solve it):**
1. Initialise a qwik project at `apps/www`
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
Add a way to configure the Nvidia GPU, by installing the necessary
packages for Proton to work.
**How(how does it solve it):**
We made a script `.scripts/gpu` when called like `gpu -c` it will
install Vulkan and proprietry nvidia drivers.
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We are adding the `Dockerfile` with all the scripts and programs to run
our games in.
**How(how does it solve it):**
1. Add `serverDockerfile` which contains all the docker code.
2. Add `.scripts` folder where we will store all the scripts; for
example in our case, where proton installation script will reside.
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
## Description
**What(what issue does this code solve/what feature does it add):**
We are adding the `Dockerfile` to build a moq-relay
**How(how does it solve it):**
1. Added `relay.Dockerfile` with all the docker code to build
kixelated's moq-relay.
2. Added `relay.yml` in workflows for building and publishing the docker
image
## Required Checklist:
- [ ] I have added any necessary documentation and comments in my code
(where appropriate)
- [ ] I have added tests to make sure my code runs in all contexts
## Further comments
Wanjohi
