Elecrow CrowPanel Advanced HMI Display Review: A Tinkerer's Touchscreen

I have been (mostly) happily running Home Assistant in my homelab for a while now. There is a tiny issue, though. While my wife and I can manage most devices through the companion app, kids or guests cannot.

Reaching out for a phone is not always convenient, and of course, I cannot handover my phone to guests. Home Assistant's own Voice Preview device is not a capable device if you are not connected to the cloud.

So when I got my hands on the Elecrow CrowPanel Advanced 10.1", a big ESP32-P4 touchscreen, I got some ideas. I could configure this device to allow access to some connected devices and put it in a common area where anyone in the household could use it.

It's an ESP32 device, and I already tinkered a little with ESPHome on my ZimaBoard so it was kind of a natural fit.

Note that this is a developer board with a screen. It's not an out-of-the-box smart home panel you just take out of the box and mount on your wall. If you enjoy tinkering, building things, you will like the device. If you want something that just works, it's not for you.

📋

Elecrow sent me this device for review. The views expressed are my own.

Hardware specification

Here is a quick look at what this device is packing inside it:

Component	Detail
Main SoC	ESP32-P4 (dual-core RISC-V)
Wireless	ESP32-C6 co-processor (WiFi 6, Bluetooth 5)
Display	10.1" IPS, 1024x600, MIPI-DSI
Touch	Capacitive (GT911 controller)
Memory	16MB flash, 32MB PSRAM
Audio	Onboard speaker output (dedicated connector) and microphone
Camera	Camera connector (add-on)
Expansion	Exposed I2C, UART, and GPIO headers
Power	USB-C, plus a battery connector
Model	DHE04310D (hardware revision V1.1)
Price	Around $60

It has interesting hardware, especially since it also offers a camera connector. My package came with a camera as well, not sure if it is included in all the boxes.

And then you also get the options to connect speakers on their own port. Which means that if you connect a LLM to your Home Assistant, and get a reply in audio format. There is a battery connector in case you want to use the device without direct power connection. The I2C, UART, and GPIO pins are accessible, too.

📋

I am using Home Assistant everywhere because this is what I am using this device for. However, this Elcrow display can be configured and used in a number of projects. You just have to put your tinkerer hat on.

Setting up the display with Home Assistant

This is where I spent most of my time, and where you should set your expectations.

Out of the box the board runs Elecrow's demo firmware, which shows off the screen but does nothing useful really. But it is still good enough to test the touchscreen and its connectivity. You would at least know that the device is working.

The demo gives you enough to test its functionality before you build on it

To make it as control panel for the Home Assistant, I flashed it with my own firmware. I went the ESPHome route, since ESPHome talks to Home Assistant over its native API and does not need the Supervisor add-on setup, which matters because I run Home Assistant in a container on Zima OS.

I will be honest, the first flash was not smooth. Getting WiFi up on this board took real work, because the ESP32-P4 has no radio of its own and leans on the ESP32-C6 over an internal SDIO link. On my V1.1 unit, the data line order was reversed compared to the reference configs I was following. Until I sorted that out, the board just kept rebooting. But that's really my fault.

One thing worth mentioning is that the stock demo firmware did not remember my WiFi after a reboot. I had to enter the credentials again. Once I moved to my own ESPHome firmware, it remained connected after reboots. So, if you only ever run the demo, do not expect it to hold settings. Perhaps that's the intentional behavior?

My first test project was really simple. I coded a single button on the screen to work as a switch in Home Assistant for my geyser plug. Tapping it toggled the real device. Also, when I flipped the geyser from the Home Assistant app instead, the button on the screen updated to match. So, things worked as expected.

I am new to LVGL, and thus I tried with a very basic project

Elecrow recommends SquareLine Vision for building the UI visually, which should be easier (more intuitive) than coding in LVGL in Arduino IDE.

📋

The quick test shows that the core promise of the Elecrow CrowPanel works. With ESPHome you can build a touch dashboard that controls real Home Assistant devices and reflects their live state, all running on the board itself with no extra server.

The display in everyday use

The screen itself is fine. It's not top-notch like an iPad. The best way I can describe it is that it feels like an entry-level tablet.

