closed source?

[frostworx]

interesting device, found it via https://www.cnx-software.com/2024/07/08/20-nanokvm-is-a-tiny-low-power-risc-v-kvm-over-ip-solution/#comments

but are you really planning to keep it closed source?

edit: finally ordered one 2 month later :)

[frostworx]

mount -t ext4 -o loop,offset=16777728 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the curious

edit:

whoops, forgot

mount -t vfat -o loop,offset=512 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the first partition

[frostworx]

a bit random grepping reveals that at least

https://github.com/hodgef/react-simple-keyboard
is used in the firmware

server/web/assets/index-u2n1Wr7j.css: * https://github.com/hodgef/react-simple-keyboard

[frostworx]

see also
https://news.ycombinator.com/item?id=40903461

[Zepan]

We are wondering wheter open or not.
At the early time (3month ago), we want make it opensource, only make the hardware, and port PiKVM on it with few develop work. but we realize it is not easy to run PiKVM on it, as it not support V4L2.
We send the hardware sample to some community developer who familiar with PiKVM, and they worked for 3month to port V4L2, and still working...(may finished in few month, when it finished, we will open PiKVM port)
we have to develop FW ourself, it takes about 2~3month, and we see >95% commit of PiKVM is written by author, so we think it may not help much if we opensource at the first time? keep this as a bug report repo maybe better?
Welcome feed back if you have better suggestion to work with community, we want a good balance with opensource and commerce.

[Zepan]

At least, we will open most interfaces/API for images,HID operations, that DIYer can customize their own functions without dig hard into complex bsp sdk.

[Zepan]

I make a vote on twitter: https://x.com/SipeedIO/status/1810508366336115192

[frostworx]

thank you for the comprehensive answer and also thanks for creating the poll.
(personally I don't use x-twitter, so I won't take part)

[ThomasKaiser]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

[shangri26199]

+1 for opensource without X account

[Zepan]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

[ThomasKaiser]

what about open backend(go), close frontend(react)?

I don't think that will stop people talking about your device being backdoored...

[seichold]

I bought a full and lite through the pre-order to check them out, but without the firmware being open source I do not think this will gain wide traction.

I really want this project to be successful as it brings a near order of magnitude cost reduction (and size!) to the ip based KVM world .

So take this as my (non X using) vote to work toward open source firmware.

[ElbPirat]

Also +1 on open source.
Pre-Ordered one for personal use, but searching something similar for my workshop/lab at work, other professional devices are too expensive for my superior... Would try to order a few once released.

[mintisan]

If it's just for playing around, closed-source is fine, but if it involves projects or production data, then I wouldn't use it [I have already bought one].

[bilogic]

i need HDMI to a monitor as well, is it possible with this hardware? or splitter?

[denern]

I have the LicheeRV Nano board and am familiar with PiKVM, how can I help you to finish?

[M0NsTeRRR]

I'm waiting for the code to be open source before buying one :)

[joubin]

evil.

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.
Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.
As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

I know many downvoted this. But if you’re willing to open source the backend and sell an SDK for enterprises that want to build their own front end anyways and integrate with their own Idps. Not sure. There might be something there

[brainstorm]

Here's another strategy that can be a win-win for both Sipeed and regular consumers of your product:

Commit to releasing it as opensource as soon as you've sold, say, 3000 units (arbitrary amount to be decided by Sipeed). Motivation behind this is:

1. It "secures" a (fixed, minimum) income threshold for Sipeed.
2. It motivates those buyers to purchase your product to accelerate it being opensource faster.

As it stands right now I'm siding with @M0NsTeRRR's position: if there is no clear commitment to release it as opensource, I'm not interested since I know that sooner or later the binary will be reverse engineered and re-implemented as OSS anyway (plus all the other security and future maintenance related concerns outlined in this issue).

EDIT: Current reversing efforts uncover worrying flaws: https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[timonoj]

I bought it first, assuming it was OSS from the beginning. I'm gonna wait for the OSS release. I can see them adding new features to their private fw every few days, but I'd rather very much just use OSS.

[scpcom]

I already took some look at LicheeRV-Nano-Build and this is what I found so far:

• freertos: contains pre-built cvitek audio libraries, did not take a closer look if this is required
• host-tools: pre-built compilers (no problem for me, can be replaced by distro/standard compliers)
• linux_5.10, opensbi and u-boot-2021.10: fully open source, can be built outside of LicheeRV-Nano-Build with minimal modifications
• middleware: contains pre-built libraries, I could not find the source for it
• osdrv: contains two pre-built modules (soph_vc_driver.ko and soph_jpeg.ko) but the source code was already released by cvitek/sophgo
• ramdisk: contains pre-built versions of standard packages like busybox (no problem for me, can be replaced by distro/standard versions)

The middleware should also be open-sourced (by the SoC vendor), it seems to be required for NanoKVM

PS: To get a better overview of the hardware related changes, I splitted out opensbi, u-boot and linux, re-based it to the original project git:
https://github.com/scpcom/linux/tree/licheervnano-5.10.y
https://github.com/scpcom/u-boot/tree/licheervnano-2021.10
https://github.com/scpcom/opensbi/tree/licheervnano-0.9
Currently the difference between LicheeRV-Nano-Build and my branches are only non-hardware-related like whitepaces and .gitignore.

[scpcom]

I almost finished my research on LicheeRV-Nano-Build and created the branches on forks of existing projects:

https://github.com/scpcom/linux/tree/licheervnano-5.10.y
https://github.com/scpcom/opensbi/tree/licheervnano-0.9
https://github.com/scpcom/u-boot/tree/licheervnano-2021.10

https://github.com/scpcom/buildroot/tree/licheervnano-2023.11
https://github.com/scpcom/FreeRTOS/tree/licheervnano

https://github.com/scpcom/sophgo-fsbl/tree/licheervnano
https://github.com/scpcom/sophgo-ramdisk/tree/licheervnano

https://github.com/scpcom/sophgo-build/tree/licheervnano
https://github.com/scpcom/sophgo-middleware/tree/licheervnano
https://github.com/scpcom/sophgo-osdrv/tree/licheervnano

Currently I am locally connecting them together as submodules, I may create and publish a top-level repo next, to make it easier.

If you look in the history you can see a replay of the commits to LicheeRV-Nano-Build splitted in to the sub projects.
They are similar with one exception:
The most interesting part is the 2.6G sized initial commit named "release" (bd39c05f39ab6d850d7c2c29a6b5ac617efc698a).
If you look in the history of my branches the size is reduced to less than 2M. You can easily watch it on github or in an editor.
It contains only the changes relevant for LicheeRV Nano now.

First I needed to find a point on the original project which is close to the current LicheeRV Nano version.
Then I made a diff and searched for more parts to exclude. I put things like wireless drivers into separate commits.
The goal was to get a better history and find the hardware relevant changes, the resulting code is identical.

Some notes about the content and references to the original projects:

buildroot
sophgo does also have a 2023.11 branch, but it s not the same:
https://github.com/sophgo/buildroot-2021.05/tree/buildroot-2023.11
It is clean 2023.11.2 plus overlay and some extra packages (downloads wifi firmware blobs and pre-built ld-musl-riscv64 libs)
https://github.com/buildroot/buildroot

freertos
Based on sophgo version with five extra tasks: camera, isp, vcodec, vi and vip
https://github.com/sophgo/freertos (https://github.com/FreeRTOS/FreeRTOS)
https://github.com/sophgo/FreeRTOS-Kernel (https://github.com/FreeRTOS/FreeRTOS-Kernel)
https://github.com/FreeRTOS/Lab-Project-FreeRTOS-POSIX
The binaries are just temp files from the compiler.

fsbl
No modifications, just one extra directory symlink (plat/sg200x)
https://github.com/sophgo/fsbl

host-tools
Not part of LicheeRV-Nano-Build, just:
https://github.com/sophgo/host-tools
compilers and toolchain

linux_5.10
sophgo linux_5.10 is very close to the XUANTIE-RV version but they decided to start
there branch with a blank 5.10.4 and mix XUANTIE-RV and there changes into one big commit
https://github.com/sophgo/linux_5.10/ (https://github.com/XUANTIE-RV/linux)

opensbi
Only few lines changed
https://github.com/XUANTIE-RV/opensbi

oss
Identical to:
https://github.com/sophgo/oss
Does not seem to contain sources, just older pre-compiled libs with headers and pkgconfig.

ramdisk
Contains some extra static linked binaries and configuration.
Two extra firmware blobs in rootfs/common_arm/usr/share/fw_vcodec,
I do not know if the blobs are really relevant or just leftovers from older sdk version.
https://github.com/sophgo/ramdisk

u-boot-2021.10
https://github.com/sophgo/u-boot-2021.10

