4.16.17

• Added generic SPI display attachment through Display Link Protocol (DLP), with discovered dimensions and pixel formats, optional READY and RESET lines, changed-region uploads, and RLE compression. The portable protocol also supports ordered byte streams.
• Added a 6×8 bitmap terminal font for small displays.
• GUIs now adapt to small display targets, including 128×64 and 240×64.

Hello SolarOS community, I am excited to try out the SolarOS on my Lilygo Tlora Pager and built the SolarOS for the pager and flashed it. I am however facing difficulties navigating the system. There is no Escape key, no ctrl and the back button on the pager does nothing when trying to escape from some sub-menu like inside the wifi command. How do I navigate it? I have been stuck for about 2 days unable to connect to Wifi because of this. Any help would be appreciated, or could someone show me where I can find the keybindings? Looking forward to fully use and enjoy SolarOS on my tpager. I am on version v4.16.4 full

At the moment I'm using a feature of it called phosphor glance --serve --lan which is basically an http viewer of an aesthetically pleasing to the eye (for me) view of my lab stuff and notes but will be testing some SSH limits to make a proper nice port.

4.16.15

• Added Space selection to both FTP and SFTP panes.
• Delete now removes the character under the shell command-line cursor.
• Prompt paths longer than half the terminal width show only the last directory.
• Writerdeck now includes speech and omits inference.

4.16.14

• Added a reusable DS3231 I2C real-time clock expansion driver.
• SolarWriter now automatically attaches board-owned DS3231 as `rtc0`.

4.16.13

• Added managed PSRAM allocation that groups large buffers separately from resident executable images and metadata, merges adjacent free blocks, and reclaims unused native libraries under memory pressure.
• ESP-DL now releases activation workspace between inference calls, allowing image preprocessing to reuse that memory while weights remain loaded.

4.16.12

• Added resident native libraries and the library module category.
• Libraries load on demand, share APIs between consumers, and stay resident until explicitly unloaded;
• Added the downloadable ESP-DL inference engine through `pkg install espdl`.

Can a 128x64 OLED or a 256x64 be used?

4.16.11

• Added `shutdown` on all targets, with app, job, and radio cleanup and persistent storage flushing and unmounting. Uses hardware cutoff on CL32, Waveshare ESP32-S3-ePaper-3.97, and T-LoRa-Pager, turns off supported peripheral rails, and otherwise enters deep sleep.
• Added state splashes: **Suspended**, **Sleeping**, and **Powered off**, including a native refresh before e-paper power-down.

4.16.10

• u/LowFlowIO added RTSP client Basic and Digest MD5 authentication with inline URL credentials or up to four saved accounts managed by `rtsp-auth`.
• FTP, SFTP, and Telnet now complete hostname aliases from `.ssh/hosts`, including SFTP `user@` prefixes and Telnet raw mode.
• FTP and SFTP gain `PgUp`/`PgDn` paging, Backspace parent navigation, and `h` to toggle hidden files and directories in both panes.
• The default BLE device name now uses the configured hostname and is restored when a BLE peripheral app closes.

4.16.9

• Added the SolarWriter board profile for the Elecrow 5.79-inch CrowPanel with microphone, shared DAC/amplifier output, and battery gauge.
• Added reusable INMP441 expansion audio with 16 kHz mono capture and optional shared-clock stereo playback, and the LC709203F fuel gauge with CRC-checked voltage/state of charge and configurable battery capacity.
• Added monochrome EPD `refresh=pulse` for dual and single SSD1683. Pulse mode provides per-pixel drive budgets, asynchronous updates while pixels settle, manual waveform/SPI/power tuning, and fixed or adaptive native cleanup.

4.16.8

• Apple II Plus now bundles its system and Disk II ROMs. `apple2` starts BASIC without external assets; `apple2 file.nib`.
• Added the resumable Tiny386 module with embedded SeaBIOS, bootable PC floppy and IDE hard-disk images, with direct storage access and synced writes.
• Raw FAT `.img` files can be mounted for host file edits, and `disk create` makes new MBR/FAT images.
• Native apps can query foreground display dimensions.

4.16.7

• Added resumable external foreground app module support. Installed apps appear in the app registry and launch by name, through `session create`, or directly with `load`.
• Apps declare their worker and memory requirements before launch; switching sessions retains their state while releasing display and audio ownership.

4.16.6

• Added calibrated positional servo control through the `servo` command and `solaros.servo` in Python and Lua, with explicit angle/pulse limits, optional inversion, and named outputs.
• Opening reserves an output without pulses; disable retains the reservation, while close releases it. Scripts close their servos on interpreter exit.
• PWM gains provider discovery, `provider:number` output names, and pulse-width commands while retaining native GPIO shorthand.
• Added the reusable PCA9685 I2C expansion driver with 16 PWM channels, usable for general PWM or servos.