The 1024x600 IPS panel is bright enough and the viewing angles are okay, but it is not going to impress anyone who has looked at a modern premium phone recently. For a control panel stuck on a wall showing buttons, that is completely acceptable.

Touch response was good in my testing. Taps registered reliably and I did not have to poke twice.

Ports, audio, and the room to grow

The CrowPanel display is meant to be more than just a display.

The two small speakers, when paired with the onboard microphone, can work as a voice satellite for Home Assistant Assist. So you get both a screen and a voice endpoint in one device.

Of course, I am limiting it to Home Assistant but you can have more usage in godowns, factories, and even in homelab setups. Your imagination and creativity can be better than me.

Then there is the battery connector. A battery option gives it more flexibility and portability. It may be a good fit where you need the device to survive during a power cut. I did not test battery life as I did not have a spare battery to connect.

The exposed I2C, UART, and GPIO means you can plug in extra sensors, another microcontroller, or your own hardware off this board. For a DIY audience, that flexibility is worth more than a prettier screen.

Elecrow suggests various scenarios where it could be used

The camera and the AI question

Elecrow also mentions "integrated AI vision capabilities" because it has the scope for an add-on camera. The 2 MP camera is optional but it came in the package. I plugged the camera in and it worked.

I have not properly tested the on-device AI feature. The ESP32-C6 is supposed to give edge AI capability to embedded devices. Now this could work with simpler cases like facial recognition for unlocking access, my thinking is that instead of running AI on the display board itself, use it as an interface and let a vision model run on a more capable device.

Is it worth getting?

🚦

Who is it for: Homelab owners and makers who see the setup work as part of the fun.
Who is it NOT for: Anyone who wants to mount a panel on the wall in ten minutes and thinks of using Android style apps to control their set up.

This is a decent offering for DIY makers. From homelab to actual industry usage, this device has potential that can be utilized by your requirements and imagination.

If you already tinker with ESPHome or ESP32 projects and you want a large touchscreen to build a project, this board gives you a lot to work with.

Play with LVGL and you can configure the device as per your need. And you don't even need to know coding. LLMs these days can easily help you generate code you want for your project.

I am repeating myself. This is not a plug-and-play smart home panel. You have to build on it. I started with a working control panel, and I plan on expanding that dashboard well beyond one button.

But if you are not comfortable flashing firmware, writing/generating code, it's not for you.

Explore CrowPanel Advanced HMI Display

from It's FOSS https://ift.tt/uGenw0Y
via IFTTT

GrapheneOS Isn't Happy With Google Over Pixel's Widening Head Start

Google's September 2026 Pixel Update Bulletin contains patches beyond what's in that month's regular Android Security Bulletin. According to GrapheneOS, some of those extra patches touch standard Android platform code, the kind that runs on non-Pixel devices, not just Pixel-branded hardware.

None of that platform-level code has reached the regular monthly bulletin or the private preview patches other manufacturers typically draw from to get their own patches ready.

And at this rate, these won't reach non-Pixel OEMs at all until Android 17 QPR2 ships later this year in December.

The project is characterizing this as Google "gatekeeping security patches to the standard Android platform code from Android OEMs."

The complaints

GrapheneOS says Android 17 QPR1 shipped new developer APIs that never made it into AOSP. This is something they claim hasn't happened since Android's Honeycomb days.

Google's API diff report backs this up. Comparing Android 17 to QPR1 shows one new package, android.hardware.hid, plus changes across sixteen others, including android.media, android.os, android.provider, android.telecom, and android.view.

GrapheneOS has ported its code to QPR1 before Google even released it, but still doesn't have permission to ship that work. For now, the project is backporting Pixel firmware, kernel drivers, userspace drivers, and HALs from QPR1 onto Android 17 instead.

On top of all that, there's a compliance issue that seems to be recurring.

Google was slow to comply with a GPL source request. GrapheneOS requested sources for a build (CD1A.260905.001.A1) on September 1, and access only came through more than two weeks later.

Why this is worrying

None of these three issues is catastrophic by itself. A three-month patch delay, a paused API rollout, a two-week wait on source code—each is the kind of thing that could pass as a one-off.