The delta between LicheeRV-Nano-Build and the following repos (also some parts of the others)
is a bit dirty because sipeed used some sdk with a different naming scheme for the chips.
On the sophgo git versions they use "cv181x" in almost all cases for the chip used in LicheeRV Nano.
On the sdk used by sipeed they reference 3 different names in the code and directory/file names: cv181x, mars and sg200x.

build
https://github.com/sophgo/build
middleware
https://github.com/sophgo/middleware
osdrv
https://github.com/sophgo/osdrv

middleware
Still the repo with most blobs:
middleware/v2/modules/audio/lib
middleware/v2/modules/isp/lib
middleware/v2/3rdparty/cli

middleware/v2/sample/test_mmf (KVM Demo)
Contains a pre-compiled lib named libmaix_mmf.a (only for riscv64)
If you look in the history of LicheeRV-Nano-Build, you may find a file named
sophgo_middleware.c which seems to be/was the source code for it (and sophgo_middleware.h is equal to maix_mmf.h).

middleware/v2/sample/test_mmf/media_server-1.0.1
Contains fragments based on:
https://github.com/ireader/media-server
https://github.com/ireader/avcodec
https://github.com/ireader/sdk

If you add the missing parts you may be able to compile the libs found in
middleware/v2/sample/test_mmf/media_server-1.0.1/libs

[brainstorm]

Good reversing writeup on:

https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[scpcom]

Here is my version of the Nano-Build repo using the submodules described above:
https://github.com/scpcom/LicheeSG-Nano-Build

[polyzium]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

[M0NsTeRRR]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

A good start, glad to see that !

[ckotte]

They should open source everything in the first hand and not wait for whatever. I bought one too because I'm interested, but I can understand why people not want to buy it if it's running on closed source.

[MatthewCroughan]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

[polyzium]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

The NanoKVM is based on the LicheeRV Nano. If you want to make your own firmware, feel free, the information is located here.
That being said, I saw your tweet regarding concerns about stolen PiKVM code. The answer is no, their firmware is original and does not use PiKVM code. In fact, they even tried to port PiKVM to the NanoKVM hardware (if they are to be believed), but I assume it is either unoptimized or the hardware is a bit weak for it.
I also suggest you look at this article regarding reverse engineering of the firmware and software inside. I am pretty sure that the firmware is original again, considering that most of PiKVM is written in Python+C, while Sipeed's implementation uses Golang.
As for the security concerns, Sipeed has acknowledged them and will release a stable and more secure firmware in the near future. The product listing says "beta version" for a reason.

[MatthewCroughan]

@polyzium I saw those claims that they tried to port kvmd and related code, which is why I am surprised to see that they have none in their end product. Overall the release process for this thing hasn't been transparent enough for what the product does (provide backdoor access to your hardware). I'm aware of all of the things I can do myself, but I haven't got my hands on the hardware yet, despite applying for the beta boards. I was looking forward to putting NixOS and kvmd on the device, or building open firmware with Nix, for it.

[scpcom]

h264 is working with my kvm_vision variant too now.

[AkechiShiro]

@scpcom Is it possible that your changes make it upstream to the official firmware/linux (maybe not all changes but the improvements at least), basically into this repository?

[VFansss]

I know this will sound quite annoying, but I'm not able to truly understand all the comments and what happened with trying to fully open source the firmware/libraries: if someone buy a NanoKVM today, what kind of things can use/flash onto it to possibly only use open source components? There's still something closed source that must be used? What's the degree of risk using it, eventually?

