zmk-rgbled-widget: A ZMK module to add battery & BT indicators using an RGB LED (like in Xiao BLEs)
I find that having a way to check the battery and connection status is very useful with wireless devices. Traditionally, the way to do this is through the addition of a display. However I always thought displays were a bit overkill for that and once I started using Xiao BLE controllers I noticed that they have an RGB LED built onto the controller itself that can be programmed.
So I wrote a small tool to indicate the battery and BT profile status that uses that LED, and I thought I'd share more broadly in case it is useful to others. It's pretty easy to add to your ZMK build as documented in the README as it is a ZMK module.
While it supports Seeeduino Xiao BLE out of the box, it's also easy to add support for it if you have a custom keyboard that has three dumb LEDs for RGB colors.
GitHub - caksoylar/zmk-rgbled-widget: A ZMK module to add battery & BT indicators using an RGB LED (like in Xiao BLEs)
A ZMK module to add battery & BT indicators using an RGB LED (like in Xiao BLEs) - caksoylar/zmk-rgbled-widgetGitHub
Kalle Sundin är en ny ledarskribent i Aftonbladet. Han har skrivit en ledare om att justitieminister Gunnar Strömmer borde läsa kriminologi. Det har han helt rätt i. Men även Kalle Sundin borde läsa kriminologi.
This week in Plasma: inhibiting inhibitions and more!
This week in Plasma: inhibiting inhibitions and more!
This is a big one, folks. Plasma 6.2’s soft feature freeze is now in effect, which means the last few features have just been merged! Now we’ll have six weeks of heavy bug-fixing before…Adventures in Linux and KDE
Brainf...
some brainfuck fluff
Includes a complete language reference, plus my many brainfuck programs and some implementations and commentary.brainfuck.org
"Let scaling-aware Xwayland clients scale themselves..." merged in Gnome
Let scaling-aware Xwayland clients scale themselves with "scale-monitor-framebuffers" (!3567) · Merge requests · GNOME / mutter · GitLab
Based on this branch from Jonas Ådahl, main commit: Apply custom scaling to...GitLab
like this
You're talking about extensions.
Extensions that don't come from GNOME are not supported at all, they've made that clear. If they wanted to, they could just stop allowing third party extensions altogether.
This is because they hook directly into GNOME Shell's' internal JS, which changes every release as they refactor it for performance or feature changes. Developers have a few months before release to adjust their extensions for the newer version.
Personally, I just raw dog vanilla GNOME for stability, and it works fine.
We've had this on KDE for a year or two now, and it's mostly been great.
It won't mean no more blurry apps unfortunately, but games will render at the correct resolution and some xwayland apps will look a lot better.
The coolest new space pictures: August 2024
The coolest new space pictures: August 2024
The Juice spacecraft accomplished a historic “double” gravity assist and took photos to prove it.The Planetary Society
like this
Researchers Map 50,000 of DNA’s Mysterious ‘Knots’ in the Human Genome
like this
I've spent a good amount of time studying various DNA processes and never once made a connection between i-motifs and clippy. Great catch! lol
The thing is, our cells create these "knots" to make room for enzymes to access our DNA. They're quite common as it's required for DNA transcription + replication, chromosome segregation in cell division, telomere maintenance, and to alter gene expression. Not sure how I overlooked what happens if they form more often than intended. Wild to learn it can lead to cancer, neurodegeneration, and heart disorders! Guess I missed two massive aspects when studying all this, the imapct of DNA forming i-motifs too often, and the resemblance to clippy hahaha.
Come venivano dal regime fascista strumentalizzati i fumetti...
Grottesco anche il caso di Dick Fulmine, di matita italiana, personaggio italo-americano operante dapprima negli USA, ma che nel luglio 1942 si trova nella fantasia di queste pubblicazioni non si sa come a combattere a fianco delle Forze dell'Asse.
Aggiungo una copertina, quella di "Albo dell'Intrepido" del 23 maggio 1942, perché nella nuova versione degli anni '50 era uno dei miei giornalini preferiti.
Alcuni fumetti continuarono ad essere pubblicati, altri vennero recuperati dopo le censure del fascismo, nuovi ne emersero, più di settant'anni fa...
LWN report about the "Rust for filesystems" session which a Rust for Linux maintainer referred to for context when retiring from the project this week
Their resignation is already being discussed in another post here from yesterday: One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"
...but I think this LWN reporting (from back in June) deserves its own post as it makes it easier for those of us who are not kernel hackers to follow what is going on.
reshared this
like this
like this
It's an interesting read to see how Kernel developers argue and think.
It's an important goal to adjust to how kernel devs discuss kernel issues.
Please don't trivialize the efforts of a smart person in a very underestimated discipline.
It's an interesting read to see how Kernel developers argue and think.
You sound like some mad scientist experimenting with kernel devs.
Large organizations always have politics—it's human nature. 1700 people is quite a large organization. Therefore, the kernel maintainers have politics. The presence of politics always means that some people will get stomped on unfairly.
This is all business as usual, in other words, and it will not go away. At best, you can shift the culture of the group and the politics along with it, but that takes time and effort and people-handling.
Academics on Mastodon
Academics on Mastodon
A list of various lists consisting of academics on Mastodonacademics-on-mastodon
Elasticsearch is Open Source, Again
Elasticsearch is Open Source, Again
Elastic is adding AGPL as an open source license option to Elasticsearch alongside ELv2 and SSPL....Elastic
like this
reshared this
On Rust, Linux, developers, maintainers
On Rust, Linux, developers, maintainers
There's been a couple of mentions of Rust4Linux in the past week or two, one from Linus on the speed of engagement and one about Wedson...Dave Airlie (Blogger)
like this
reshared this
Talks about different developer styles, slightly interesting and not too long winded I guess, but not much about the actual situation.
I think this is still not such a great look for Rust. I had expected interfacing Rust to C to present fewer problems than it seems to. I had hoped the Rust compiler could produce object code with almost no runtime dependencies, the way C compilers can. So integrating Rust code into the kernel should be fairly painless from the C side, if things were as one would hope.
It does sound to me in the earlier post that there was some toxicity going on. Maybe it had something to do with the context being a DRM driver.
I looked at a few Rust tutorials but they seemed to take forever to get to any interesting parts. I will keep looking.
like this
Your point about it being a culture issue is spot on. Many maintainers who are established in the kernel have made it clear they'd rather keep the status quo and the comfort of stagnation rather than bring a new technology forward to improve the security of their systems.
If it wasn't Rust, but some other language with similar benefits, the same people would've thrown their hands in the air and complained that they're being forced to rewrite everything or some other hyperbole.
Because it's a FOSS project, for some reason it's acceptable for maintainers to be entitled arseholes who abuse anyone they personally have a vendetta against.
In any other workplace, this behaviour wouldn't be called "nontechnical concerns" it would be called workplace bullying. And as much as Linus wants to say he's working on his anger issues, he is personally one of the contributors who has set this culture of aggression and politicking as much as any other.
silico_biomancer
in reply to bravekarma • • •bravekarma
in reply to silico_biomancer • • •Nice! It was essentially my first Zephyr project and I tried to make it accessible code-wise, so I am happy you found it useful in that regard.
I know at least a couple other people that adapted it to a single LED. I’d probably do it too if I needed it but I’d find it difficult to share it with others given that decoding the information is harder for others.