Taken together, however, they point to a recurring theme. Google is holding security fixes back from the wider Android ecosystem, withholding new APIs from AOSP for the first time in over a decade, and slow-walking GPL compliance it's required to meet.

Don't even get me started on what they are doing to the Android app ecosystem.

Google is on track to require every Android app developer, whether on the Play Store, F-Droid, or anywhere else, to register with them. Come 2027, that means handing over legal identification and signing key evidence before an app can run on any certified device.

Sideloading an unverified app following this would mean enabling developer settings, waiting through a mandatory 24-hour cooldown, and clicking past several warning screens (classic scare tactics, btw).

GrapheneOS is one of dozens of organizations that signed onto the Keep Android Open campaign opposing this, alongside F-Droid, the Electronic Frontier Foundation, and the Free Software Foundation.

If you ask me, this Big Tech company is doing what's regrettably natural for it, clamping down open access to things so that its competition cannot benefit.

Via: Android Authority.

from It's FOSS https://ift.tt/YGbBSdf
via IFTTT

Valve Quietly Open-Sources Its Android Compatibility Layer

Yeah, Valve has not bothered putting out a proper announcement for this. I got to know about this thanks to Liam Squires-Hand, who covered it briefly yesterday. The gaming giant has open-sourced the Android compatibility layer it built for the recently launched Steam Frame.

Lepton lets users play games exclusive to Android on Linux by launching them inside a container. Valve says most users will not interact with Lepton directly since the Steam client itself handles that job.

The project is aimed at game developers who want to bring VR-focused Android titles over to Steam Frame, though the repository does note other use cases are possible.

Two licenses, one codebase

The compatibility layer is not released under a single license, as the repository's LICENSE.md file splits the project into two pieces, each governed separately.

The compat tool itself, the part Steam invokes to actually launch a game inside the container, is released under the MIT license. The Android root filesystem that gets built and run inside that container is a different matter. Because it incorporates code from several outside projects, it carries a GPL-3.0 license instead.

What's included?

Lepton's Android image is not built from scratch. It leans on a handful of existing open source projects, each covering a different piece of the puzzle.

Waydroid is the one doing most of the heavy lifting. It already runs a full Android system inside a Linux container using namespaces, and Lepton borrows patches and components from it directly during the build.

LineageOS supplies the actual Android system image that Waydroid, and by extension Lepton, customizes. Waydroid's runtime ships a minimal image based on LineageOS.

AOSP, the Android Open Source Project, sits underneath all of it. It's the base source tree that LineageOS, Waydroid, and, in turn, Lepton all build on top of, and its license terms carry throughout the whole stack.

Boringdroid gets a smaller credit in the same license file, alongside the others, though Valve does not go into detail on what it specifically contributes. You can go through its repo to make an educated guess.

Don't click away yet

This project is not trying to be a general-purpose way to run Android on Linux. It has been trimmed down on purpose.

Every app inside Lepton runs as the same user, with no walls built between them. Each game is instead meant to get its own separate container, and when launching them, Lepton switches off the Android services it does not need.

There's more to it than what I have discussed, so go through the repo if you would like to learn more.

It's good to see that while the Steam Frame has not started shipping yet, parts of its software stack are already being open-sourced. Lepton joins FEX, the x86-to-ARM translation layer Valve relies on for the same headset, as pieces of a stack that developers can now read, inspect, and build against.

---

Suggested Read 📖: The various compatibility layers in SteamOS.

from It's FOSS https://ift.tt/3czOK4h
via IFTTT

Bonjour! Firefox Smart Window Users Now Get to Use a French AI

Mozilla and Mistral have announced a partnership that brings the Mistral Small 4 model to Firefox Smart Window, the browser's AI-powered window that lets users chat their way through a web browsing session.

Both companies portray this as pushback against a browser ecosystem increasingly dominated by a few large companies. The concern is that one company could end up running the browser, the search results, and the AI answering your questions.

This is followed by the expansion of beta access to the feature in eligible regions as well as improved French language support.

Why go with Mistral?