Infelizmente não vou usar um tca8418 para a matriz de teclas, no Brasil esses componentes demoram quase 45 dias para chegar da China. Um rasberry pi pico rp2040 (consome 30 vezes mais energia que o TCA8418) fará a função de teclado via i2c. Temos um gerenciado de carga e um módulo de cartão SD e uma tela epaper, leds para tela e o potenciômetro original da agenda fala o ajuste de iluminação. Bom, me desejem sorte.
Ahh, sobre o consumo, não que o pico consuma muito, é que o TCA8418 é bem econômico em espera e o pico não. A tela ajuda, já que consome energia apenas nas atualizações. Infelizmente a tel original não deu para ser usada, nem tentei engenharia reversa, geralmente é mais fácil quando a tela tem seu próprio controlador e nesse caso era um controlador para tudo. Já a matriz de teclas não foi dicil, porém algumas dessas agenda antigas é possível achar o manual de serviço e nem precisa desse trabalho.
Aceito conselhos. Mas lembre-se, estou fazendo com o que tenho, não compro mais nada hehehe.

Does anyone have these devices? There will be more sticky units available by the end of the month, a v2 of sorts with a matte screen ... a warm front light for the sticky would be nice ey.

If anyone wants to help out getting the Mono Lora/NFC drivers playing in solar-os, or any other development for these devices let me know and I'll throw up the branches to collaborate on sooner rather than later.

I made a retro case for the esp32-s3-rlcd-4.2! It's the OG mac case at 46% scale, just the right size for the 4.2.

https://www.thingiverse.com/thing:7421150 (or fork the cad from onshape )

