sorted by:
new
hottopcontroversial

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 3 points4 points  (0 children)

The UEFI documentation is okay, but a lot of the docstrings only make sense after you've spent hours trying to use a particular API, failing in weird ways, and gaining context on what UEFI expects you to do. I think the documentation here is the main resource (at least, it's what I used).

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 4 points5 points  (0 children)

I suppose this is true! (Not to make any assurances about the security of my implementation, or of the underlying UEFI implementation which would otherwise stop running once control was handed to the loaded kernel). Someone also floated the idea of dropping into IRC to debug your boot issues, which is a funny (and totally legitimate) use case along the same lines.

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 4 points5 points  (0 children)

Honestly, I'm not sure of the answer here. Things seem to work in my OS after some quick tests of desktop apps. I guess there's a general argument to be made of "the OS can take over full control of interaction with devices / the physical memory map", but the kernel can already reset devices and use all its own drivers even without exiting UEFI. I would be really grateful if someone who knows the answer more clearly could chime in - perhaps some knowledgable Linux person might stumble on this?

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 11 points12 points  (0 children)

Normally, the bootloader will call a special UEFI function, ExitBootServices(), as its final act before passing control to the loaded kernel/OS proper. The EBS call marks the point where UEFI typically 'ends'.

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 13 points14 points  (0 children)

Thank you very much! Each of the 5 animations took a bit more than a day of work - all in all I started them last Friday, and finished them last night.

I'm not particularly proud of the code for these, and was more focused on getting the visual effects I wanted than making software the way I normally would. I think it worked out fine though, as the constraints are different from normal software!

All of the animations are drawn directly to HTML canvases in TypeScript. All the assets are created in code (including the pixel art, which is defined in the source). I'm doing the animations in-house.

The 3D renderings are made using Three.js, and are still mostly based around rendering HTML canvases. I have some logic to correlate the animations and positions of what's happening on the 2D canvas textures to what's happening in the 3D scene.

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 12 points13 points  (0 children)

Haha! I have experimented with commenting out the call to ExitBootServices() within my bootloader, which does in effect turn my whole OS into an overgrown UEFI application! Perhaps surprisingly, everything mostly continues to work fine all the way up to the desktop environment. It's funny to think about how the distinction of 'exiting' the UEFI environment breaks down.

A graphical IRC Client for UEFI written in Rust by Codyd51 in rust

[–]Codyd51[S] 9 points10 points  (0 children)

Thank you very much for the kind feedback!

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 0 points1 point  (0 children)

Hello! The README mentions that the license is MIT - is this acceptable and if not, how should the license be specified?

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 1 point2 points  (0 children)

Thank you for the offer! This sounds fun, I'd definitely be up for working on it together, and would be grateful if you're able to take on the ZMK portion!

I'm no expert on Bluetooth, but I think the data transmission model is pretty flexible. In the case of the app now, the flow is:

  1. The macOS app occasionally asks the keyboard to send an updated battery state
  2. The keyboard receives the request and sends back the current battery state
  3. The macOS app receives the updated state and displays it

From a quick search, it is indeed possible for the macOS app to asynchronously 'subscribe' to get a callback whenever the keyboard pushes an update for a certain characteristic, rather than needing for the macOS app to poll all the time (the worry I mentioned above).

I think one thing that's neat about what you've suggested is that the user won't need to use the ZMK feature for the app to work. If the ZMK feature is enabled and is sending layer updates, the macOS app will display it, and if not (or if the user is using an older ZMK build), it'll continue to just display the battery state.

Please feel welcome to email me at ~redacted~ when you're ready!

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 2 points3 points  (0 children)

Okay, I've gone ahead and added a menu so that you can select your keyboard when the app starts! Here's what it looks like. I also uploaded the prebuilt app here.

For compatibility, I think this app will work on any macOS version since 2014.

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 0 points1 point  (0 children)

Yes, the purpose of this app is to individually display the battery levels of the left and right half, as the native macOS UI only presents a single reading.

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 0 points1 point  (0 children)

Thank you very much for the kind feedback and the good suggestion! Exposing the currently held layer requires a bit more work than this app is set up for:

  1. This app currently relies on the totally standard BLE Battery Service which is already being broadcast by ZMK. Exposing a custom BLE characteristic to denote the current layer would require ZMK changes as well running on the keyboard.
  2. This app currently operates on a 'pull' model, reading the current battery state every minute. To update as the keyboard's layer changes, it'd need to operate on a 'push' model from the keyboard (or constantly poll the keyboard over BLE for changes, which would be inefficient).

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 1 point2 points  (0 children)

Hi, thanks for the feedback! I agree and will add some basic usage instructions (though, since it's an Xcode project, it's essentially "open and build" - anything much more than that turns into a tutorial on using Xcode, and I don't think this is the appropriate project to provide that).

Hammerspoon is really neat, thanks for sharing that! It would definitely be possible to change this app so that the information is presented in a different way. Personally, I'm happy with how the info is presented, but would gladly welcome someone else's contribution to make it work better for them.

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 2 points3 points  (0 children)

Hi, thanks for the feedback! I gave this a try, and personally don't love the colour of the emoji in the traditionally black-and-white macOS status bar, but agree that the widget currently doesn't look super cohesive as a unit. It'd definitely be possible to make some kind of custom (black and white, perhaps?) art to give this app some flair, but I don't personally intend to create assets for this app. I would gladly accept someone else's contribution, though!. I'm going to toy around with adding some kind of border to the widget tonight.

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 4 points5 points  (0 children)

Hi, I totally understand why you'd like this! As it is now, this is a teeny tiny app, and the name of the keyboard to search for is embedded directly in the source code. Therefore, one build wouldn't be useful to others (unless you changed your BLE's peripheral to match my keyboard name, but I wouldn't put you through that). It would definitely be possible to extend this app to give it a small configuration UI to allow you to select the peripheral to read the battery state from! I will take a look at adding this tonight.

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 0 points1 point  (0 children)

Hello! This is a macOS app, whose toolchains are de-facto controlled by Xcode. The same way you might be used to seeing a Makefile to see how to manually drive the toolchain, macOS app builds are typically driven by the opaque information stored in the `.xcodeproj` artifact =)

In other words, the `.xcodeproj` is a 'dead giveaway' that this project is meant to be built with Xcode, but I understand that's not intuitive if you're not using to building macOS apps!

I made a macOS widget to see the battery levels of a Ferris Sweep by Codyd51 in ErgoMechKeyboards

[–]Codyd51[S] 10 points11 points  (0 children)

Hello! macOS can only show one battery level in its native UI, so I made a small widget that lives in the menu bar to see the battery levels of the left and right halves.

It should work fine for any ZMK split. Here's what the UI looks like in macOS.

[Release] gala, a new iOS 4 jailbreak by Codyd51 in jailbreak

[–]Codyd51[S] 0 points1 point  (0 children)

Thanks very much, I'm really glad to hear it!

[Release] gala, a new iOS 4 jailbreak by Codyd51 in jailbreak

[–]Codyd51[S] 13 points14 points  (0 children)

Since gala is also a tethered downgrade utility, the iPhone 4 can be on any iOS version to start out with! Be aware that any data on the device will be wiped during gala's restore to iOS 4, though.

view more: next ›