GitHub C Daily Trending Repositories

opa334/Dopamine

Dopamine is a semi-untethered jailbreak for iOS 15 to 26(.0.1)

Dopamine

A rootless semi-untethered jailbreak for iOS 15.0 - 17.3.1 (arm64e), iOS 15.0 - 18.7.1, 26.0 - 26.0.1 (A12/A13) and iOS 15.0 - 18.7.1 (arm64). More details will follow here soon.

Please note that all issues related to version support will be deleted without response.

Official website / download: https://ellekit.space/dopamine/

Crementif/BotW-BetterVR

A project aimed at providing a better PC VR mode for BotW using the Cemu emulator

BetterVR is a VR mod/hook that adds a PC-VR mode for BotW using the Wii U emulator called Cemu.

It currently supports the following features:

Fully stereo-rendered with 6DOF, with full roomscale support. No alternated eye rendering is used.
Full hands and arms support. You can deck yourself out in all the fanciest clothes.
Wield weapons, torches and bokoblin arms into combat.
Gestures to equip and throw weapons.
Use motion controls to interact with the world to solve puzzles or start fires.
Large mod compatibility. BetterVR only modifies the code and no game data. Most other mods should be compatible.
Optional third-person mode.

Requirements

Supported VR headsets:

The app currently utilizes OpenXR, which is supported on all the major headsets (Valve Index, HTC Vive, Oculus Rift, Meta Quest, Windows Mixed Reality etc.). However, controller bindings are currently only provided for Oculus Touch controllers. While more integrated solutions are being found out, there's probably ways to setup OpenXR mappings through SteamVR or other applications.

Other Requirements:

A gaming PC with a CPU that is good at single-threaded workloads (a recent Intel i5 or Ryzen 5 are recommended at least)! The GPU matters a bit, but the CPU is the bottleneck here.
A legal copy of BotW for the Wii U.
Windows OS. It doesn't work under Linux (even with Wine/Proton) for now.
A properly set up Cemu emulator that's able to run at 60FPS or higher. See this guide for more info.
- Before reporting issues, make sure that you have a WORKING version of the game that can go in-game on your PC before you install this mod!
A recent Cemu version. Only Cemu 2.6 is tested to work.

Current Limitations & Known Issues

There's a small chance that the screen stays black after exiting any menus, which requires restarting the game to continue.
Climbing ladders require jumping up the ladder to go up and you have to look at the ladder.
You can get stuck behind ladders sometimes, especially when you stop moving at the very top of the ladder while climbing down. So keep moving at the start!
It'll lack some comfort options for now, like a left-handed mode ~~or snap turning~~ (added).

Mod Installation

Tip

Meta/Oculus Link has terrible frame interpolation that will make game appear to run much worse while also making the grass and arms glitchy, even while using a cable. Its HIGHLY recommended to use ALVR (free, both wired and wireless), Virtual Desktop (paid, wireless, most performant) or Steam Link (free, wireless) instead for Meta Quest headsets.

Download the latest BetterVR_Launcher.exe release from the Releases page.
Move BetterVR_Launcher.exe into the same folder as Cemu.exe.
Modify the general Cemu settings first by launching the Cemu.exe and looking for the following things.
- Cemu's window title says your Cemu is version 2.6 or newer.
- Breath of the Wild is inside your game list, and lists update V208 in the update column.
- Go to Debug -> Accurate Barriers (Vulkan) and make sure it is disabled for better performance.
- Go to Options -> General Settings -> Graphics. Make sure that the Renderer is set to Vulkan, that the correct GPU is selected, and VSync is off. Close the settings window.
- Go to Options -> Graphic Packs and click the Download Community Graphic Packs button to make sure that your graphic packs are up to date.
Close Cemu, connect your VR headset to your PC, start Virtual Desktop, SteamVR and and make sure that it has its OpenXR runtime set properly:
- For Virtual Desktop users: https://github.com/mbucchia/VirtualDesktop-OpenXR/wiki#download--installation
- For SteamVR, ALVR and Meta Quest Link users: https://academy.vrex.no/knowledge-base/openxr/
Run BetterVR by using the BetterVR_Launcher.exe, then go to Options -> Graphic packs -> The Legend of Zelda: Breath of the Wild and make sure:
- BetterVR is enabled.
- Mods -> FPS++ is enabled. The game will crash without it.
Besides those, there's some other recommended graphic pack settings to make your game run properly and look better in VR:
- Graphics:
  - Set the VR Resolution Multiplier to change the resolution of the game when you're in VR. The mod is not very GPU intensive, so using a higher multiplier might not cost any performance.
  - Set the Anti-Aliasing to Nvidia FXAA or None (if you are using 2x resolution multiplier or higher).
  - Use the optional recording mode above the VR Resolution Multiplier to render pixels outside of your VR headset's field-of-view to fit a 16:9 aspect ratio.
- FPS++: Set the FPS limit to at least 120 or 144. Your headset/runtime will still control the actual VR framerate.
- Enhancements: Set anisotropic filtering to 16x, and optionally set a Clarity preset to make the colors less washed out.
[Optional] To avoid some heavy stutters when you first start the game, download the shader caches from https://chriztr.github.io/cemu_shader_and_pipeline_caches/ and follow the How to install the caches section on that page.
Double click the game in Cemu's game list while your VR headset is turned on and connected. If things went correctly, you should now be playing the game in VR!

Use the in-game BetterVR menu to see the BetterVR settings and controls guide (hold the X or equivalent button on your left VR controller, or long press the Menu button on your Xbox controller).
In the settings you can also enable an option to immediately start the game when you start the BetterVR_Launcher.exe. You can also add this executable to Virtual Desktop, SteamVR etc. as a non-official Steam game.

Troubleshooting

Here's some steps to help you debug issues when the game fails to launch:

Verify that you've got a working game copy. Use Cemu.exe and launch the game normally. If you can load the game normally, it should work.
Make sure that if you're using a laptop, both your integrated graphics card and your dedicated graphics card drivers are updated. Make sure that its also plugged into a wall outlet and that its NOT using a power saving setting.
Unfortunately, some older AMD GPUs might have issues. See contact options below to help us squash these.
Uninstall any Vulkan overlays or layers that might cause issues. Programs like Overwolf, RTSS and other things CAN cause issues, though certainly not guaranteed.
Go over all the installation steps one more time and make sure that you didn't diverge from any of the steps. If you're seeing a green screen, it means that the Vulkan layer isn't enabled. This is likely due to using OpenGL in Cemu's settings.
If Cemu shows a Vulkan error like -13, these issues are likely GPU driver related.

If none of these steps helped, check the BotW support channel on the Flat2VR Discord server (recommended) or make a GitHub issue. Me and other people will try to help you in our spare time.

Controls

You can now view the controls in-game now by opening the BetterVR menu by holding the X button on your left VR controller. With Valve Index Controllers you can use the A button. For Xbox/Playstation etc. controllers, long press the Start button and use the mouse for changing settings.

You can find the controller image here (click to enlarge):

Technical Overview

Rendering an image to the VR headset

This mod ships with no game files, so you might ask how it works.

The game starts with the BetterVR Vulkan layer enabled. The Vulkan layer, which comes in the form of the .DLL file, is then able to intercept the Vulkan commands that Cemu submits so that we can get the final frame to render to the VR headset and draw the debugging tools.

A technical hurdle here was that due to OpenXR frameworks not being designed to be instantiated inside something that is intercepting Vulkan commands, this mod utilizes Vulkan <-> D3D12 interop to pipe the rendered output from Vulkan to a D3D12 application that's just used for rendering the captured image to the VR headset. That way the OpenXR framework is just interacting with root-level rendering handles, instead of what'd occur in the Vulkan hook.

Using an external DLL originally made a lot of sense when Cemu wasn't open-sourced (though it also makes it slightly less tied to a specific emulator or version of Cemu, and prevents a VR specific version of Cemu that'll quickly become outdated). In hindsight, it probably would've saved a lot of time spent trying to get the mod to work without using D3D12.

How to make it VR

However, while drawing the game's rendered output to the VR headset is one thing, getting a native game to render a 3D image is a whole other thing. For that, the mod has a bunch of PowerPC assembly patches (the Wii U has a PowerPC CPU) to modify the game's code. For example, an important patch is to make it so that the game renders two frames before updating all of the game's systems and objects that are on-screen. Then, among many other patches, you'll also find patches that change the camera or player model positions each frame, or trigger an attack.

Usually the assembly code will call into the C++ code if it wants to do complicated algebra to specify where the camera or Link's hands should be for example. And some assembly patches use a clearing instruction for the Wii U's GPU which, after being translated, will signal the Vulkan hook to send the almost-finished final game image to the D3D12 code where it can present it inside the VR headset.

Additionally, since combat is a large part of the original game, there's also a new swing and stab detection system that allows the player to cut trees and enemies down when they execute proper swings and stabbing motions. This prevents a situation where weapon hitboxes are abused to instantly stagger an enemy. There's plans for an even deeper integration, but as of today that's about it. This is fully optional since the mod still features an attack button, but the latter will offer a lot more immersion.

Understanding how the game works, finding and patching the exact parts inside the game's executable is by far the most difficult part and it took thousands of hours of reverse-engineering. Its without a doubt the most time consuming task of this VR mod, especially since this game uses a custom C++ engine of which is not much known about other then the good work of the (largely unfinished, but still very helpful) decompilation project.

If you want to know more about the technical details, feel free to ask in the BetterVR related channels in the Flat2VR Discord server. There's enough that was skipped over or left out in this explanation.

Build Instructions (For Developers)

Install the latest Vulkan SDK from https://vulkan.lunarg.com/sdk/home#windows and make sure that VULKAN_SDK was added to your environment variables.
Install vcpkg (make sure to run the bootstrap and install commands it mentions) and use the following command to install the required dependencies: vcpkg install openxr-loader:x64-windows-static-md glm:x64-windows-static-md vulkan-headers:x64-windows-static-md imgui:x64-windows-static-md
Change the CMakeUserPresets.json file to contain the directory where you've stored vcpkg. Its currently hardcoded. If you want to use Meta XR Simulator (which is quite helpful during debugging), you should change its path now too. Meta XR Simulator doesn't work unless you edit the [install folder]/config/sim_core_configuration.json file from "disable_interop": false, to "disable_interop": true,.
[Optional] Download and extract a new Cemu installation to the Cemu folder that's included. This step is technically not required, but it's the default install location and makes debugging much easier.
Use Visual Studio (Recommended) or Clion to open the CMake project. Make sure that it's compiling a x64 build.
For direct Visual Studio debugging, its recommended that instead of launching the BetterVR_Launcher, you set-up a launch.vs.json that launches Cemu.exe with the .dll loaded. Once the CMake project is open in VS (make sure its not ran as admin), go to Debug->Debug and Launch Settings for BetterVR_Layer. With that open, copy the configuration from launch.vs.json and replace the placeholder paths.
If step 6 doesn't work, you can also just launch the BetterVR_Project by debugging the BetterVR_Launcher target (make sure to pick the Install option). You might have to manually attach or install a multi-process debugging extension.

Credits

Crementif: Main Developer
Acudofy: Sword & stab analysis system
Holydh: Developed the input systems
leoetlino: For the BotW Decomp project, which was very useful
Exzap: Technical support and optimization help
Mako Marci: Edited the trailer, made the logo and controller guide
Tim, Mako Marci, Solarwolf07, Elliott Tate & Derra: Helped with testing, recording, feedback and support

Licenses

This project is licensed under the MIT license. BetterVR also uses the following libraries:

nothings/stb

stb single-file public domain libraries for C/C++

stb

single-file public domain (or MIT licensed) libraries for C/C++

This project discusses security-relevant bugs in public in Github Issues and Pull Requests, and it may take significant time for security fixes to be implemented or merged. If this poses an unreasonable risk to your project, do not use stb libraries.

Noteworthy:

image loader: stb_image.h
image writer: stb_image_write.h
image resizer: stb_image_resize2.h
font text rasterizer: stb_truetype.h
typesafe containers: stb_ds.h