Sorry for this "non technical" question but as everyone else I'm concerned about security of the device, and I'm not able to truly understand (as someone that doesn't have it right now, but plan to buy it if everything matches) the degree of uncertainty/obscurity if I use the device like it is vs what's available as totally open source

[scpcom]

@scpcom Is it possible that your changes make it upstream to the official firmware/linux (maybe not all changes but the improvements at least), basically into this repository?

I already created two pull requests in September:
sipeed/LicheeRV-Nano-Build#44
sipeed/LicheeRV-Nano-Build#45
Since there was no response I keep them opened and up-to-date but did not try to open new pull requests.

if someone buy a NanoKVM today, what kind of things can use/flash onto it to possibly only use open source components? There's still something closed source that must be used? What's the degree of risk using it, eventually?

If you use the original sources from Sipeed you have to put them all together yourself, and not all official sources are published yet, you still would require some closed source libs.
This is the reason why I created my own fork, put it all together and created open source replacements for the few missing libs. If you follow this comment you are able build your own image from source:
#1 (comment)

[scpcom]

Let's talk about the 7 closed source libs remaining.
This is not limited to Sipeed, they are part of cvitek/sophgo middleware.

libae.so, libaf.so, libawb.so: responsible for things like gain control
libisp_algo.so: algos for color correction, filters and profiles
libcvi_json-c.a, libcvi_miniz.a and libjson-c.so: used to parse isp_tuning sensor parameters found in /mnt/cfg/param/

If you have a Lichee RV Nano with camera module (a.k.a. MaixCAM) you may want to keep them.
But do we need them for NanoKVM? No.

Many of the lib symbols are referenced but during runtime of NanoKVM only 3 of them are really used in addition to the (Un)Register functions:
CVI_ISP_GetExposureAttr
CVI_ISP_SetExposureAttr
CVI_ISP_SetWDRExposureAttr

I did not want to harm the source code which is referencing ae, af and awb so I created dummy libs that almost do nothing:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/modules/dummy

algo, json-c and miniz is only used in libcvi_bin.so, libcvi_bin_isp.so and libisp.so.
There are two existing complier flags that allow to stop using them by just adding a Makefile:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/modules/isp_light
I added a thrid compiler flag named ISP_LIGHT which disables the few remaining parts:
https://github.com/scpcom/sophgo-middleware/blob/maix_mmf-cvisdk/modules/isp_light/Makefile#L69

On NanoKVM you will see not difference in quality, speed or functionality.
I made sure the dummy and light libs are only used inside the kvmapp folder, all other projects still can use the fully featured versions.
At this stage NanoKVM runs full open source now.

Something about licenses: I put my own commits under BSD 3-clause.
But since all work is based on existing code or part of existing project you have to check the source tree for the license used there.

[scpcom]

Now I took a look at the host-tools.

The arm versions are from linaro and can be found here too:
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-elf/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/arm-linux-gnueabihf/
Since they maybe not customized or required for NanoKVM I did not look at the git.

The riscv versions are based on Xuantie-900 GNU Toolchain V2.6.1 which can be found here:
https://github.com/XUANTIE-RV/xuantie-gnu-toolchain/tree/2023.03.08

This contains almost all we need with one exception: T-Head does not seem to offer a repository for the riscv-musl libc submodule.
I created a repository based on the patches found here:
https://github.com/openembedded/openembedded-core/blob/langdale/meta/recipes-core/musl/musl_git.bb
https://github.com/thead-yocto-mirror/meta-riscv/blob/langdale-thead-V1.1.2/recipes-core/musl/musl_%25.bbappend

The result can be found here:
https://github.com/scpcom/riscv-gnu-toolchain/tree/xuantie-gnu-toolchain-v2.6.x
https://github.com/scpcom/riscv-musl/tree/thead-sdk-v1.1.2
I put a copy of the build scipts here:
https://github.com/scpcom/LicheeSG-Nano-Build/tree/develop/host

The scripts work standalone, for example you can copy build-riscv-thead-musl-toolchain.sh to somewhere else and run it there. It will clone all required code before build.
Be aware if you build all three variants you need about 40GB free space and it takes about 12 hours to finish (multiple days on slower hosts).
If the build is done (or you download them from the Releases page) you can empty the host-tools/gcc folder and unpack the three tar archives there to use them to build the firmware image.

[scpcom]

All other pre-built host-tools like genimage are also build from source now, provided by linux, u-boot and buildroot:
scpcom/buildroot@02116db
scpcom/sophgo-build@682a4db
scpcom/sophgo-build@cec9ba1
scpcom/sophgo-build@f19053c
Now you do not need a AMD/Intel x86_64 host anymore to build the image. I verified the build is working at least on ARM aarch64 machines too.

Building tailscale from source is now also possible with LicheeSG-Nano-Build:
https://github.com/scpcom/buildroot/blob/nanokvm-2024.05/package/tailscale-riscv64/tailscale-riscv64.mk

You can enable it with:
./build-nanokvm.sh --tailscale
I keep it disabled by default because tailscaled is permanently calling the tailscale servers even if you not configured it and there is no option yet in the NanoKVM web interface to completely disable it.

[bt90]

It's rather sad to compare this botched attempt at open sourcing piece by piece with competitors like JetKVM, which manages to provide the full source code in a single repo.

https://github.com/jetkvm/kvm

[Frogomeli]

It's rather sad to compare this botched attempt at open sourcing piece by piece with competitors like JetKVM, which manages to provide the full source code in a single repo.

https://github.com/jetkvm/kvm

It's out of scope from this issue, but i don't see the source code of jetkvm_native used in native.go. Maybe I'm missing something.

[scpcom]

As far as I can see the jetkvm repo is just the app (web server) which is similar to the repository here: Can not be used standalone.
There is no bootloader (opensbi, u-boot etc), no kernel and no operating system. It maybe a alternative (if the hardware is available some day) but can not compared with the project(s) discussed here: providing a full firmware image for an existing product.

[geerlingguy]

From their Kickstarter update:

Here’s what’s available today:

• KVM Runtime & UI: The core application, written in Go, responsible for device functionality. Additionally, the UI for both the Cloud Dashboard and the local dashboard is stored in this repository. Link
• Cloud API: The cloud services, including the API, enabling remote access and management. Link
• Website & Docs: Comprehensive resources to help you get started. Link

The only missing piece is the system image repo, which will be added in the next few days, as we’re finalizing some essential details before a public release.

(Emphasis mine)

[bt90]

but can not compared with the project(s) discussed here: providing a full firmware image for an existing product.

And that is exactly my point. The product already exists and the open source part is still just a lip service.

[scpcom]

but can not compared with the project(s) discussed here: providing a full firmware image for an existing product.

And that is exactly my point. The product already exists and the open source part is still just a lip service.

For me a kickstarter project like jetkvm is "just a lip service" by design. They may do it better but at this moment we can just guess.
The base firmware image for NanoKVM was available from the beginning. The server/web sources followed later.
The sources for original maixcam_lib are still missing but they provided enough code to which made it possible to reproduce a fully functional replacement.

[scpcom]

The source code for sipeed kvm_system was added here now:
1db304a

It is build with MaixCDK, if you use my repository you can enable it with:
./build-nanokvm.sh --maixcdk
And you can combine it with tailsale if needed:
./build-nanokvm.sh --maixcdk --tailscale

[oliv3r]

@scpcom amazing work, really glad someone is picking up here.

You mentioned earlier:

If the build is done (or you download them from the Releases page)

But this did not accompany a link ;)