Firefox 155 was the release that opened up Smart Window to users based in France, though the beta originally ran with three AI models: Google's Gemini, Alibaba's Qwen, and OpenAI's gpt-oss-120B.

None of those came from a European lab. Mozilla says it evaluated the 119-billion-parameter Mistral Small 4, specifically for its multilingual performance, before adding it to the "Personalized" category, replacing OpenAI's offering.

The other models are still available, of course. The company is just pushing Mistral as an additional pick that gives users more choice rather than settling for a few limited options.

And that language support I talked about earlier isn't some half-baked job where a translated interface was bolted on top of an English-first model. Mistral has tuned the model directly on regional languages and dialects, treating multilingual handling as a core feature.

The company says support for more European countries is coming later this year, without naming any specific ones, while Mistral has already confirmed that the UK and Germany are next.

Should you bother?

When I tried Smart Window, it was a beta release limited to people in the US and Canada that I got into through an early-access portal. I found it useful for summarizing a page, discussing certain choices, and asking it follow-up questions about my queries.

What has changed now is that it has reached France and that one of its models comes from a local AI lab. You can see it in how both of these companies are describing the move.

Mistral is pitching this as sovereign AI reaching consumers, while Mozilla calls it an independent browser working with a frontier European AI company.

Coming back to the question, you should care about this if you are someone who wants an AI-powered sidekick for your research sessions without the headache of setting one up manually.

So what are you waiting for? Get started right now by downloading the latest Firefox release!

---

Suggested Read 📖: Firefox 155 has introduced two new changes for faster web browsing.

from It's FOSS https://ift.tt/XsTnyve
via IFTTT

Zsh Quiz: How Well Do You Know Your Shell?

Zsh has become the default shell for a lot of Linux and macOS users, and for good reason. Between Oh My Zsh, autosuggestions, and smarter tab completion, there's a lot going on under the hood.

But how much do you actually know about it? Take this quiz and find out.

🚧

Some browsers block the JavaScript-based quiz units. Disable your ad blocker to enjoy the quizzes and puzzles.

Few people know that Zsh's roots go back to 1990, when Paul Falstad created it as a student project. That means, Zsh is older than Linux.

I've spent a good amount of time customizing my own zsh setup, and honestly, there's more to it than most users realize. Tab completion itself works very differently (or should I say better) from bash. Then there's spelling correction, smarter globbing, and configuration through .zshrc that can get as simple or as complex as you want.

If you want to learn Zsh, try this resource section on Linux Handbook.

from It's FOSS https://ift.tt/vLgTmUy
via IFTTT

The Famed PS5 Linux Project Lead Quits Over a Premature Exploit Report to Sony

In April this year, we saw Andy Nguyen turning the PS5 into a Linux-powered gaming PC that ran Steam games and emulators, making good use of the hardware on-board.

Sadly, he has now announced that he is walking away from the PS5 hacking scene altogether and is stopping work on porting the project to the PS5 Pro, which would've shipped sometime in 2027.

All due to a single exploit

I am stepping away from the ps5 scene and stopping all my work on ps5 linux.
After pouring my heart and months of my life into it, including plans to finish ps5 pro support and release in 2027, it's all down the sink.

— Andy Nguyen (@theflow0) September 15, 2026

You see, running Linux on a PlayStation console is possible because the PS5 Linux project was able to find a way past the hypervisor using exploits Sony had already patched, covering firmware 3.00 through 7.61.

The issue starts with Andy gatekeeping a hypervisor bug that was still open on current firmware, one he says he had found a while earlier. It was prematurely divulged to Sony less than a day after the researchers who found it agreed to wait.

He clarified his position, saying that:

I asked them to at least wait for GTA 6 to come out so that people would have the opportunity to legally purchase the game and also enjoy linux.

Once Sony knows about a bug such as this, it's only a matter of time before it's patched, and that is where PlayStation's bug bounty program on HackerOne comes in.

The ones who found it

To give you an idea of PlayStation's HackerOne program.

While Andy has not named anybody in his post, you will find the reporter after a quick web search. Jordy has put out his side of things, laying out how he handled the bug.

