Project Description
A lot of people are using mechanical keyboard. Having a custom SUSE-branded keycap would be cool. The idea is to create a set of 3D models for such keycaps in various profiles for everyone to print.
Goal for this Hackweek
- List the required profiles
- Create STL files for each of them
- 3D print and test if possible
Resources
- 3D printer, I don't have one
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
-
-
over 3 years ago by bmwiedemann | Reply
For the instructions for the previous mini batch of black-chameleon-on-green keycaps see https://mailman.suse.de/mlarch/SuSE/maxtorhof/2018/maxtorhof.2018.02/msg00022.html
-
over 3 years ago by bmwiedemann | Reply
Would also be cool if we could get the Geeko as a standard keycap into https://www.wasdkeyboards.com/products/keycaps.html?p=2 next to Arch, Debian and Mint
-
over 3 years ago by rainerkoenig | Reply
The question is: 3D print the keycap or do it in a more professional way? In my previous job I worked at Fujitsu and when we were producing keyboards they were taking raw keyboads and then engraving them with a laser. You can see lots of videos on keyboard laser engraving on YouTube. Maybe there are services around that do custom keyboards with laser engraving.
On the other hand there are laser cutters for 3D printers on the market, so you could also try to engrave them at home with a 3D printer plus laser unit. I have no idea how precise this is.
3D printing could be possible as well, but don't expect very high quality (shiny surface) from a 3D printed keycap, at least with PLA. Maybe ABS and then finishing it wir Aceton works better. But keep in mind the usually the nozzle of a 3D printer has a diameter of 0.4 mm, so the question is how good the logo will come out with this limitations.
-
over 3 years ago by rainerkoenig | Reply
There are STLs for Cherry Keycaps on Thingiverse. I just setup my 3D printer to try out...
-
over 3 years ago by rainerkoenig | Reply
Half an hour later:
Printed with 0.1mm resolution. The side surfaces are great, the top is a bit rough because its round and not flat.
-
over 3 years ago by rainerkoenig | Reply
Took the SVG scaled and extruded it in openSCAD. Then export to STL. Then then merging this with the STL of the key cap in FreeCAD. STL-Export again. Result: FDM printer is at its limits when using a 0.4 mm nozzle). Maybe better results with resin printers that have a higher resolution.
-
over 3 years ago by cbosdonnat | Reply
Could it help using some filler and sanding to get a better surface before drawing on it?
-
-
-
over 3 years ago by MattK | Reply
I have a modified CR-10 and have tried to make keycaps before with varying levels of success. I've also tried printing molds in TPU and then using them to make resin keycaps. My smallest nozzle right now is 0.4mm though. Maybe this is my excuse to finally buy a resin printer.
-
over 3 years ago by cbosdonnat | Reply
Not really 3D printable models, but still instructions to build brandable keycaps: https://www.instructables.com/Wooden-Keycaps-Using-Hand-Tools/
-
Reply to rainerkoenig
Half an hour later:
Printed with 0.1mm resolution. The side surfaces are great, the top is a bit rough because its round and not flat.
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Reply to rainerkoenig
Took the SVG scaled and extruded it in openSCAD. Then export to STL. Then then merging this with the STL of the key cap in FreeCAD. STL-Export again. Result: FDM printer is at its limits when using a 0.4 mm nozzle). Maybe better results with resin printers that have a higher resolution.
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Reply to ecandino
Hi all, I would like to join the project! I'm new to 3D printing and such, but I was curious to try and learn.
A friend of mine is also available to borrow me his Prusa Mini (with the 0.25 nozzle) 
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Reply to ecandino
This is the video of the bicolor keycap: https://www.youtube.com/watch?v=HjOd9OIDABY
I've uploaded the STL on Thingiverse: https://www.thingiverse.com/thing:5423109 but it's not visible yet because I am a new user.. :/
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
Adding individual key RGB to the keychron k17 pro by ldragon
Description
I recently acquired a k17 pro and was disheartened to learn instead of a way to set individual key RGB values we were given a set of preset "animations" and didn't have individual key RGB. The keychron k17 pro in hardware does support individual key RGB addressing as shown in many of the animations it ships with.
However this functionality is not provided to the firmware/via to set individual key RGB back light. Other keychron keyboard with similar issues seem to have this resolved by following a method similar to the one described here this aim is to replicate this one the k17 and attempt to over come the shortcomings of the original(save+load does not work).
Goals
- Port the original RGB to the wls_2025q1 branch of keychrons fork of qmk
- Fix the capslock and numlock state light not changing state after being pressed once.
- Fix the save+load issue that is present in the fork by Sasuchisama
Resources
RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso
Description
The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.
We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.
This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.
The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.
Goals
The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.
Key goals for the week:
- Analyze & Identify: Dive into the
SUSE/rmtRuby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions). - Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
- Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like
rb-sysormagnus. - Benchmark: Create a benchmarking script (e.g., using
k6,ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients. - Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.
Resources
- RMT Source Code (Ruby):
https://github.com/SUSE/rmt
- RMT Documentation:
https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
- Tooling & Stacks:
- RMT/Ruby development environment (for running the base RMT)
- Rust development environment (
rustup,cargo)
- Potential Integration Libraries:
- rb-sys:
https://github.com/oxidize-rb/rb-sys - Magnus:
https://github.com/matsadler/magnus
- rb-sys:
- Benchmarking Tools:
k6(https://k6.io/)ab(ApacheBench)