Anyway, are you hosting/releasing any images for the nanokvm? I'd like to built it, but the 40+gb disk space requirement makes it a bit hard at the moment ...

[scpcom]

You mentioned earlier:

If the build is done (or you download them from the Releases page)

But this did not accompany a link ;)

I only mentioned it for the toolchain, which can be found here:
https://github.com/scpcom/riscv-gnu-toolchain/releases/tag/riscv64-gcc-thead_20230307-10.2.0
Currently I do not plan to release any images. My focus is still on the source code and to make it as easy as possible to build your own image from it.

[scpcom]

Since I added a new github workflow (inspired by sophgo-sg200x-debian), the build process is fully transparent now and you can download the resulting ready-to-use stable images here:
https://github.com/scpcom/LicheeSG-Nano-Build/releases

I also started experimenting with Ubuntu (NanoKVM app and HDMI/camera input is already working, but keyboard/mouse control with USB gadget does not work):
https://github.com/scpcom/sophgo-sg200x-debian/releases

[howels]

Since I added a new github workflow (inspired by sophgo-sg200x-debian), the build process is fully transparent now and you can download the resulting ready-to-use stable images here: https://github.com/scpcom/LicheeSG-Nano-Build/releases

I also started experimenting with Ubuntu (NanoKVM app and HDMI/camera input is already working, but keyboard/mouse control with USB gadget does not work): https://github.com/scpcom/sophgo-sg200x-debian/releases

Do these work with the NanoKVM PCIe model, i.e. does your release include the updates in the official 1.3.0 release?

[scpcom]

It contains

• all updates from the NanoKVM repository here (app version 2.1.5 + Download button for ISO images)
• my open source version of the maixam_lib (does work with any device that has the same chip, no difference for PCIe-Slot variant)
• almost all other hardware specific things are based on the LicheeRV-Nano-Build repsitory and the chip vendors SDK

The settings of the PCIe version are done by the init.d scripts (/etc/init.d/S15kvmhwd and more) which are also included.
I do not think the 1.3.0 image itself does contain any extra content.
On the Debian/Ubuntu version I did not implement the WiFi setup yet, all other should work.