Most libraries by stb, except: stb_dxt by Fabian "ryg" Giesen, original stb_image_resize by Jorge L. "VinoBS" Rodriguez, and stb_image_resize2 and stb_sprintf by Jeff Roberts.

library	latest version	category	LoC	description
stb_vorbis.c	1.22	audio	5584	decode ogg vorbis files from file/memory to float/16-bit signed output
stb_hexwave.h	0.5	audio	680	audio waveform synthesizer
stb_image.h	2.30	graphics	7988	image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC
stb_truetype.h	1.26	graphics	5079	parse, decode, and rasterize characters from truetype fonts
stb_image_write.h	1.16	graphics	1724	image writing to disk: PNG, TGA, BMP
stb_image_resize2.h	2.18b	graphics	10679	resize images larger/smaller with good quality
stb_rect_pack.h	1.01	graphics	623	simple 2D rectangle packer with decent quality
stb_perlin.h	0.5	graphics	428	perlin's revised simplex noise w/ different seeds
stb_ds.h	0.67	utility	1895	typesafe dynamic array and hash tables for C, will compile in C++
stb_sprintf.h	1.10	utility	1906	fast sprintf, snprintf for C/C++
stb_textedit.h	1.14	user interface	1429	guts of a text editor for games etc implementing them from scratch
stb_voxel_render.h	0.89	3D graphics	3807	Minecraft-esque voxel rendering "engine" with many more features
stb_dxt.h	1.12	3D graphics	719	Fabian "ryg" Giesen's real-time DXT compressor
stb_easy_font.h	1.1	3D graphics	305	quick-and-dirty easy-to-deploy bitmap font for printing frame rate, etc
stb_tilemap_editor.h	0.42	game dev	4187	embeddable tilemap editor
stb_herringbone_wa...	0.7	game dev	1221	herringbone Wang tile map generator
stb_c_lexer.h	0.12	parsing	941	simplify writing parsers for C-like languages
stb_divide.h	0.94	math	433	more useful 32-bit modulus e.g. "euclidean divide"
stb_connected_comp...	0.96	misc	1049	incrementally compute reachability on grids
stb_leakcheck.h	0.6	misc	194	quick-and-dirty malloc/free leak-checking
stb_include.h	0.02	misc	295	implement recursive #include support, particularly for GLSL

Total libraries: 21 Total lines of C code: 51166

FAQ

What's the license?

These libraries are in the public domain. You can do anything you want with them. You have no legal obligation to do anything else, although I appreciate attribution.

They are also licensed under the MIT open source license, if you have lawyers who are unhappy with public domain. Every source file includes an explicit dual-license for you to choose from.

How do I use these libraries?

The idea behind single-header file libraries is that they're easy to distribute and deploy because all the code is contained in a single file. By default, the .h files in here act as their own header files, i.e. they declare the functions contained in the file but don't actually result in any code getting compiled.

So in addition, you should select exactly one C/C++ source file that actually instantiates the code, preferably a file you're not editing frequently. This file should define a specific macro (this is documented per-library) to actually enable the function definitions. For example, to use stb_image, you should have exactly one C/C++ file that doesn't include stb_image.h regularly, but instead does

#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

The right macro to define is pointed out right at the top of each of these libraries.

Are there other single-file public-domain/open source libraries with minimal dependencies out there?

Yes.

If I wrap an stb library in a new library, does the new library have to be public domain/MIT?

No, because it's public domain you can freely relicense it to whatever license your new library wants to be.

What's the deal with SSE support in GCC-based compilers?

stb_image will either use SSE2 (if you compile with -msse2) or will not use any SIMD at all, rather than trying to detect the processor at runtime and handle it correctly. As I understand it, the approved path in GCC for runtime-detection require you to use multiple source files, one for each CPU configuration. Because stb_image is a header-file library that compiles in only one source file, there's no approved way to build both an SSE-enabled and a non-SSE-enabled variation.

While we've tried to work around it, we've had multiple issues over the years due to specific versions of gcc breaking what we're doing, so we've given up on it. See https://github.com/nothings/stb/issues/280 and https://github.com/nothings/stb/issues/410 for examples.

Some of these libraries seem redundant to existing open source libraries. Are they better somehow?

Generally they're only better in that they're easier to integrate, easier to use, and easier to release (single file; good API; no attribution requirement). They may be less featureful, slower, and/or use more memory. If you're already using an equivalent library, there's probably no good reason to switch.

Can I link directly to the table of stb libraries?

You can use this URL to link directly to that list.

Why do you list "lines of code"? It's a terrible metric.

Just to give you some idea of the internal complexity of the library, to help you manage your expectations, or to let you know what you're getting into. While not all the libraries are written in the same style, they're certainly similar styles, and so comparisons between the libraries are probably still meaningful.

Note though that the lines do include both the implementation, the part that corresponds to a header file, and the documentation.

Why single-file headers?

Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)

There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.

Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)

Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.

Why "stb"? Is this something to do with Set-Top Boxes?

No, they are just the initials for my name, Sean T. Barrett. This was not chosen out of egomania, but as a moderately sane way of namespacing the filenames and source function names.

Will you add more image types to stb_image.h?

No. As stb_image use has grown, it has become more important for us to focus on security of the codebase. Adding new image formats increases the amount of code we need to secure, so it is no longer worth adding new formats.

Do you have any advice on how to create my own single-file library?

Yes. https://github.com/nothings/stb/blob/master/docs/stb_howto.txt

Why public domain?

I prefer it over GPL, LGPL, BSD, zlib, etc. for many reasons. Some of them are listed here: https://github.com/nothings/stb/blob/master/docs/why_public_domain.md

Why C?

Primarily, because I use C, not C++. But it does also make it easier for other people to use them from other languages.

Why not C99? stdint.h, declare-anywhere, etc.

I still use MSVC 6 (1998) as my IDE because it has better human factors for me than later versions of MSVC.

SchedMD/slurm

Slurm: A Highly Scalable Workload Manager

Slurm Workload Manager

This is the Slurm Workload Manager. Slurm is an open-source cluster resource management and job scheduling system that strives to be simple, scalable, portable, fault-tolerant, and interconnect agnostic. Slurm currently has been tested only under Linux.

As a cluster resource manager, Slurm provides three key functions. First, it allocates exclusive and/or non-exclusive access to resources (compute nodes) to users for some duration of time so they can perform work. Second, it provides a framework for starting, executing, and monitoring work (normally a parallel job) on the set of allocated nodes. Finally, it arbitrates conflicting requests for resources by managing a queue of pending work.

NOTES FOR GITHUB DEVELOPERS

The official issue tracker for Slurm is at

: https://support.schedmd.com/

We welcome code contributions and patches. Please see the contributing guidelines for further details.

SOURCE DISTRIBUTION HIERARCHY

The top-level distribution directory contains this README as well as other high-level documentation files, and the scripts used to configure and build Slurm (see INSTALL). Subdirectories contain the source-code for Slurm as well as a test suite and further documentation. A quick description of the subdirectories of the Slurm distribution follows:

src/ [ Slurm source ]

: Slurm source code is further organized into self explanatory subdirectories such as src/api, src/slurmctld, etc.

doc/ [ Slurm documentation ]

: The documentation directory contains some latex, html, and ascii text papers, READMEs, and guides. Manual pages for the Slurm commands and configuration files are also under the doc/ directory.

etc/ [ Slurm configuration ]

: The etc/ directory contains a sample config file, as well as some scripts useful for running Slurm.

slurm/ [ Slurm include files ]

: This directory contains installed include files, such as slurm.h and slurm_errno.h, needed for compiling against the Slurm API.

testsuite/ [ Slurm test suite ]

: The testsuite directory contains an extensive collection of tests written for Check, Expect and Pytest.

auxdir/ [ autotools directory ]

: Directory for autotools scripts and files used to configure and build Slurm

contribs/ [ helpful tools outside of Slurm proper ]

: Directory for anything that is outside of slurm proper such as a different api or such. To have this build you need to do a make contrib/install-contrib.

COMPILING AND INSTALLING THE DISTRIBUTION

Please see the instructions at

: https://slurm.schedmd.com/quickstart_admin.html

Extensive documentation is available from our home page at

: https://slurm.schedmd.com/slurm.html

LEGAL

Slurm is provided "as is" and with no warranty. This software is distributed under the GNU General Public License, please see the files COPYING, DISCLAIMER, and LICENSE.OpenSSL for details.

lz4/lz4

Extremely Fast Compression algorithm

LZ4 - Extremely fast compression

LZ4 is lossless compression algorithm, providing compression speed > 500 MB/s per core, scalable with multi-cores CPU. It features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems.

Speed can be tuned dynamically, selecting an "acceleration" factor which trades compression ratio for faster speed. On the other end, a high compression derivative, LZ4_HC, is also provided, trading CPU time for improved compression ratio. All versions feature the same decompression speed.

LZ4 is also compatible with dictionary compression, both at API and CLI levels. It can ingest any input file as dictionary, though only the final 64KB are used. This capability can be combined with the Zstandard Dictionary Builder, in order to drastically improve compression performance on small files.

LZ4 library is provided as open-source software using BSD 2-Clause license.

Benchmarks

The benchmark uses lzbench, from @inikep compiled with GCC v8.2.0 on Linux 64-bits (Ubuntu 4.18.0-17). The reference system uses a Core i7-9700K CPU @ 4.9GHz (w/ turbo boost). Benchmark evaluates the compression of reference Silesia Corpus in single-thread mode.

Compressor	Factor	Compression	Decompression
memcpy	1.000	13700 MB/s	13700 MB/s
LZ4 default (v1.9.0)	2.101	780 MB/s	4970 MB/s
LZO 2.09	2.108	670 MB/s	860 MB/s
QuickLZ 1.5.0	2.238	575 MB/s	780 MB/s
Snappy 1.1.4	2.091	565 MB/s	1950 MB/s
Zstandard 1.4.0 -1	2.883	515 MB/s	1380 MB/s
LZF v3.6	2.073	415 MB/s	910 MB/s
zlib deflate 1.2.11 -1	2.730	100 MB/s	415 MB/s
LZ4 HC -9 (v1.9.0)	2.721	41 MB/s	4900 MB/s
zlib deflate 1.2.11 -6	3.099	36 MB/s	445 MB/s

Installation

make
make install     # this command may require root permissions

LZ4's Makefile supports standard Makefile conventions, including staged installs, redirection, or command redefinition. It is compatible with parallel builds (-j#).

Building LZ4 - Using vcpkg

You can download and install LZ4 using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg.exe install lz4

The LZ4 port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Documentation

The raw LZ4 block compression format is detailed within lz4_Block_format.

Arbitrarily long files or data streams are compressed using multiple blocks, for streaming requirements. These blocks are organized into a frame, defined into lz4_Frame_format. Interoperable versions of LZ4 must also respect the frame format.

Other source versions