By Jordy's account, the bug was his own discovery, found with what he calls his "trusty ai clanker machine" and no help from anyone else. He had even agreed to Andy's request to not disclose the findings.

Unexpectedly, a third person, still unnamed, found the same bug using AI a few hours later. Anticipating that there would be more people finding the same bug, Jordy decided to post the flaw on HackerOne.

The code is still there

The project's GitHub page and all the related repositories are still there. Nothing has been archived as of today, and if you wanted to, you could start contributing to the PS5 Linux project by taking over any pending work or cooking up new improvements.

You should know that the loader currently supports the original model and the Slim on firmware 3.00 through 7.61, so your test device would need to be on one of those. The PS5 Pro support Andy was building never reached the repository, so you would have to start from scratch.

That's the beauty of open source software. Even if the lead developer and key core maintainers decide to abandon a project, new people can easily take over the work or fork it, and steer it in a direction of their choosing.

While Andy's departure is a blow to the plan for supporting newer PS5 firmware and the PS5 Pro, other contributors have shown that they can deliver work on the loader without him, and I am hopeful more will follow.

from It's FOSS https://ift.tt/tU8Rk5i
via IFTTT

How an Italian Logistics Company Moved From Windows to Linux: A Real Migration Story

In the past, I have shared stories of how real people using Linux in the real world. My favorite is the interview with Stu Keroff, who educates students to make the best use of Linux in school.

When Mišo reached out to me and shared how he helped a local small business move from Windows to Linux, I though of reviving that old series where real people share real stories of how they migrated to Linux and open source.

Mišo Oroz is the founder of Zerolock, an Italian IT company based in Spirano, Bergamo, specialised in migrating small and medium businesses from proprietary systems to Linux and open source.

Here's his story.

---

I got the call in early 2026. The owner of a small transport and logistics company in Mapello, Bergamo, had five office workstations and a team of drivers who needed to stay in contact throughout the day. He was not looking for a philosophy lesson about open source. He was tired of paying for software that kept causing problems, tired of calling an external technician, and tired of his team losing time to things that had nothing to do with moving goods from one place to another.

What they had before

The office ran on a standard setup that most small Italian businesses would recognise. Five workstations running a proprietary operating system (you know which one), a commercial office suite licensed per user, third-party antivirus renewed annually.

The drivers communicated with the office using WhatsApp on their personal phones, which meant company conversations were happening on a consumer messaging app with no archiving, no administration, and no separation between personal and work messages.

Their data lived partly on local machines and partly on a shared folder. When I asked to see where the most important company documents were stored, it took a few minutes to find the most recent version of a file that should have been immediately accessible.

The owner had paid for eight to ten external IT interventions over two years. Update failures, slowdowns, the occasional scare that turned out to be less serious than it looked but still cost half a day of anxiety and cleanup time.

The assessment

Before touching anything, I spent time understanding what each person actually did on their computers every day. This matters more than any list of installed software, because the real question is not what tools exist but which ones are genuinely in use and how.

The office staff used a word processor, a spreadsheet, email, and a shared filing system. The owner needed occasional remote access when he was out on the road. The drivers needed a reliable way to communicate with the office without using personal phones. No sector-specific proprietary software that would be difficult to replace, which made the project significantly more straightforward than many migrations I have worked on.

The stack

The replacement infrastructure was built entirely on open source components.

Kubuntu 26.04 LTS on all five office workstations. LibreOffice replacing the commercial office suite. Thunderbird for email. Nextcloud deployed on a server hosted in Italy, replacing both the local shared folder and eliminating any dependency on foreign cloud providers. Mattermost for internal communication, installed on the same Italian infrastructure, accessible from both the office workstations and the drivers' phones via the mobile app.

The office used an Epson WorkForce WF-C579R, a networked A4 colour multifunction connected via ethernet. This was the most technically interesting part of the hardware setup.

Kubuntu 26.04 automatically installed a driverless IPP driver, which caused two concrete problems: duplex printing reversed the back page regardless of whether long-side or short-side binding was selected, and print speed was noticeably slower than it had been on the previous system. The driverless path, which works well for many modern printers, does not handle all Epson business devices correctly on 26.04 because the Epson PPA does not yet support the current release.