I do have a NanoKVM Lite and NanoKVM Full (Cube) for testing.
The NanoKVM PCIe is already shipping to me.

[howels]

It contains

* all updates from the NanoKVM repository here (app version 2.1.5 + Download button for ISO images)

* my open source version of the maixam_lib (does work with any device that has the same chip, no difference for PCIe-Slot variant)

* almost all other hardware specific things are based on the LicheeRV-Nano-Build repsitory and the chip vendors SDK

The settings of the PCIe version are done by the init.d scripts (/etc/init.d/S15kvmhwd and more) which are also included. I do not think the 1.3.0 image itself does contain any extra content. On the Debian/Ubuntu version I did not implement the WiFi setup yet, all other should work.

I do have a NanoKVM Lite and NanoKVM Full (Cube) for testing. The NanoKVM PCIe is already shipping to me.

Tried your latest build, initially I thought HDMI capture wasn't working on the nanokvm-pcie but I swapped from H264 to MJPEG and it sprung into life. On H264 I initially get the test-pattern of coloured stripes then when swapping back from MJPEG the site is stuck at "loading" with spinning dots.

[scpcom]

Tried your latest build, initially I thought HDMI capture wasn't working on the nanokvm-pcie but I swapped from H264 to MJPEG and it sprung into life. On H264 I initially get the test-pattern of coloured stripes then when swapping back from MJPEG the site is stuck at "loading" with spinning dots.

On NanoKVM Cube I can switch from H264 to MJPEG and vice versa without a problem. The only relevant difference between H264 and MJEPG is: MJPEG needs much more CPU on the client hardware (web browser) side.
The test-pattern is shown if no input is detected.
This also happens if the target system sends the "energy saving" signal to HDMI. In this case you can press a key or move the mouse over the test-pattern and the HDMI input will show up again.
But maybe the H264 needs more power and NanoKVM gets not enough via PCIe? I will look at it if the hardware arrives.

[howels]

Tried your latest build, initially I thought HDMI capture wasn't working on the nanokvm-pcie but I swapped from H264 to MJPEG and it sprung into life. On H264 I initially get the test-pattern of coloured stripes then when swapping back from MJPEG the site is stuck at "loading" with spinning dots.

On NanoKVM Cube I can switch from H264 to MJPEG and vice versa without a problem. The only relevant difference between H264 and MJEPG is: MJPEG needs much more CPU on the client hardware (web browser) side. The test-pattern is shown if no input is detected. This also happens if the target system sends the "energy saving" signal to HDMI. In this case you can press a key or move the mouse over the test-pattern and the HDMI input will show up again. But maybe the H264 needs more power and NanoKVM gets not enough via PCIe? I will look at it if the hardware arrives.

Thanks for getting a device to check, this device is powered via PoE as I haven't put it into a chassis yet. Don't think power is an issue as the PoE readout was well under 10W of draw, I think it was only using 3 or 4W.

[scpcom]

There is some update on the originial NanoKVM app:
libmaixcam_lib.so was replaced by libkvm_mmf.so (still no source code yet).
kvm_mmf is based on the same code as maixcam_lib but contains only the components required for NanoKVM.
Included: vi (video input) and venc (video encoder)
Removed: vo (video output), vdec (video decoder), avc2flv and nn (tpu)
The download of a lib dongled to the hardware is also removed now.

Update on my variant:
I did almost the same on my variant by disabling unused code with a compiler flag.
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/kvm_mmf

Before we had 75M ION memory and about 160M for the OS.
Now we can reduce the ION size to 35M which makes 196M total memory available to the OS (currently I changed the memory layout only on the Debian/Ubuntu version: 35M/196M for the kvm variant, 64M/168M for other variants).

I also removed the use of the old pre-built libcvi_bin_isp, it is built from source too now.

On the Debian/Ubuntu image NanoKVM is fully functional too now (as far as I tested), including:

• USB Gadget (Virtual Keyboard, Mouse, Network, Storage)
• WiFi Setup on NanoKVM PCIe (Client/Station Mode, I did not find a way to test AP mode yet)

PS: I can confirm that sometimes you get no picture on NanoKVM PCIe after login, but this also happend on the original image before I installed my on. On my images it always helped to move the mouse over the test pattern and the picture showed up.

[wj-xiao]

All the code is now open-source. And this issue is closed.

We'll be adding more documentation and build scripts in the near future.

For any other matters, please feel free to open a new issue for discussion.