Beyond the C reference source, many contributors have created versions of lz4 in multiple languages (Java, C#, Python, Perl, Ruby, etc.). A list of known source ports is maintained on the LZ4 Homepage.

Packaging status

Most distributions are bundled with a package manager which allows easy installation of both the liblz4 library and the lz4 command line interface.

Special Thanks

Takayuki Matsuoka, aka @t-mat, for exceptional first-class support throughout the lifetime of this project

jqlang/jq

Command-line JSON processor

jq

jq is a lightweight and flexible command-line JSON processor akin to sed,awk,grep, and friends for JSON data. It's written in portable C and has zero runtime dependencies, allowing you to easily slice, filter, map, and transform structured data.

Documentation

Official Documentation: jqlang.org
Try jq Online: play.jqlang.org

Installation

Prebuilt Binaries

Download the latest releases from the GitHub release page.

Docker Image

Pull the jq image to start quickly with Docker.

Run with Docker

Example: Extracting the version from a `package.json` file

docker run --rm -i ghcr.io/jqlang/jq:latest < package.json '.version'

Example: Extracting the version from a `package.json` file with a mounted volume

docker run --rm -i -v "$PWD:$PWD" -w "$PWD" ghcr.io/jqlang/jq:latest '.version' package.json

Building from source

Dependencies

libtool
make
automake
autoconf

Instructions

git submodule update --init    # if building from git to get oniguruma
autoreconf -i                  # if building from git
./configure --with-oniguruma=builtin
make clean                     # if upgrading from a version previously built from source
make -j8
make check
sudo make install

Build a statically linked version:

make LDFLAGS=-all-static

If you're not using the latest git version but instead building a released tarball (available on the release page), skip the autoreconf step, and flex or bison won't be needed.

Cross-Compilation

For details on cross-compilation, check out the GitHub Actions file and the cross-compilation wiki page.

Community & Support

Questions & Help: Stack Overflow (jq tag)
Chat & Community: Join us on Discord
Wiki & Advanced Topics: Explore the Wiki

License

jq is released under the MIT License. jq's documentation is licensed under the Creative Commons CC BY 3.0. jq uses parts of the open source C library "decNumber", which is distributed under ICU License

qmk/qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families

Quantum Mechanical Keyboard Firmware

This is a keyboard firmware based on the tmk_keyboard firmware with some useful features for Atmel AVR and ARM controllers, and more specifically, the OLKB product line, the ErgoDox EZ keyboard, and the Clueboard product line.

Documentation

See the official documentation on docs.qmk.fm

The docs are powered by VitePress. They are also viewable offline; see Previewing the Documentation for more details.

You can request changes by making a fork and opening a pull request.

Supported Keyboards

The project also includes community support for lots of other keyboards.

Maintainers

QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, Hasu. The OLKB product firmwares are maintained by Jack Humbert, the Ergodox EZ by ZSA Technology Labs, the Clueboard by Zach White, and the Atreus by Phil Hagelberg.

Official Website

qmk.fm is the official website of QMK, where you can find links to this page, the documentation, and the keyboards supported by QMK.

microsoft/PowerToys

Microsoft PowerToys is a collection of utilities that supercharge productivity and customization on Windows

Microsoft PowerToys

Microsoft PowerToys is a collection of utilities that help you customize Windows and streamline everyday tasks.

Installation · Documentation · Blog · Release notes

🔨 Utilities

PowerToys includes over 30 utilities to help you customize and optimize your Windows experience:


Advanced Paste	Always on Top	Awake
Color Picker	Command Not Found	Command Palette
Crop And Lock	Environment Variables	FancyZones
File Explorer Add-ons	File Locksmith	Grab And Move
Hosts File Editor	Image Resizer	Keyboard Manager
Light Switch	Mouse Utilities	Mouse Without Borders
New+	Peek	PowerDisplay
PowerRename	PowerToys Run	Quick Accent
Registry Preview	Screen Ruler	Shortcut Guide
Text Extractor	Workspaces	ZoomIt

📦 Installation

For detailed installation instructions and system requirements, visit the installation docs.

But to get started quickly, choose one of the installation methods below:

Download the .exe file from GitHub

Go to the PowerToys GitHub releases, scroll down and select Assets to reveal the installation files, and choose the one that matches your architecture and install scope. For most devices, that would be x64 per-user.

Microsoft Store

You can easily install PowerToys from the Microsoft Store:

WinGet

Download PowerToys from [WinGet](https://github.com/microsoft/winget-cli#installing-the-client). Updating PowerToys via winget will respect the current PowerToys installation scope. To install PowerToys, run the following command from the command line / PowerShell:

User scope installer (default)

winget install Microsoft.PowerToys -s winget

Machine-wide scope installer

winget install --scope machine Microsoft.PowerToys -s winget

Other methods

There are [community driven install methods](https://learn.microsoft.com/windows/powertoys/install#community-driven-install-tools) such as Chocolatey and Scoop. If these are your preferred install solutions, you can find the install instructions there.

✨ What's new?

To see what's new, check out the release notes.

🛣️ Roadmap

We are planning some nice new features and improvements for the next releases – a brand-new Shortcut Guide experience, ensuring it's easier to find and install Command Palette extensions and so much more! Stay tuned for v0.100!

❤️ PowerToys Community

The PowerToys team is extremely grateful to have the support of an amazing active community. The work you do is incredibly important. PowerToys wouldn't be nearly what it is today without your help filing bugs, updating documentation, guiding the design, or writing features. We want to say thank you and take time to recognize your work. Your contributions and feedback improve PowerToys month after month!

Contributing

This project welcomes contributions of all types. Besides coding features / bug fixes, other ways to assist include spec writing, design, documentation, and finding bugs. We are excited to work with the power user community to build a set of tools for helping you get the most out of Windows. We ask that before you start work on a feature that you would like to contribute, please read our Contributor's Guide. We would be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you grant us the rights to use your contribution and that you have permission to do so. For guidance on developing for PowerToys, please read the developer docs for a detailed breakdown. This includes how to setup your computer to compile.

Code of conduct

This project has adopted the Microsoft Open Source Code of Conduct.

Privacy statement

The application logs basic diagnostic data (telemetry). For more privacy information and what we collect, see our PowerToys Data and Privacy documentation.

memovai/mimiclaw

MimiClaw: Harness on a $5 chip. No OS(Linux). No Node.js. No Mac mini. No Raspberry Pi. No VPS. Hardware agents OS.

MimiClaw: Pocket AI Assistant on a $5 Chip

English | 中文 | 日本語

The world's first AI assistant(OpenClaw) on a $5 chip. No Linux. No Node.js. Just pure C

MimiClaw turns a tiny ESP32-S3 board into a personal AI assistant. Plug it into USB power, connect to WiFi, and talk to it through Telegram — it handles any task you throw at it and evolves over time with local memory — all on a chip the size of a thumb.

Meet MimiClaw

Tiny — No Linux, no Node.js, no bloat — just pure C
Handy — Message it from Telegram, it handles the rest
Loyal — Learns from memory, remembers across reboots
Energetic — USB power, 0.5 W, runs 24/7
Lovable — One ESP32-S3 board, $5, nothing else

How It Works

You send a message on Telegram. The ESP32-S3 picks it up over WiFi, feeds it into an agent loop — the LLM thinks, calls tools, reads memory — and sends the reply back. Supports both Anthropic (Claude) and OpenAI (GPT) as providers, switchable at runtime. Everything runs on a single $5 chip with all your data stored locally on flash.

Quick Start

What You Need

An ESP32-S3 dev board with 16 MB flash and 8 MB PSRAM (e.g. Xiaozhi AI board, ~$10)
A USB Type-C cable
A Telegram bot token — talk to @BotFather on Telegram to create one
An Anthropic API key — from console.anthropic.com, or an OpenAI API key — from platform.openai.com

Install

# You need ESP-IDF v5.5+ installed first:
# https://docs.espressif.com/projects/esp-idf/en/v5.5.2/esp32s3/get-started/

git clone https://github.com/memovai/mimiclaw.git
cd mimiclaw

idf.py set-target esp32s3

Ubuntu Install

Recommended baseline:

Ubuntu 22.04/24.04
Python >= 3.10
CMake >= 3.16
Ninja >= 1.10
Git >= 2.34
flex >= 2.6
bison >= 3.8
gperf >= 3.1
dfu-util >= 0.11
libusb-1.0-0, libffi-dev, libssl-dev

Install and build on Ubuntu:

sudo apt-get update
sudo apt-get install -y git wget flex bison gperf python3 python3-pip python3-venv \
  cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

./scripts/setup_idf_ubuntu.sh
./scripts/build_ubuntu.sh

macOS Install

Recommended baseline:

macOS 12/13/14
Xcode Command Line Tools
Homebrew
Python >= 3.10
CMake >= 3.16
Ninja >= 1.10
Git >= 2.34
flex >= 2.6
bison >= 3.8
gperf >= 3.1
dfu-util >= 0.11
libusb, libffi, openssl

Install and build on macOS:

xcode-select --install
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

./scripts/setup_idf_macos.sh
./scripts/build_macos.sh

Configure

MimiClaw uses a two-layer config system: build-time defaults in mimi_secrets.h, with runtime overrides via the serial CLI. CLI values are stored in NVS flash and take priority over build-time values.

cp main/mimi_secrets.h.example main/mimi_secrets.h

Edit main/mimi_secrets.h:

#define MIMI_SECRET_WIFI_SSID       "YourWiFiName"
#define MIMI_SECRET_WIFI_PASS       "YourWiFiPassword"
#define MIMI_SECRET_TG_TOKEN        "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
#define MIMI_SECRET_API_KEY         "sk-ant-api03-xxxxx"
#define MIMI_SECRET_MODEL_PROVIDER  "anthropic"     // "anthropic" or "openai"
#define MIMI_SECRET_SEARCH_KEY      ""              // optional: Brave Search API key
#define MIMI_SECRET_TAVILY_KEY      ""              // optional: Tavily API key (preferred)
#define MIMI_SECRET_PROXY_HOST      ""              // optional: e.g. "10.0.0.1"
#define MIMI_SECRET_PROXY_PORT      ""              // optional: e.g. "7897"

Then build and flash:

# Clean build (required after any mimi_secrets.h change)
idf.py fullclean && idf.py build

# Find your serial port
ls /dev/cu.usb*          # macOS
ls /dev/ttyACM*          # Linux

# Flash and monitor (replace PORT with your port)
# USB adapter: likely /dev/cu.usbmodem11401 (macOS) or /dev/ttyACM0 (Linux)
idf.py -p PORT flash monitor

Important: Plug into the correct USB port! Most ESP32-S3 boards have two USB-C ports. You must use the one labeled USB (native USB Serial/JTAG), not the one labeled COM (external UART bridge). Plugging into the wrong port will cause flash/monitor failures.

Show reference photo

CLI Commands (via UART/COM port)

Connect via serial to configure or debug. Config commands let you change settings without recompiling — just plug in a USB cable anywhere.

Runtime config (saved to NVS, overrides build-time defaults):

mimi> wifi_set MySSID MyPassword   # change WiFi network
mimi> set_tg_token 123456:ABC...   # change Telegram bot token
mimi> set_api_key sk-ant-api03-... # change API key (Anthropic or OpenAI)
mimi> set_model_provider openai    # switch provider (anthropic|openai)
mimi> set_model gpt-4o             # change LLM model
mimi> set_proxy 127.0.0.1 7897  # set HTTP proxy
mimi> clear_proxy                  # remove proxy
mimi> set_search_key BSA...        # set Brave Search API key
mimi> set_tavily_key tvly-...      # set Tavily API key (preferred)
mimi> config_show                  # show all config (masked)
mimi> config_reset                 # clear NVS, revert to build-time defaults

Debug & maintenance:

mimi> wifi_status              # am I connected?
mimi> memory_read              # see what the bot remembers
mimi> memory_write "content"   # write to MEMORY.md
mimi> heap_info                # how much RAM is free?
mimi> session_list             # list all chat sessions
mimi> session_clear 12345      # wipe a conversation
mimi> heartbeat_trigger           # manually trigger a heartbeat check
mimi> cron_start                  # start cron scheduler now
mimi> restart                     # reboot

USB (JTAG) vs UART: Which Port for What

Most ESP32-S3 dev boards expose two USB-C ports:

Port	Use for
USB (JTAG)	`idf.py flash`, JTAG debugging
COM (UART)	REPL CLI, serial console

REPL requires the UART (COM) port. The USB (JTAG) port does not support interactive REPL input.

Port details & recommended workflow

Port	Label	Protocol
USB	USB / JTAG	Native USB Serial/JTAG
COM	UART / COM	External UART bridge (CP2102/CH340)

The ESP-IDF console/REPL is configured to use UART by default (CONFIG_ESP_CONSOLE_UART_DEFAULT=y).

If you have both ports connected simultaneously:

USB (JTAG) handles flash/download and provides secondary serial output
UART (COM) provides the primary interactive console for the REPL
macOS: both appear as /dev/cu.usbmodem* or /dev/cu.usbserial-* — run ls /dev/cu.usb* to identify
Linux: USB (JTAG) → /dev/ttyACM0, UART → /dev/ttyUSB0

Recommended workflow:

# Flash via USB (JTAG) port
idf.py -p /dev/cu.usbmodem11401 flash

# Open REPL via UART (COM) port
idf.py -p /dev/cu.usbserial-110 monitor
# or use any serial terminal: screen, minicom, PuTTY at 115200 baud

Memory

MimiClaw stores everything as plain text files you can read and edit:

File	What it is
`SOUL.md`	The bot's personality — edit this to change how it behaves
`USER.md`	Info about you — name, preferences, language
`MEMORY.md`	Long-term memory — things the bot should always remember
`HEARTBEAT.md`	Task list the bot checks periodically and acts on autonomously
`cron.json`	Scheduled jobs — recurring or one-shot tasks created by the AI
`2026-02-05.md`	Daily notes — what happened today
`tg_12345.jsonl`	Chat history — your conversation with the bot

Tools

MimiClaw supports tool calling for both Anthropic and OpenAI — the LLM can call tools during a conversation and loop until the task is done (ReAct pattern).

Tool	Description
`web_search`	Search the web via Tavily (preferred) or Brave for current information
`get_current_time`	Fetch current date/time via HTTP and set the system clock
`cron_add`	Schedule a recurring or one-shot task (the LLM creates cron jobs on its own)
`cron_list`	List all scheduled cron jobs
`cron_remove`	Remove a cron job by ID

To enable web search, set a Tavily API key via MIMI_SECRET_TAVILY_KEY (preferred), or a Brave Search API key via MIMI_SECRET_SEARCH_KEY in mimi_secrets.h.

Cron Tasks

MimiClaw has a built-in cron scheduler that lets the AI schedule its own tasks. The LLM can create recurring jobs ("every N seconds") or one-shot jobs ("at unix timestamp") via the cron_add tool. When a job fires, its message is injected into the agent loop — so the AI wakes up, processes the task, and responds.

Jobs are persisted to SPIFFS (cron.json) and survive reboots. Example use cases: daily summaries, periodic reminders, scheduled check-ins.

Heartbeat

The heartbeat service periodically reads HEARTBEAT.md from SPIFFS and checks for actionable tasks. If uncompleted items are found (anything that isn't an empty line, a header, or a checked - [x] box), it sends a prompt to the agent loop so the AI can act on them autonomously.

This turns MimiClaw into a proactive assistant — write tasks to HEARTBEAT.md and the bot will pick them up on the next heartbeat cycle (default: every 30 minutes).

Also Included

WebSocket gateway on port 18789 — connect from your LAN with any WebSocket client
OTA updates — flash new firmware over WiFi, no USB needed
Dual-core — network I/O and AI processing run on separate CPU cores
HTTP proxy — CONNECT tunnel support for restricted networks
Multi-provider — supports both Anthropic (Claude) and OpenAI (GPT), switchable at runtime
Cron scheduler — the AI can schedule its own recurring and one-shot tasks, persisted across reboots
Heartbeat — periodically checks a task file and prompts the AI to act autonomously
Tool use — ReAct agent loop with tool calling for both providers

For Developers

Technical details live in the docs/ folder:

docs/ARCHITECTURE.md — system design, module map, task layout, memory budget, protocols, flash partitions
docs/TODO.md — feature gap tracker and roadmap
docs/WIFI_ONBOARDING_AP.md — how the local MimiClaw-XXXX onboarding/admin AP flow works
docs/tool-setup/ — configuration guides for external service integrations (Tavily, etc.)

Contributing

Please read CONTRIBUTING.md before opening issues or pull requests.

Contributors

Thanks to everyone who has contributed to MimiClaw.

License

MIT

Acknowledgments

Inspired by OpenClaw and Nanobot. MimiClaw reimplements the core AI agent architecture for embedded hardware — no Linux, no server, just a $5 chip.

Star History

asterisk/asterisk

The official Asterisk Project repository.

The Asterisk(R) Open Source PBX

By Mark Spencer <markster@digium.com> and the Asterisk.org developer community.
Copyright (C) 2001-2025 Sangoma Technologies Corporation and other copyright holders.

SECURITY

It is imperative that you read and fully understand the contents of the security information document before you attempt to configure and run an Asterisk server.

See Important Security Considerations for more information.

WHAT IS ASTERISK ?

Asterisk is an Open Source PBX and telephony toolkit. It is, in a sense, middleware between Internet and telephony channels on the bottom, and Internet and telephony applications at the top. However, Asterisk supports more telephony interfaces than just Internet telephony. Asterisk also has a vast amount of support for traditional PSTN telephony, as well.

For more information on the project itself, please visit the Asterisk Home Page and the official Asterisk Documentation.

SUPPORTED OPERATING SYSTEMS

Linux

The Asterisk Open Source PBX is developed and tested primarily on the GNU/Linux operating system, and is supported on every major GNU/Linux distribution.

Others

Asterisk has also been 'ported' and reportedly runs properly on other operating systems as well, Apple's Mac OS X, and the BSD variants.

GETTING STARTED

Most users are using VoIP/SIP exclusively these days but if you need to interface to TDM or analog services or devices, be sure you've got supported hardware.

Supported telephony hardware includes:

All Analog and Digital Interface cards from Sangoma
Any full duplex sound card supported by PortAudio
The Xorcom Astribank channel bank

UPGRADING FROM AN EARLIER VERSION

If you are updating from a previous version of Asterisk, make sure you read the Change Logs.

Change Logs

NEW INSTALLATIONS

Ensure that your system contains a compatible compiler and development libraries. Asterisk requires either the GNU Compiler Collection (GCC) version 4.1 or higher, or a compiler that supports the C99 specification and some of the gcc language extensions. In addition, your system needs to have the C library headers available, and the headers and libraries for ncurses.

There are many modules that have additional dependencies. To see what libraries are being looked for, see ./configure --help, or run make menuselect to view the dependencies for specific modules.

On many distributions, these dependencies are installed by packages with names like 'glibc-devel', 'ncurses-devel', 'openssl-devel' and 'zlib-devel' or similar. The contrib/scripts/install_prereq script can be used to install the dependencies for most Debian and Redhat based Linux distributions. The script also handles SUSE, Arch, Gentoo, FreeBSD, NetBSD and OpenBSD but those distributions mightnoit have complete support or they might be out of date.

So, let's proceed:

Read the documentation.
The Asterisk Documentation website has full information for building, installing, configuring and running Asterisk.
Run ./configure
Execute the configure script to guess values for system-dependent variables used during compilation. If the script indicates that some required components are missing, you can run ./contrib/scripts/install_prereq install to install the necessary components. Note that this will install all dependencies for every functionality of Asterisk. After running the script, you will need to rerun ./configure.
Run make menuselect
This is needed if you want to select the modules that will be compiled and to check dependencies for various optional modules.
Run make
Assuming the build completes successfully:
Run make install
If this is your first time working with Asterisk, you may wish to install the sample PBX, with demonstration extensions, etc. If so, run:
Run make samples
Doing so will overwrite any existing configuration files you have installed.
Finally, you can launch Asterisk in the foreground mode (not a daemon) with asterisk -vvvc
You'll see a bunch of verbose messages fly by your screen as Asterisk initializes (that's the "very very verbose" mode). When it's ready, if you specified the "c" then you'll get a command line console, that looks like this:
*CLI>
You can type core show help at any time to get help with the system. For help with a specific command, type core show help <command>.

man asterisk at the Unix/Linux command prompt will give you detailed information on how to start and stop Asterisk, as well as all the command line options for starting Asterisk.

ABOUT CONFIGURATION FILES

All Asterisk configuration files share a common format. Comments are delimited by ; (since # of course, being a DTMF digit, may occur in many places). A configuration file is divided into sections whose names appear in []'s. Each section typically contains statements in the form variable = value although you may see variable => value in older samples.

SPECIAL NOTE ON TIME

Those using SIP phones should be aware that Asterisk is sensitive to large jumps in time. Manually changing the system time using date(1) (or other similar commands) may cause SIP registrations and other internal processes to fail. For this reason, you should always use a time synchronization package to keep your system time accurate. All OS/distributions make one or more of the following packages available:

ntpd/ntpsec
chronyd
systemd-timesyncd

Be sure to install and configure one (and only one) of them.

FILE DESCRIPTORS

Depending on the size of your system and your configuration, Asterisk can consume a large number of file descriptors. In UNIX, file descriptors are used for more than just files on disk. File descriptors are also used for handling network communication (e.g. SIP, IAX2, or H.323 calls) and hardware access (e.g. analog and digital trunk hardware). Asterisk accesses many on-disk files for everything from configuration information to voicemail storage.

Most systems limit the number of file descriptors that Asterisk can have open at one time. This can limit the number of simultaneous calls that your system can handle. For example, if the limit is set at 1024 (a common default value) Asterisk can handle approximately 150 SIP calls simultaneously. To change the number of file descriptors follow the instructions for your system below:

PAM-BASED LINUX SYSTEM

If your system uses PAM (Pluggable Authentication Modules) edit /etc/security/limits.conf. Add these lines to the bottom of the file:

root            soft    nofile          4096
root            hard    nofile          8196
asterisk        soft    nofile          4096
asterisk        hard    nofile          8196

(adjust the numbers to taste). You may need to reboot the system for these changes to take effect.

GENERIC UNIX SYSTEM

If there are no instructions specifically adapted to your system above you can try adding the command ulimit -n 8192 to the script that starts Asterisk.

MORE INFORMATION

Visit the Asterisk Documentation website for more documentation on various features and please read all the configuration samples that include documentation on the configuration options.

Finally, you may wish to join the Asterisk Community Forums

Welcome to the growing worldwide community of Asterisk users!

        Mark Spencer, and the Asterisk.org development community

Asterisk is a trademark of Sangoma Technologies Corporation

[Sangoma] [Home Page] [Support] [Documentation] [Community Forums] [Release Notes] [Security] [Mailing List Archive]

HermannBjorgvin/Clawdmeter

ESP32 desk dashboard that shows Claude Code usage

Clawdmeter

A small ESP32 dashboard I made for my desk to keep an eye on Claude Code usage.

It runs on a Waveshare ESP32-S3-Touch-AMOLED-2.16 as well as a few other alternative boards and pairs over Bluetooth, the splash screen plays pixel-art Clawd animations that get busier when your usage rate climbs. The two side buttons send Space and Shift+Tab over BLE HID for Claude Code's voice mode and mode-toggle shortcuts.

Screens

The device boots into the splash. Tap the screen anywhere to switch to the Usage view; tap again to flip back to the splash.

Splash	Usage

Splash; touch-toggle anytime	Session and weekly utilization

While the splash is up, the middle (PWR) button cycles animations. Hold the power button for 3 seconds, then release, to put the device into pairing mode — this clears the saved Bluetooth bond and re-advertises. The firmware also auto-rotates animations every 20 s within the current usage-rate group, so a long stretch on the splash isn't just one Clawd on loop.

Hardware

Boards supported out of the box:

Please check if a pull request exists for your alternative hardware port before opening a new one, providing QA feedback and testing on the same hardware is more valuable than duplicate pull requests.

Porting to another board: the firmware is a thin HAL with per-board folders under firmware/src/boards/. Drop in a new folder and a new PlatformIO env — main.cpp, ui.cpp, and splash.cpp never need to change. See docs/porting/adding-a-board.md for the walk-through and docs/porting/hal-contract.md for the interfaces a port must implement.

Prerequisites

Linux (tested on Ubuntu), macOS, or Windows 10/11
PlatformIO CLI
Linux: curl, bluetoothctl, busctl (BlueZ Bluetooth stack)
macOS: python3 (the installer sets up a venv with bleak and httpx)
Windows: python3 3.11+ (the installer sets up a venv with bleak, httpx, and pystray)
Claude Code with an active subscription

macOS installation

The macOS host pieces — Python daemon, LaunchAgent, and flash helper — were ported by Chris Davidson (@lorddavidson). Thanks Chris!

Flash the firmware

./flash-mac.sh waveshare_amoled_216                       # auto-detects /dev/cu.usbmodem*
./flash-mac.sh waveshare_amoled_18  /dev/cu.usbmodem1101  # or pass an explicit USB serial port

The board env name is required. Run ./flash-mac.sh with no args to see the available envs (scraped from firmware/platformio.ini).

Pair the device

After flashing, open System Settings → Bluetooth and click Connect next to "Clawdmeter". The daemon only ever connects to the peripheral this Mac is paired/connected to — it never scans for a nearby device — so once it's connected here the daemon picks it up on its next poll (~60 s).

Install the daemon

The daemon reads your Claude OAuth token from the macOS Keychain (service Claude Code-credentials), polls usage every 60 s, and pushes it to the display over BLE.

./install-mac.sh

The installer creates a Python venv in daemon/.venv/, installs bleak and httpx, renders a LaunchAgent into ~/Library/LaunchAgents/com.user.claude-usage-daemon.plist, and loads it. The first run is launched interactively so macOS prompts for Bluetooth permission.

Useful commands:

launchctl list | grep claude-usage                                          # check it's running
tail -F ~/Library/Logs/claude-usage-daemon.out.log                          # live logs
launchctl unload ~/Library/LaunchAgents/com.user.claude-usage-daemon.plist  # stop
launchctl load -w ~/Library/LaunchAgents/com.user.claude-usage-daemon.plist # start

Linux installation

Flash the firmware

./flash.sh waveshare_amoled_216                  # defaults to /dev/ttyACM0
./flash.sh waveshare_amoled_18  /dev/ttyACM1     # or pass an explicit USB serial port

The board env name is required. Run ./flash.sh with no args to see the available envs (scraped from firmware/platformio.ini).

Pair the device

After flashing, the device advertises as "Clawdmeter". Pair it once:

# Scan for the device
bluetoothctl scan le

# When "Clawdmeter" appears, pair and trust it
bluetoothctl pair F4:12:FA:C0:8F:E5    # use your device's MAC
bluetoothctl trust F4:12:FA:C0:8F:E5

To re-pair later, hold the power button for 3 seconds then release — the device clears its saved bond and re-advertises.

Install the daemon

The daemon polls your Claude usage every 60 seconds and sends it to the display over BLE.

./install.sh
systemctl --user start claude-usage-daemon

Check status: systemctl --user status claude-usage-daemon

View logs: journalctl --user -u claude-usage-daemon -f

Windows installation

Runs natively on Windows — no WSL required. A system-tray app polls your usage and pushes it over BLE, and starts automatically at login.

Prerequisites

Native Windows (not WSL).
Python 3.11+ from python.org — check "Add python.exe to PATH" during install.
Claude Code installed, with claude login completed. The token is read from %USERPROFILE%\.claude\.credentials.json (falling back to %LOCALAPPDATA%\Claude\ then %APPDATA%\Claude\).
The repo on a native Windows path (e.g. %USERPROFILE%\Clawdmeter), not a \\wsl$ share — the installer refuses a WSL path.

Flash the firmware

pio run -d firmware -e waveshare_amoled_216 -t upload --upload-port COM5   # use your device's COM port

Run pio run -d firmware with no env to see the available board envs.

Pair the device

The device is a bonded BLE HID keyboard, so pair it once: Settings → Bluetooth & devices → Add device → Bluetooth, then select "Clawdmeter". Pairing is required — it enables the physical buttons and keeps a persistent connection (the device keeps showing your last-synced usage even after the daemon quits). To undo, use Remove device (this disables the buttons).

Install the daemon (recommended)

From the repo root in PowerShell:

powershell -ExecutionPolicy Bypass -File install-windows.ps1

This creates a venv, installs bleak/httpx/pystray/Pillow from the in-repo requirements (no internet downloads), registers a per-user login-autostart entry (HKCU\…\Run, no admin needed), and launches the tray app headlessly (no console window).

Run manually instead (optional)

python -m venv .venv
.venv\Scripts\Activate.ps1        # if blocked: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned, then retry
pip install -r daemon\requirements-windows.txt
python daemon\claude_usage_daemon_windows.py        # runs in the foreground; Ctrl+C to stop

Tray icon and menu

The icon's corner bubble shows state — green Connected, amber Scanning, red Error — and hovering shows the status (Connected · last update HH:MM). A notification fires once when it enters Error (e.g. an expired token). Right-click for the menu:

Status header — live state + last sync time.
Start at login — toggle autostart on/off.
Quit — stops the daemon cleanly; leaves the Windows pairing intact (device keeps its last reading).

Logs and troubleshooting

Get-Content $env:LOCALAPPDATA\Clawdmeter\daemon.log -Tail 30        # view logs
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v Clawdmeter /f   # remove autostart

Symptom	Fix
`Device not found`	Power on the device; make sure it's in range and paired.
`token expired` toast / `API HTTP 401`	Re-run `claude login`, then restart the daemon.
`Connection failed`	Toggle Windows Bluetooth off/on in Settings.
`Warning: running under Linux/WSL`	Run from a native PowerShell window, not a WSL shell.

How it works

The daemon reads your Claude Code OAuth token — from the macOS Keychain (service Claude Code-credentials) on macOS, or from ~/.claude/.credentials.json on Linux (%USERPROFILE%\.claude\.credentials.json on Windows).
It makes a minimal API call to api.anthropic.com/v1/messages — one token of Haiku, basically free.
The usage numbers come straight out of the response headers (anthropic-ratelimit-unified-5h-utilization and friends).
The daemon connects to the ESP32 over BLE and writes a JSON payload to the GATT RX characteristic.
The firmware parses it and updates the LVGL dashboard.
The firmware also tracks the rate of change of session % over a 5-minute window and picks splash animations from the matching mood group.
The two side buttons are independent of all of this — they send Space and Shift+Tab as BLE HID keyboard input to the paired host directly.

Physical buttons

The board has three side buttons. Left and right send HID keys; the middle (PWR) button cycles splash animations and, held for 3 seconds, triggers pairing mode.

Button	GPIO	Function
Left	GPIO 0	Hold to send Space (Claude Code voice-mode push-to-talk)
Middle (PWR)	AXP2101 PKEY	On splash: cycle animations. Hold 3s + release: pairing mode
Right	GPIO 18	Press to send Shift+Tab (Claude Code mode toggle)

Space and Shift+Tab go out as standard BLE HID keyboard reports, so they trigger in whatever window has focus on the paired host — not just Claude Code.

BLE protocol

The device advertises a custom GATT service alongside the standard HID keyboard service:

	UUID
Data Service	`4c41555a-4465-7669-6365-000000000001`
RX Characteristic (write)	`4c41555a-4465-7669-6365-000000000002`
TX Characteristic (notify)	`4c41555a-4465-7669-6365-000000000003`
HID Service	`00001812-0000-1000-8000-00805f9b34fb`

JSON payload format (written to RX):

{ "s": 45, "sr": 120, "w": 28, "wr": 7200, "st": "allowed", "ok": true }

Fields: s = session %, sr = session reset (minutes), w = weekly %, wr = weekly reset (minutes), st = status, ok = success flag.

Development

Desktop simulator — iterate on the UI without hardware: an SDL2 window runs the full firmware loop with scenario playback (pio run -d firmware -e sim, then cd firmware && .pio/build/sim/program). See SIM-USAGE.md for controls, scenarios, and headless screenshots.
Splash animations — Anthropic's official Clawd sprites, archived with provenance notes in research/clawd-official/; node tools/convert_official_clawd.js regenerates firmware/src/splash_animations.h. See tools/README.md.
Icons — Lucide PNGs convert to LVGL C arrays with tools/png_to_lvgl.js. See tools/README.md.
Fonts — the pre-compiled LVGL fonts and the LVGL-9 patching they need: docs/fonts.md.
Porting — docs/porting/adding-a-board.md and docs/porting/hal-contract.md.

Credits

Pixel-art Clawd animations are Anthropic's official mascot art (claude.ai/code, Claude Code desktop), archived and converted by the tooling in tools/ and research/clawd-official/.
Lucide icon set (lucide.dev, MIT) for bluetooth and battery UI glyphs.
Anthropic brand fonts (Tiempos Text, Styrene B) — see licensing warning below.

Licensing gray area warning

The software in this repository uses and adheres to the Anthropic brand guidelines and uses the same proprietary fonts that Anthropic has a license for but this software uses without permission as well as using assets from Anthropic such as the copyrighted Clawd mascot so even though the code in this repo is non-proprietary I will not license it myself under a copyleft license since this repo includes proprietary fonts and copyrighted assets. Please be aware of this if you fork or copy the code from this repo. You have been warned!

RfidResearchGroup/proxmark3

Iceman Fork - Proxmark3

The Proxmark3 is the swiss-army tool of RFID, allowing for interactions with the vast majority of RFID tags on a global scale. Originally built by Jonathan Westhues, the device is now the goto tool for RFID Analysis for the enthusiast. Iceman repository is considered to be the pinnacle of features and functionality, enabling a huge range of extremely useful and convenient commands and LUA scripts to automate chip identification, penetration testing, and programming

Latest Release	Coverity	Contributors

Actions OSX CI	Actions Ubuntu CI	Actions Windows CI

PROXMARK3 INSTALLATION AND OVERVIEW

Installation	Use of the Proxmark3
Linux - Setup and Build	Compilation Instructions
Linux - Important notes on ModemManager	Validating Proxmark3 Client Functionality
macOS - Homebrew & Upgrading HomeBrew Tap Formula	First Use and Verification
macOS - MacPorts	Commands & Features
macOS - Setup and Build	Standalone Modes
Windows - Setup and Build
Termux / Android - Setup and Build
iOS - Setup and Build
Blue Shark Manual	Command Cheat Sheet
Advanced Compilation Parameters	More Cheat Sheets
Troubleshooting	Complete Client Command Set
JTAG	T5577 Introduction Guide

Notes / helpful documents

Notes
Notes on UART	Notes on Termux / Android	Notes on paths
Notes on frame format	Notes on tracelog / wireshark	Notes on EMV
Notes on external flash	Notes on loclass	Notes on Coverity Scan Config & Run
Notes on file formats used with Proxmark3	Notes on MFU binary format	Notes on FPGA & ARM
Developing standalone mode	Wiki about standalone mode	Notes on Magic UID cards
Notes on Color usage	Makefile vs CMake	Notes on Cloner guns
Notes on cliparser usage	Notes on clocks	Notes on MIFARE DESFire
Notes on CIPURSE	Notes on NDEF type4a	Unofficial MIFARE DESFire bible

How to build?

Proxmark3 RDV4

See the instruction links in the tables above to build, flash and run for your Proxmark3 RDV4 device.

Generic Proxmark3 platforms

In order to build this repo for generic Proxmark3 platforms we urge you to read Advanced compilation parameters

We define generic Proxmark3 platforms as following devices.

Supported

RDV1, RDV2, RDV3 easy
Ryscorp green PCB version
Radiowar black PCB version
numerous Chinese adapted versions of the RDV3 easy (kkmoon, PiSwords etc)
Proxmark3 SE (Special Edition) (BLE enabled)
Proxmark3 X
- Note: Community tested
- Note: unknown device hw

Not supported

⚠ Proxmark Evolution (EVO)
- Note: unknown pin assignments.
⚠ Ryscorp Proxmark3 Pro
- Note: device has different fpga and unknown pin assignments.
- Note: Company have disappeared, leaving their customers in the dark.

Experimental support

⚠ iCopy-X
- Note: currently incompatible with iCopy-X GUI as Proxmark client commands using different syntax
- Note: see also icopyx-community repos for upstream sources, reversed hw etc.
- Note: Uses DRM to lock down tags, ignores the open source licences. Use on your own risk.
⚠ Proxmark3 Ultimate
- Note: unknown device hw
- Note: FPGA images is building for it. Use on your own risk.

Unknown support status

⚠ VX
- Note: unknown device hw

When it comes to these new unknown models we are depending on the community to report in if this repo works and what they did to make it work.

256KB flash memory size of generic Proxmark3 platforms

⚠ Note: You need to keep a eye on how large your ARM chip built-in flash memory is. With 512KB you are fine but if its 256KB you need to compile this repo with even less functionality. When running the ./pm3-flash-all you can see which size your device have if you have the bootloader from this repo installed. Otherwise you will find the size reported in the start message when running the Proxmark3 client ./pm3.

OBS! Read the 256KB flash memory advisory

What has changed?

Proxmark3 RDV4 hardware modifications:

added flash memory 256KB
added smart card module
added FPC connector for peripherals such as Bluetooth+battery addon
improved antennas
- swappable
- LF Q factor switch
- LF 125/134 frequency switch
tiny PCB form factor
ABS case

This repo vs official Proxmark3 repo:

See the Changelog file which we try to keep updated.

In short this repo gives you a completely different user experience when it comes to Proxmark3.

Supports command tab complete
Richer CLI with use of colors / emojis
Help text system implemented everywhere
Hints system
User preference settings
Extensive testing with continuous integration build systems on Linux, OSX and Windows, and regular usage of static analysis tools like
- Coverity Scan
- Cppcheck (v2.6)
- GCC and Clang aggressive enforcement of diagnostic flags
Auto detection of serial ports and seamless integration with Bluetooth addon
Reconnect to device from inside client
Supports tearoff attacks
Supports NFC NDEF type1, type2, type4a, type4b, mifare, barcode
Supports pm3 client scripts, lua scripts, python scripts
Most comprehensive collection of scripts available
Wiegand encoding, decoding.
Supports EMV
Supports CIPURSE
Most standalone modes available with easy compilation
Extensive test script for client and external tools
Most comprehensive compiled known keys dictionaries
Slimed down usb communications with NG-frames
The most compiled public known key recovery software
The fastest implementations of said software
Support multiple fileformats for dump files (BIN/EML/JSON)
Interoperability of said fileformats with libnfc, MFC tool app etc
Supports more RFID based protocols than ever
Easy install for package maintainers, distro maintainers
Supports cmake, make
Builds without errors or warnings on more OS/platforms than ever
Available as package on known distros like Gentoo, Kali, Termux, Macports, Homebrew
Much more documentation

Development

⚠ Note: This is a bleeding edge repository. The maintainers actively is working out of this repository and will be periodically re-structuring the code to make it easier to comprehend, navigate, build, test, and contribute to, so DO expect significant changes to code layout on a regular basis.

👉 Remember! If you intend to contribute to the code, please read the coding style notes first. We usually merge your contributions fast since we do like the idea of getting a functionality in the Proxmark3 and weed out the bugs afterwards.

The public roadmap is an excellent start to read if you are interesting in contributing.

Supported operating systems

This repo compiles nicely on

WSL1 on Windows 10
WSL2 on Windows 10/11
Proxspace environment release v3.xx
Windows/MinGW environment
Ubuntu, ParrotOS, Gentoo, Pentoo, Kali, NetHunter, Arch Linux, Fedora, Debian, Raspbian
Android / Termux
macOS / Homebrew (or MacPorts, experimental) / Apple Silicon M1
iOS (Jailbroken, rootful)
Docker container
- Iceman repo based ubuntu 18.04 container
- Iceman fork based container v1.7

Precompiled binaries

See Proxmark3 precompiled builds

Proxmark3 GUI

The official PM3-GUI from Gaucho will not work. Not to mention is quite old and not maintained any longer.

Proxmark3 Universal GUI will work more or less.
Proxmark3 GUI cross-compiled which is recently updated and claims to support latest source of this repo.
Proxmark3_GUI simple gui in vb.net

Official channels

Where do you find the community?

Maintainers

To all distro, package maintainers, we tried to make your life easier.

make install is now available and if you want to know more.

This document will be helpful for you

Notes for maintainers

Citation

Use this bibtex to cite this repository globally:

@misc{proxmark3,
  author = {C. {Herrmann} and P. {Teuwen} and O. {Moiseenko} and M. {Walker} and others},
  title = {{Proxmark3 -- Iceman repo}},
  howpublished = {\url{https://github.com/RfidResearchGroup/proxmark3}},
  keywords = {rfid nfc iceman proxmark3 125khz 134khz 13.56mhz},
}

If you need to refer to a specific state of the repository, use a commit number or a date of access, e.g.:

  note = {Accessed: commit 12327f71a27da23831901847886aaf20e8ad3ca0}
  note = {Accessed: 2021-01-01}

Copyright and licensing terms

Each contribution is under the copyright of its author. See AUTHORS.

The Proxmark3 source code is covered by the following licensing terms, usually referred as GPLv3 or later.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

A copy of the GPLv3 is available in LICENSE.

Some dependencies may be under other free licensing terms compatible with the Proxmark3 licensing terms, see their respective description.

facebook/zstd

Zstandard - Fast real-time compression algorithm

Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. It's backed by a very fast entropy stage, provided by Huff0 and FSE library.

Zstandard's format is stable and documented in RFC8878. Multiple independent implementations are already available. This repository represents the reference implementation, provided as an open-source dual BSD OR GPLv2 licensed C library, and a command line utility producing and decoding .zst, .gz, .xz and .lz4 files. Should your project require another programming language, a list of known ports and bindings is provided on Zstandard homepage.

Development branch status:

Benchmarks

For reference, several fast compression algorithms were tested and compared on a desktop featuring a Core i7-9700K CPU @ 4.9GHz and running Ubuntu 24.04 (Linux 6.8.0-53-generic), using lzbench, an open-source in-memory benchmark by @inikep compiled with gcc 14.2.0, on the Silesia compression corpus.

Compressor name	Ratio	Compression	Decompress.
zstd 1.5.7 -1	2.896	510 MB/s	1550 MB/s
brotli 1.1.0 -1	2.883	290 MB/s	425 MB/s
zlib 1.3.1 -1	2.743	105 MB/s	390 MB/s
zstd 1.5.7 --fast=1	2.439	545 MB/s	1850 MB/s
quicklz 1.5.0 -1	2.238	520 MB/s	750 MB/s
zstd 1.5.7 --fast=4	2.146	665 MB/s	2050 MB/s
lzo1x 2.10 -1	2.106	650 MB/s	780 MB/s
lz4 1.10.0	2.101	675 MB/s	3850 MB/s
snappy 1.2.1	2.089	520 MB/s	1500 MB/s
lzf 3.6 -1	2.077	410 MB/s	820 MB/s

The negative compression levels, specified with --fast=#, offer faster compression and decompression speed at the cost of compression ratio.

Zstd can also offer stronger compression ratios at the cost of compression speed. Speed vs Compression trade-off is configurable by small increments. Decompression speed is preserved and remains roughly the same at all settings, a property shared by most LZ compression algorithms, such as zlib or lzma.

The following tests were run on a server running Linux Debian (Linux version 4.14.0-3-amd64) with a Core i7-6700K CPU @ 4.0GHz, using lzbench, an open-source in-memory benchmark by @inikep compiled with gcc 7.3.0, on the Silesia compression corpus.

Compression Speed vs Ratio	Decompression Speed

A few other algorithms can produce higher compression ratios at slower speeds, falling outside of the graph. For a larger picture including slow modes, click on this link.

The case for Small Data compression

Previous charts provide results applicable to typical file and stream scenarios (several MB). Small data comes with different perspectives.

The smaller the amount of data to compress, the more difficult it is to compress. This problem is common to all compression algorithms, and reason is, compression algorithms learn from past data how to compress future data. But at the beginning of a new data set, there is no "past" to build upon.

To solve this situation, Zstd offers a training mode, which can be used to tune the algorithm for a selected type of data. Training Zstandard is achieved by providing it with a few samples (one file per sample). The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression. Using this dictionary, the compression ratio achievable on small data improves dramatically.

The following example uses the github-users sample set, created from github public API. It consists of roughly 10K records weighing about 1KB each.

Compression Ratio	Compression Speed	Decompression Speed

These compression gains are achieved while simultaneously providing faster compression and decompression speeds.

Training works if there is some correlation in a family of small data samples. The more data-specific a dictionary is, the more efficient it is (there is no universal dictionary). Hence, deploying one dictionary per type of data will provide the greatest benefits. Dictionary gains are mostly effective in the first few KB. Then, the compression algorithm will gradually use previously decoded content to better compress the rest of the file.

Dictionary compression How To:

Create the dictionary

zstd --train FullPathToTrainingSet/* -o dictionaryName
Compress with dictionary

zstd -D dictionaryName FILE
Decompress with dictionary

zstd -D dictionaryName --decompress FILE.zst

Build instructions

make is the main build system of this project. It is the reference, and other build systems are periodically updated to stay compatible. However, small drifts and feature differences can be present, since perfect synchronization is difficult. For this reason, when your build system allows it, prefer employing make.

Makefile

Assuming your system supports standard make (or gmake), just invoking make in root directory generates zstd cli at root, and also generates libzstd into lib/.

Other standard targets include:

make install : install zstd cli, library and man pages
make check : run zstd, test its essential behavior on local platform

The Makefile follows the GNU Standard Makefile conventions, allowing staged install, standard compilation flags, directory variables and command variables.

For advanced use cases, specialized flags which control binary generation and installation paths are documented in lib/README.md for the libzstd library and in programs/README.md for the zstd CLI.

cmake

A cmake project generator is available for generating Makefiles or other build scripts to create the zstd binary as well as libzstd dynamic and static libraries. The repository root now contains a minimal CMakeLists.txt that forwards to build/cmake, so you can configure the project with a standard cmake -S . invocation, while the historical cmake -S build/cmake entry point remains fully supported.

cmake -S . -B build-cmake
cmake --build build-cmake

By default, CMAKE_BUILD_TYPE is set to Release.

Support for Fat (Universal2) Output

zstd can be built and installed with support for both Apple Silicon (M1/M2) as well as Intel by using CMake's Universal2 support. To perform a Fat/Universal2 build and install use the following commands:

cmake -S . -B build-cmake-debug -G Ninja -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h;arm64"
cd build-cmake-debug
ninja
sudo ninja install

Meson

A Meson project is provided within build/meson. Follow build instructions in that directory.

You can also take a look at .travis.yml file for an example about how Meson is used to build this project.

Note that default build type is release.

VCPKG

You can build and install zstd vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install zstd

The zstd port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Conan

You can install pre-built binaries for zstd or build it from source using Conan. Use the following command:

conan install --requires="zstd/[*]" --build=missing

The zstd Conan recipe is kept up to date by Conan maintainers and community contributors. If the version is out of date, please create an issue or pull request on the ConanCenterIndex repository.

Visual Studio (Windows)

Going into build directory, you will find additional possibilities:

Projects for Visual Studio 2008 and 2010.
- VS2010 project is compatible with VS2012, VS2013, VS2015 and VS2017.
Automated build scripts for Visual compiler by @KrzysFR, in build/VS_scripts, which will build zstd cli and libzstd library without any need to open Visual Studio solution.
It is now recommended to generate Visual Studio solutions from cmake

Buck

You can build the zstd binary via buck by executing: buck build programs:zstd from the root of the repo. The output binary will be in buck-out/gen/programs/.

Bazel

You can integrate zstd into your Bazel project by using the module hosted on the Bazel Central Repository.

Testing

You can run quick local smoke tests by running make check. If you can't use make, execute the playTest.sh script from the src/tests directory. Two env variables $ZSTD_BIN and $DATAGEN_BIN are needed for the test script to locate the zstd and datagen binary. For information on CI testing, please refer to TESTING.md.

Status

Zstandard is deployed within Meta and many other large cloud infrastructures, to compress humongous amounts of data in various formats and use cases. It is also continuously fuzzed for security issues by Google's oss-fuzz program.

License

Zstandard is dual-licensed under BSD OR GPLv2.

Contributing

The dev branch is the one where all contributions are merged before reaching release. Direct commit to release are not permitted. For more information, please read CONTRIBUTING.

darktable-org/darktable

darktable is an open source photography workflow application and raw developer

darktable

darktable is an open source photography workflow application and non-destructive raw developer - a virtual lighttable and darkroom for photographers. It manages your digital negatives in a database, lets you view them through a zoomable lighttable and enables you to develop raw images, enhance them and export them to local or remote storage.

darktable is not a free Adobe® Lightroom® replacement.

https://www.darktable.org/

Documentation

The darktable user manual is maintained in the dtdocs repository.

Lua API documentation is maintained in the luadocs repository.

Website

The website (https://www.darktable.org/) is maintained in the dtorg repository.

Requirements

Supported platforms

Linux
FreeBSD
NetBSD
OpenBSD
Windows 10 and later
Apple Silicon Macs running macOS 14 and later
Intel Macs running macOS 15 and later

Big-endian platforms are not supported.

32-bit platforms are not officially supported - they might or might not work.

Both darktable and the libraries it uses are developed on the Linux platform. Therefore, other platforms MAY have additional bugs that are not present in the Linux version. In addition, for example, on the Windows platform, printing support is not currently implemented. So we recommend, if you have a choice of platform, to use darktable on Linux.

Hardware

(workable minimum / recommended minimum):

RAM: 4 GB / 8 GB
CPU: Intel Pentium 4 (Core 2 for Windows) / Intel Core i5 4×2.4 GHz
GPU: none / Nvidia with 1024 CUDA cores, 4 GB, OpenCL 1.2 compatible
free disk space: 250 MB / 1 GB

darktable can run on lightweight configurations (even on a Raspberry Pi), but expect modules like denoise, local contrast, contrast equalizer, retouch or liquify to be slow beyond usable.

A GPU is not mandatory but is strongly recommended for a smoother experience. Nvidia GPUs are recommended for safety because some AMD drivers behave unreliably with some modules (e.g. local contrast).

AI features (optional)

Darktable includes optional AI-powered features such as object masks, denoise and upscale. These require building with -DUSE_AI=ON (off by default), or --enable-ai when building with the build helper script build.sh. AI features are disabled by default in preferences and must be enabled by the user. Models are downloaded from the AI tab in preferences (default repository: darktable-org/darktable-ai).

CPU inference is bundled and works out of the box - no additional software is needed. On macOS (Apple Silicon), CoreML acceleration and on Windows, DirectML GPU acceleration are also bundled by default. Processing on CPU is slower than GPU but requires no special hardware.

GPU acceleration significantly speeds up AI inference but requires installing a GPU-enabled build of ONNX Runtime separately:

NVIDIA (CUDA): Linux and Windows.
- Supported NVIDIA GPU with up-to-date drivers (Maxwell or newer)
- CUDA Toolkit 12 or CUDA Toolkit 13
- cuDNN 9.x
AMD (ROCm): Linux only.
- Supported AMD GPU with up-to-date drivers (RDNA2/CDNA or newer), see compatibility matrix
- ROCm 6+
- MIGraphX (may require separate install, e.g. apt install migraphx migraphx-dev on Ubuntu)
Intel (OpenVINO): Linux and Windows.
- Supported Intel GPU with up-to-date drivers (integrated Gen9+, discrete Arc, or NPU Meteor Lake+)
- Intel OpenCL or/and Level Zero runtime (included with drivers on Windows; on Linux may need intel-opencl-icd or level-zero)
- On Windows, requires OpenVINO Toolkit installation
Windows (DirectML): bundled, works with any DirectX 12 compatible GPU (NVIDIA, AMD, Intel). No extra install needed.
- Windows 10 1903+ (DirectML is a system component)
macOS (CoreML): bundled, uses Apple Neural Engine automatically. No extra install needed.
- macOS 11+ (Big Sur)
- Apple Silicon (M1+)

GPU memory: 4 GB VRAM minimum. If GPU inference fails (out of memory, unsupported op, EP crash), darktable automatically retries on CPU and continues.

AMD first-run latency: on AMD GPUs the first inference per model is significantly slower because ROCm/MIGraphX compiles the model graph on the fly. The compiled graph is cached, so subsequent runs of the same model are fast.

To enable GPU acceleration, run one of the install scripts:

Linux:

curl -fsSL https://raw.githubusercontent.com/darktable-org/darktable/HEAD/tools/ai/install-ort-gpu.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/darktable-org/darktable/HEAD/tools/ai/install-ort-gpu.ps1 | iex

Then point darktable at the installed library via the AI tab in preferences (click detect). See tools/ai/README.md for flags, prerequisites, manual install, and troubleshooting. Verify the active provider with darktable -d ai.

Installing

If the latest release is still not available as a pre-built package for your distribution, you can build the software yourself following the instructions below.

Latest release

5.6.0 (stable)

When using a pre-built package, ensure that it has been built with Lua, OpenCL, OpenMP and Colord support. These are optional and will not prevent darktable from running if missing, but their absence will degrade the user experience. You can check for them by running darktable with the --version command line option.

Development snapshot

The development snapshot reflects the current state of the master branch. It is intended for testing and is generally not safe. See the notes below for warnings and precautions about using the master branch.

Updating from older versions

When updating darktable from an older release, you only need to install the newest version. Existing files will be preserved.

However, newer releases occasionally need to change the structure of the library database (containing the whole list of images known to darktable, with their editing history). If this happens you will be prompted with a request to either upgrade the database or close the software.

Migration to a newer database structure/newer release means that your edits (both new and old) will no longer be compatible with older versions of darktable. Upgrades are definitive. Newer versions are always compatible with older edits, but newer edits are generally not compatible with older versions.

darktable automatically backs up the library database when a new version causes it to be upgraded (in ~/.config/darktable/library.db-pre-3.0.0 for example), so you can revert to the previous release by restoring this backup if needed (simply rename it to library.db).

You will not be able to open the newer version of the database with a version of darktable that only supports the older version of the database. This is impossible because the older application does not know how the database schema has changed, so its code will not be able to work with it.

You will be able to import images with an XMP sidecar file that contains newer versions of processing modules or new modules, but those image editing parts will be discarded and you will lose them.

If you plan to move regularly between two versions (new/unstable and old/stable) see below for details of how to do it safely.

Obtaining extensions

Extensions and plugins use the Lua scripting language and can be downloaded here. Lua support is optional in darktable, so make sure you have the lua interpreter and its development files (package lua-dev or lua-devel, depending on distributions) installed on your system while building or ensure the package you are using has been built with this library.

Extensions allow exporting for various media and websites, merge/stack/blend HDR, panoramas or focus bracketing, apply AI-based facial recognition, manage tags and GPS data, etc.

Building

Dependencies

Compatible compilers/toolchains:

Clang: 15 and later
GCC: 12 and later
MinGW-w64: 10 and later
XCode: 15.2 and later

Required dependencies (minimum version):

CMake 3.18
GTK 3.24.15
GLib 2.56
SQLite 3.26
libcurl 7.56
libpng 1.5.0 (for PNG import & export, also for reading LUT files in PNG format)
Exiv2 0.27.2 (but at least 0.27.4 built with ISO BMFF support needed for Canon CR3 raw import)
potrace 1.16
pugixml 1.8

Required dependencies (no version requirement):

Lensfun (for automatic lens correction) (Note: alpha 0.3.95 and git master branch are not supported)
libjpeg (both the original IJG library and API-compatible ones, such as libjpeg-turbo, will work)
LibTIFF (for TIFF import & export)
Little CMS 2

Optional dependencies (minimum version):

OpenMP 4.5 (for CPU multi-threading and SIMD vectorization)
LLVM 7 (for OpenCL checks at compilation time)
OpenCL 1.2 (for GPU-accelerated computing)
Lua 5.4 (for plugins and extension scripting)
G'MIC 2.7.0 (for .gmz compressed LUT files support)
libgphoto2 2.5 (for camera tethering)
Imath 3.1.0 (for 16-bit "half" float TIFF export and faster import)
libavif 0.9.3 (for AVIF import & export)
ONNX Runtime 1.18 (for AI inference)
libarchive 3.8.5 (for AI models download)
libheif 1.13.0 (for HEIF import & export; also for AVIF import if no libavif)
libjxl 0.7.0 (for JPEG XL import & export)
WebP 0.3.0 (for WebP import & export)

Optional dependencies (no version requirement):

colord, Xatom (for fetching the system display color profile)
PortMidi (for MIDI input support)
SDL2 (for gamepad input support)
CUPS (for print mode support)
OpenEXR (for EXR import & export)
OpenJPEG (for JPEG 2000 import & export)
GraphicsMagick or ImageMagick (for misc image format import)

To install all the dependencies on Linux systems, you may use the source repository of your distribution. This will install the same packages that were used to build the official darktable package on your system. Most likely, you will want to build a newer version than the one packaged in the distribution. So please note that although this does not happen very often, it is possible that a new version of darktable will have a new (required or optional) dependency. So the commands below only simplify the creation of your build environment, but will not replace your attention to the build process and possibly finding and installing certain additional dependency packages.

Fedora and RHEL/CentOS

sudo dnf builddep darktable

OpenSuse

sudo zypper si -d darktable

Ubuntu

Recent Ubuntu releases do not include the deb-src sources out of the box, even in commented form. To add them, you need to run "Software & Updates" and on the first tab that opens, "Ubuntu Software", check the "Source code" checkbox. Only after that you can use the following command:

sudo apt-get build-dep darktable

Debian

sudo apt-get build-dep darktable

Get the source

Master branch (unstable)

The master branch contains the latest version of the source code and is intended:

as a working base for developers,
for beta-testers to chase bugs,
for users willing to sacrifice stability for new features without waiting for the next release.

The master branch comes with no guarantee of stability and might corrupt your database and XMP files, result in loss of data and edit history or temporarily break compatibility with previous versions and commits.

How dangerous is it? Most of the time, it is fairly stable. As with any rolling-release kind of deployment, bugs appear more often but are fixed faster too. Sometimes, though, these bugs can result in losses or inconsistencies in the editing history of your pictures. This is fine if you don't need to open your edits again in the future, but maybe not if you manage an estate.

After backing up your ~/.config/darktable directory and the sidecar .XMP files of any pictures you intend to open with the master branch, you may obtain the source as follows:

git clone --recurse-submodules https://github.com/darktable-org/darktable.git
cd darktable

See below (in "Using") how to start a test install of the unstable version without damaging your regular stable install and files.

Latest stable release

5.6.0

The darktable project releases two major versions every year, on Summer and Winter Solstices, tagged with even numbers (e.g. 4.2, 4.4, 4.6, 4.8). Minor revisions are tagged with a third digit (e.g. 4.4.1, 4.4.2) and mostly provide bug fixes and camera support. You may want to compile these stable releases yourself to get better performance for your particular computer:

git clone --recurse-submodules https://github.com/darktable-org/darktable.git
cd darktable
git fetch --tags
git checkout tags/release-5.6.0

Get submodules

Note that libxcf, OpenCL, RawSpeed, whereami and LibRaw are tracked via git submodules, so after checking-out darktable, you need to update/checkout the submodules too:

git submodule update --init

Compile

Easy way

WARNING: If you have previously built darktable, don't forget to first completely remove (rm -R) the build and /opt/darktable directories to avoid conflicting files from different versions. Many weird behaviors and transient bugs have been reported that can be traced to the build cache not properly invalidating the changed dependencies, so the safest way is to completely remove previously built binaries and start again from scratch.

darktable provides a shell script that automatically takes care of building on Linux and macOS for classic cases in a single command.

./build.sh --prefix /opt/darktable --build-type Release --install --sudo

If you want to install a test version alongside your regular/stable version, change the install prefix:

./build.sh --prefix /opt/darktable-test --build-type Release --install --sudo

This builds the software for your architecture only, with:

-O3 optimization level,
SSE/AVX support if detected,
OpenMP support (multi-threading and vectorization) if detected,
OpenCL support (GPU offloading) if detected,
Lua scripting support if detected.

If you want to have dartkable displayed along your other applications, you only need to add a symbolic link:

ln -s /opt/darktable/share/applications/org.darktable.darktable.desktop /usr/share/applications/org.darktable.darktable.desktop

Now, your custom-built darktable is ready to be used just like any pre-packaged software.

Manual way

Alternatively, you can use a manual build to pass custom arguments.

Linux

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable/ ..
cmake --build .
sudo cmake --install .

macOS

See Homebrew or MacPorts instructions.

Windows

See these instructions.

Using

Test/unstable version

To use a test version of darktable without damaging your regular/stable version's files and database, start darktable in a terminal with:

/opt/darktable-test/bin/darktable --configdir "~/.config/darktable-test"

and ensure that you set the option "create XMP files" to "never" in preferences -> storage -> XMP sidecar files. This way, your regular/stable version will save its configuration files in ~/.config/darktable, as usual, the test/unstable one will save in ~/.config/darktable-test, and the two versions will not produce database conflicts.

Regular/stable version

Simply launch it from your desktop application menu or, from a terminal, run darktable or /opt/darktable/bin/darktable. If the installation did not create a launcher in your applications menu, run:

sudo ln -s /opt/darktable/share/applications/org.darktable.darktable.desktop /usr/share/applications/org.darktable.darktable.desktop

You may find darktable configuration files in ~/.config/darktable. If you experience crashes at startup, try launching darktable from a terminal with OpenCL disabled using darktable --disable-opencl.

Contributing

There are many ways you can contribute to the darktable project:

Write a blog about darktable
Create a tutorial for darktable
Help expand the user wiki or user manual
Answer questions on the user Matrix room or the pixls.us forum
Share your ideas on the developer Matrix room
Test releases
Review pull requests
Start hacking on darktable and see developer's guide

FAQ

Why is my camera not detected when plugged-in ?

Check that you have the latest gphoto2 library installed in order to support the newest cameras.

Why is my lens not detected/corrected in darkroom ?

Lens correction profiles are provided by Lensfun, which has 2 parts: a program and a database. Most Linux distributions provide a recent enough version of the program, but provide an outdated version of the database. If Lensfun is correctly installed, then update its database in a terminal by running:

lensfun-update-data

or alternatively

/usr/bin/g-lensfun-update-data

Why do the thumbnails in the lighttable view look different to the preview in the darkroom view ?

For RAW files that have never been edited in darktable (when you have just imported them), the lighttable view, by default, shows the JPEG preview placed into the RAW file by your camera. Loading this JPEG file is faster and makes the lighttable view more responsive when importing large collections of images.

However, this JPEG thumbnail is processed by the firmware of the camera, with proprietary algorithms, and colors, sharpness and contrast that might not look the same as darktable processing (which is what you see when opening the image in the darkroom view). Camera manufacturers don't publish details of the pixel processing they perform in their firmware so their look is not exactly or easily reproducible by other software.

However, once RAW images have been edited in darktable, the lighttable thumbnail should exactly match the darkroom preview, as they are processed in the same way.

If you never want to see the embedded JPEG thumbnail in the lighttable view, for RAW files, you should set the option "use raw file instead of embedded JPEG from size" to "never" in preferences -> lighttable.

Wiki

Community

Darktable forum on pixls.us

pbatard/rufus

The Reliable USB Formatting Utility

Rufus: The Reliable USB Formatting Utility

Rufus is a utility that helps format and create bootable USB flash drives.

Features

Format USB, flash card and virtual drives to FAT/FAT32/NTFS/UDF/exFAT/ReFS/ext2/ext3
Create DOS bootable USB drives using FreeDOS or MS-DOS
Create BIOS or UEFI bootable drives, including UEFI bootable NTFS
Create bootable drives from bootable ISOs (Windows, Linux, etc.)
Create bootable drives from bootable disk images, including compressed ones
Create Windows 11 installation drives for PCs that don't have TPM or Secure Boot
Create Windows To Go drives
Create VHD/DD, VHDX and FFU images of an existing drive
Create persistent Linux partitions
Compute MD5, SHA-1, SHA-256 and SHA-512 checksums of the selected image
Perform runtime validation of UEFI bootable media
Improve Windows installation experience by automatically setting up OOBE parameters (local account, privacy options, etc.)
Perform bad blocks checks, including detection of "fake" flash drives
Download official Microsoft Windows 8, Windows 10 or Windows 11 retail ISOs
Download UEFI Shell ISOs
Modern and familiar UI, with 38 languages natively supported
Small footprint. No installation required.
Portable. Secure Boot compatible.
100% Free Software (GPL v3)

Compilation

Use either Visual Studio 2026 or MinGW and then invoke the .sln or configure/make respectively.

Visual Studio

Rufus is an OSI compliant Open Source project. You are entitled to download and use the freely available Visual Studio Community Edition to build, run or develop for Rufus. As per the Visual Studio Community Edition license, this applies regardless of whether you are an individual or a corporate user.

Additional information

Rufus provides extensive information about what it is doing, either through its easily accessible log, or through the Windows debug facility.

Enhancements/Bugs

Please use the GitHub issue tracker for reporting problems or suggesting new features.

FreeRTOS/FreeRTOS-Kernel

FreeRTOS kernel files only, submoduled into https://github.com/FreeRTOS/FreeRTOS and various other repos.

Getting started

This repository contains FreeRTOS kernel source/header files and kernel ports only. This repository is referenced as a submodule in FreeRTOS/FreeRTOS repository, which contains pre-configured demo application projects under FreeRTOS/Demo directory.

The easiest way to use FreeRTOS is to start with one of the pre-configured demo application projects. That way you will have the correct FreeRTOS source files included, and the correct include paths configured. Once a demo application is building and executing you can remove the demo application files, and start to add in your own application source files. See the FreeRTOS Kernel Quick Start Guide for detailed instructions and other useful links.

Additionally, for FreeRTOS kernel feature information refer to the Developer Documentation, and API Reference.

Also for contributing and creating a Pull Request please refer to the instructions here.

FreeRTOS-Kernel V11.1.0 source code is part of the FreeRTOS 202406.00 LTS release.

Getting help

If you have any questions or need assistance troubleshooting your FreeRTOS project, we have an active community that can help on the FreeRTOS Community Support Forum.

To consume FreeRTOS-Kernel

Consume with CMake

If using CMake, it is recommended to use this repository using FetchContent. Add the following into your project's main or a subdirectory's CMakeLists.txt:

Define the source and version/tag you want to use:

FetchContent_Declare( freertos_kernel
  GIT_REPOSITORY https://github.com/FreeRTOS/FreeRTOS-Kernel.git
  GIT_TAG        main #Note: Best practice to use specific git-hash or tagged version
)

In case you prefer to add it as a git submodule, do:

git submodule add https://github.com/FreeRTOS/FreeRTOS-Kernel.git <path of the submodule>
git submodule update --init

Add a freertos_config library (typically an INTERFACE library) The following assumes the directory structure:
- include/FreeRTOSConfig.h

add_library(freertos_config INTERFACE)

target_include_directories(freertos_config SYSTEM
INTERFACE
    include
)

target_compile_definitions(freertos_config
  INTERFACE
    projCOVERAGE_TEST=0
)

In case you installed FreeRTOS-Kernel as a submodule, you will have to add it as a subdirectory:

add_subdirectory(${FREERTOS_PATH})

Configure the FreeRTOS-Kernel and make it available
- this particular example supports a native and cross-compiled build option.

set( FREERTOS_HEAP "4" CACHE STRING "" FORCE)
# Select the native compile PORT
set( FREERTOS_PORT "GCC_POSIX" CACHE STRING "" FORCE)
# Select the cross-compile PORT
if (CMAKE_CROSSCOMPILING)
  set(FREERTOS_PORT "GCC_ARM_CA9" CACHE STRING "" FORCE)
endif()

FetchContent_MakeAvailable(freertos_kernel)

In case of cross compilation, you should also add the following to freertos_config:

target_compile_definitions(freertos_config INTERFACE ${definitions})
target_compile_options(freertos_config INTERFACE ${options})

Consuming stand-alone - Cloning this repository

To clone using HTTPS:

git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git

Using SSH:

git clone git@github.com:FreeRTOS/FreeRTOS-Kernel.git

Repository structure

The root of this repository contains the three files that are common to every port - list.c, queue.c and tasks.c. The kernel is contained within these three files. croutine.c implements the optional co-routine functionality - which is normally only used on very memory limited systems.
The ./portable directory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the ./portable directory for more information.
The ./include directory contains the real time kernel header files.
The ./examples/template_configuration directory contains a sample FreeRTOSConfig.h to help jumpstart a new project. See the FreeRTOSConfig.h file for instructions.

Code Formatting

FreeRTOS files are formatted using the "uncrustify" tool. The configuration file used by uncrustify can be found in the FreeRTOS/CI-CD-GitHub-Actions's uncrustify.cfg file.

Line Endings

File checked into the FreeRTOS-Kernel repository use unix-style LF line endings for the best compatibility with git.

For optimal compatibility with Microsoft Windows tools, it is best to enable the git autocrlf feature. You can enable this setting for the current repository using the following command:

git config core.autocrlf true

Git History Optimizations

Some commits in this repository perform large refactors which touch many lines and lead to unwanted behavior when using the git blame command. You can configure git to ignore the list of large refactor commits in this repository with the following command:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Spelling and Formatting

We recommend using Visual Studio Code, commonly referred to as VSCode, when working on the FreeRTOS-Kernel. The FreeRTOS-Kernel also uses cSpell as part of its spelling check. The config file for which can be found at cspell.config.yaml There is additionally a cSpell plugin for VSCode that can be used as well. .cSpellWords.txt contains words that are not traditionally found in an English dictionary. It is used by the spellchecker to verify the various jargon, variable names, and other odd words used in the FreeRTOS code base are correct. If your pull request fails to pass the spelling and you believe this is a mistake, then add the word to .cSpellWords.txt. When adding a word please then sort the list, which can be done by running the bash command: sort -u .cSpellWords.txt -o .cSpellWords.txt Note that only the FreeRTOS-Kernel Source Files, include, portable/MemMang, and portable/Common files are checked for proper spelling, and formatting at this time.

Third Party Tools

Visit this link for detailed information about third-party tools with FreeRTOS support.

GitHub C Daily Trending Repositories

opa334/Dopamine

Dopamine

Crementif/BotW-BetterVR

Requirements

Supported VR headsets:

Other Requirements:

Current Limitations & Known Issues

Mod Installation

Troubleshooting

Controls

Technical Overview

Rendering an image to the VR headset

How to make it VR

Build Instructions (For Developers)

Credits

Licenses

nothings/stb

stb

This project discusses security-relevant bugs in public in Github Issues and Pull Requests, and it may take significant time for security fixes to be implemented or merged. If this poses an unreasonable risk to your project, do not use stb libraries.

FAQ

What's the license?

How do I use these libraries?

Are there other single-file public-domain/open source libraries with minimal dependencies out there?

If I wrap an stb library in a new library, does the new library have to be public domain/MIT?

What's the deal with SSE support in GCC-based compilers?

Some of these libraries seem redundant to existing open source libraries. Are they better somehow?

Can I link directly to the table of stb libraries?

Why do you list "lines of code"? It's a terrible metric.

Why single-file headers?

Why "stb"? Is this something to do with Set-Top Boxes?

Will you add more image types to stb_image.h?

Do you have any advice on how to create my own single-file library?

Why public domain?

Why C?

Why not C99? stdint.h, declare-anywhere, etc.

SchedMD/slurm

Slurm Workload Manager

NOTES FOR GITHUB DEVELOPERS

SOURCE DISTRIBUTION HIERARCHY

COMPILING AND INSTALLING THE DISTRIBUTION

LEGAL

lz4/lz4

LZ4 - Extremely fast compression

Benchmarks

Installation

Building LZ4 - Using vcpkg

Documentation

Other source versions

Packaging status

Special Thanks

jqlang/jq

jq

Documentation

Installation

Prebuilt Binaries

Docker Image

Run with Docker

Example: Extracting the version from a package.json file

Example: Extracting the version from a package.json file with a mounted volume

Building from source

Dependencies

Instructions

Cross-Compilation

Community & Support

License

qmk/qmk_firmware

Quantum Mechanical Keyboard Firmware

Documentation

Supported Keyboards

Maintainers

Official Website

microsoft/PowerToys

Microsoft PowerToys

Installation · Documentation · Blog · Release notes

🔨 Utilities

📦 Installation

✨ What's new?

🛣️ Roadmap

❤️ PowerToys Community

Example: Extracting the version from a `package.json` file

Example: Extracting the version from a `package.json` file with a mounted volume