The solution was to install printer-driver-escpr via apt and force the correct driver using lpadmin. After that, duplex worked correctly and speed returned to normal.

For scanning to a network folder, I set up Samba on each administration workstation, created a Scanner folder in each user's home directory, and configured the scan destination on the Epson web admin panel via IP address using SMB with dedicated credentials set through smbpasswd. This is worth documenting for anyone running Epson business printers on Kubuntu 26.04, because the driverless default will cause the same duplex problem and the fix is not obvious.

pfSense as the network firewall. Encrypted automated backups running nightly. For remote access I deployed RustDesk through my own VPS, which solved a specific challenge with Kubuntu 26: the system runs on Wayland by default, and many remote desktop tools that work reliably on older Linux systems have compatibility issues with Wayland. RustDesk via a self-hosted relay server worked consistently once that configuration was in place, and it has been the standard approach for all my Kubuntu 26 deployments since.

Total recurring licence cost after migration: zero.

The migration

Everything was built and tested on a separate machine before touching any production workstation. I validated every workflow, confirmed that existing documents opened correctly in LibreOffice, tested the Nextcloud connection, and set up Mattermost including the mobile configuration for the drivers.

The actual migration happened over a weekend. Each workstation was rebuilt from scratch with a clean Kubuntu installation. Data was migrated from the existing shared folder to Nextcloud over the local network before the weekend, so that by Monday morning the files were already in the right place on the new system. The drivers received the Mattermost app on their phones with the configuration already set up. From day one they had a dedicated work channel separate from their personal messaging.

Training and the first days on site

The weekend migration was only the beginning. The following Monday I was on site for the first three days of the working week and available by phone for the rest. Each employee received individual training on the tools they actually used, not a generic overview of the new system. I sat next to each person and worked through their specific daily tasks: how to open and save documents in LibreOffice, how to access files on Nextcloud, how to use Mattermost for internal messages.

This part of the project is not glamorous but it is where migrations succeed or fail. The software can be perfect and the migration still falls apart if the people using it feel abandoned on Monday morning. Being on site those first days meant I could answer questions immediately rather than leaving people stuck waiting for an email reply.

What was actually difficult

Two things created friction, as I mentioned earlier. Since this is sort of a case study, I will highlight those two hurdles again.

The first was the printer. The Epson driverless issue was not something I had encountered before on 26.04 and it took a few hours to diagnose and resolve. The duplex problem was intermittent enough that it would have been easy to miss during testing and only surface in daily use. I now test duplex printing explicitly on every Kubuntu 26.04 deployment with a networked Epson.

The second was the Wayland remote access setup. Kubuntu 26 required a different approach to remote desktop than older Linux systems. Testing different configurations took additional time before I arrived at the RustDesk and self-hosted VPS solution that now works reliably. It is a known challenge with Wayland that the ecosystem is actively improving, but at the time it required real problem-solving.

The adjustment period for the office staff was easier than I had anticipated, largely because of the time spent on site. The drivers adapted fastest. For them the change was a new app on their phone that replaced a WhatsApp group, and within a day or two it felt normal.

Six months later

The company has not called me for a single ordinary technical issue since the migration.

The productivity difference showed up in ways that were immediately visible. Before the migration, the workday started with machines that took several minutes to become usable after login, with antivirus scans running in the background competing for resources. Unscheduled updates had a habit of appearing at the worst possible moments, sometimes forcing restarts mid-morning. When something broke, work stopped until the external technician arrived.

After the migration, bootup is fast, background processes do not fight for CPU during working hours, and updates run overnight without touching the working day. The time that had been quietly disappearing into slowdowns, restarts, and waiting is simply not disappearing anymore.

Licence costs for the operating system, office suite, and antivirus are gone. The Nextcloud server costs less per month than their previous storage arrangement. The external technician has not been called.

The drivers now have a proper work communication channel that is administered, archived, and completely separate from their personal phones.

The end result is one hour per day recovered per employee, zero ordinary technical issues after migration, zero recurring licence costs. We have a happy client.

from It's FOSS https://ift.tt/8Z7w2zF
via IFTTT