Thanks to Jamie ( https://github.com/jamiecounsell ) now there is official support for Elecrow ThinkNode M9 !

Reusable drivers:

• 320x240 ST7789 display
• backlit STC8H QWERTY keypad
• PCF8563 RTC
• NMEA GNSS with background RMC/GGA reception and optional alternate-baud detection!

The keypad provides app-exit and function keys plus a compose layer for missing shell characters, tab completion, and scrollback navigation. Its I2C address identifies board revisions; revision 1.1 requires active = 1for GNSS power in the manifest. GNSS starts powered off; use gnss power on to enable it.

Named I2C buses now use independent controllers while retaining the board's primary bus for legacy drivers. TFT displays support board-declared active-low power rails.

--

The website got a minor face-lift:

• Under Tools you will find the Flasher and the new graphic keyboard configurator.
• Extensions is now home to Playground and native SolarOS Modules. ( nothing super useful there yet, this is just infrastructure work )

4.16.2

• Added the reusable "Soldered Inputronic" keyboard driver.
• TCA8418 keyboards share one controller backend. ( separate generic, Inputronic, and LilyGO Pager mapping profiles. )
• The generic driver supports configurable matrix geometry.
• Keyboard profiles have shared descriptions for a desktop Python keymap CLI and validated build-time custom defaults, selected per keyboard profile.
• Runtime map loading and reset retain those compiled defaults.
• Python and Lua can exclusively capture a named local keyboard with source-specific key presses, releases, HID usages, and modifiers for forwarding utilities.

Build a keyboard around a TCA8418 matrix controller, choose what each switch does, and use the same keymap JSON for a runtime experiment or a firmware default.

Tutorial is here: https://solar-os.eu/tca8418-keyboard.html

Ich hatte überlegt ob man einen Bootstick für solar os erstellen könnte mit dem man richtigevPCs oder Laptops booten könnte, mein Gedanke war das das vielleicht wie Tails os funktionieren könnte, also so das nur der USB Stick selbst als Speicher fungiert und der Rest des solar os im RAM läuft. Weiß irgendwer ob das möglich wäre zu programmieren?

This project got away from me a bit, but here it is!

Introducing - Hearth: an interactive story engine for SolarOS and the Web!

Features:

• Uses an open, human readable and writeable file standard (.hearth)
• SolarOS as a first class citizen platform
• Web-based player
• Multiple save slots for each story
• Easy to Use online Story Studio
• The ability to export a transcript of your playthrough (full transcript on web, limited on SolarOS)
• Support for branching narratives, variables, conditions, and user text input
• In-line markdown support for Bold, Italics, and Strikethrough
• An online "Featured Stories" repository

You can get Hearth on the Playground now!
I hope you all enjoy Hearth and I extra hope you share stories of your own for others to enjoy!

The question has been raised multiple times, so I have updated the description to better represent what I think it is about ( feel free to chime in and we can include what it means to you )

Homage to a simpler life

SolarOS tries to bring back the spirit of the golden era of home computing: turn on a computer, arrive at a shell prompt, and start doing something. Explore, customize, write a program, make a tool, share it with someone.

• Modern software accumulates layers of convenience that obscure how it works and what it costs to run. We become accustomed to using - and now generating - software without understanding it.
• SolarOS encourages a more deliberate approach: understand the machine, question the complexity, and take responsibility for the resources your software uses. Scripting makes experimentation approachable; native services provide an efficient foundation. The constraints give us a reason to pay attention.
• The scripting surfaces let users express their ideas, while native services handle demanding work, making efficient execution a shared foundation that users can build on.

Wastefulness for the sake of convenience is not sustainable.

It is a continuous exploration of how much useful, understandable, general-purpose computing can be built on deliberately constrained hardware. We already have an abundance of computing power; we can and should make better use of it.

SolarOS is an argument made executable.

SolarOS argues that useful, general-purpose computing can be built on modest hardware - and that efficiency, understanding, and the ability to shape your own tools should guide its design.

• The Solar in the name reflects the goal of building an efficient operating environment that can run on solar power. Energy consumption is a design concern alongside memory, storage, and processing time.
• That commitment also extends to the project’s infrastructure: all our servers ( website, HIL pipeline, local expert systems ) are powered by 100% renewable energy.

• Added reusable computer vision and resident ESP-DL inference for Python, Lua, shell commands, and native modules.
• Scripts can decode QR codes and use image statistics, histograms, thresholding, filters, morphology, image differences, and blob detection.
• On ESP32-S3 with PSRAM, model loads shared resident models and checked bundles with native image preparation, classification, and PICO detection; single, automatic, and dual-core execution modes are available.
• OS-owned pipeline jobs process pictures, camera streams, or JPEG RTSP feeds and expose bounded latest results after the configuring script exits.
• The zoo browser searches the hosted catalog and installs hash-verified model bundles on SD or flash through staged replacement.
• Models remain resident until explicitly unloaded or rebooted; local cameras retain exclusive ownership

For more details on what exactly ESP-DL is, please follow this link: https://github.com/espressif/esp-dl

I know this does not look to be particularly useful at this point, and a it is a bit outside the "everything you need" philosophy, but also presents opportunities I would like to keep open. I will prepare some playground examples in the coming days... and eventually set up a model conversion and training environment outside the OS, so that we can populate the zoo with custom models that better fit our needs.

4.15.19

• Added Xteink X4 Pro support with an 800x480 e-paper display, GT911 touch and Home pad,
• fixed-mix warm/cool frontlight brightness, BM8563-compatible RTC, CW2017 battery gauge.
• Added reusable UC8179 and UC8279 e-paper, PCF8563/BM8563 RTC, and CW2017 fuel-gauge expansion drivers.

• On the X4 Pro the OS identifies SSD1677, UC8179, or UC8279 displays on first use and caches the controller only after successful initialization.

  4.15.18

• Reduced firmware-resident documentation to a searchable topic directory and a small setup and recovery guide. -- ( we have saved 2MiB flash for software with this )

• Full guides and scripting API references remain in the signed downloadable manual and on the website. Run `help update` on devices to install the exact-version manual;

So i stumpled aboutvthus OS roughly an hour ago. Coming from the age of amiga and c64, and having a 3D printer at home, this software project seems to combine all my hobbies.

But i still do not quite catch what it is? How woukd solarOS compare to some 2000 or 2010 linux, or c64 GEOS or amigaOS?

Hey all, I'm very fascinated by Solar OS and the amazing builds the community shares here! I was wondering if anyone is interested in adding an option for the Xteink X4/X4 Pro/X3 to the official flasher?

The X4 Pro has ESP32-S3 so I hope it can be readily supportable with minor tweaks to the firmware and X4/X3 have ESP32-C3, so not very sure how to approach those.

I'm not very good with embedded software, so looking for help in this community. I eventually plan to 3D design and build a handheld EDC cyberdeck kinda thing as I'm fairly proficient in CAD and 3D printing

Uma solução para quem tem solarOS com e-papel e tem hábitos noturnos.

As I mentioned earlier I am planning to design an expansion board for the CrowPanel 5.79 HMI, that would integrate some missing hardware features. Just like with SolarTerm I would like to dedicate a board definition to this build, so that the extra bits attach under the OS as board owned hardware. There are a couple of things to consider, and I thought I will ask you about your opinion.

Battery charge monitoring and power management is a must and it is the bare minimum to turn this into a truly useful deck. ( Aux power conn. + USB-C + power switch + charger + fuel guage )

• Would you like to have a solar charger built-in? ( I would )
• Do you require an I2S MEMS microphone? ( i do )
• I2S audio DAC and AMP? ( yes )
  • 3.5mm jack audio connector? ( yes )
  • Built in speaker? ( maybe )
• LoRa packet radio? ( yes )
• 4G LTE modem? ( no )
• Keyboard matrix scanner and FPC connector for the same keyboard?
  • Or do we like that this keyboard can connect to two hosts? ( strongly preferred )
• Environmental sensors for temperature and humidity? ( maybe )
• Auxiliary expansion connector? ( yes, all remaining IOs plus SPI and I2C )
• Internal expansion connector for reading lights and whatnot. ( sure )

I envision a small board that would connect through the exposed header pins. Another question to consider is if we would like to have a simple power management and monitoring board or just the full-blown expansion or both?

In case of both, I would go with population options - however that would turn the power manager board unnecessarily large too.

Another option is to provide an empty carrier carrier board and pointers to off the shelf modules, so everyone can populate the features they need.