Show more

Haha, and here's the commit from Jan 31 that is exactly the same as the hack I just made to the kernel last night. It's pretty fun I can look at the commit history like that. Open source development is awesome! Thanks, Andrzej!

Oooh!! Apparently the features I want were added to later versions of the FunctionFS kernel module! Maybe I should back-port those changes to the source tree I'm stuck working with.

It's fascinating that my quick hack is almost exactly reproduced in current linux kernel sources!

Might just have to "bite the bullet" and write a proper kernel module for my device. But staying in userspace is soooo much more convenient!

Oi! The FunctionFS system in the Linux Kernel is really cool for creating USB devices in userspace, but it's not quite as configurable as I'd like it to be.

It doesn't seem to support USB 3 speeds at all, and if you try for USB 2 "HighSpeed", FunctionFS limits you to "FullSpeed" instead. Womp womp.

It took a custom hack to the FunctionFS kernel module, but I finally got my USB device working at the speeds I want. =) (for now).

Not sure if that's the right solution long-term, but it'll do for now.

In other rendering news, I'm keeping my eye on the DriftFX project. It integrates with other rendering technologies like D3D and OpenGL.

Maybe someday I can integrate it with Kludge and allow JavaFX GUIs. In addition to ImGUI.

Here's an example of depth buffering from a more complicated application that uses Kludge: molecule rendering.

This is an N-terminal Alanine molecule rendered in a space-filling style.

Those spheres are actually not meshes. They're rendered directly in the fragment shader, so they're pixel-perfect at any resolution. The fragment shader generates the depth information too.

I just updated my Kludge library (a thin wrapper for ) to expose an API for depth buffering!

Here's some fully-working sample code if you want to see how to use depth buffers in Kludge:

Even though the blue triangle is drawn after the red one, it has a farther z value, so it gets clipped by depth buffer testing.

It's such a small change, but it's nice we no longer need `args: Array<String>` in main() declarations.

I just updated my Kludge project, an idiomatic API for :

Wow, the more I learn about , the more I like it. Having move semantics (and having the compiler forcing me to use them) totally changes the way I think about organizing my code! I can have forced self-destructive instances now, which totally prevents double-cleanup bugs.

Have to say, bindgen is pretty great, but it took a while to get it working due to kbuild. Not bindgen's fault.

And the rustc error messages are just super helpful. Crate and rustup are amazing too!

Overall, the Rust ecosystem is really inviting and I hope I don't have to write much more C code in the future. =)

Still learning because JVM interop with C code just isn't great. Looks like trying to interface with the Linux kernel using Rust was about the un-gentle-est introduction I could have possibly attempted.

Nevertheless, I will persist.

Startup idea: A big red button 🔴 with a USB port that enumerates as a keyboard ⌨ and when you press it, it emits CTRL-C so you can SIGINT your programs more dramatically 🎆

I've been working a lot with low-level system libraries and OS functions lately. I've been finding that my usual dev platform ( on JVM) has way too much friction with C interop.

So I'm learning some now to see if that's better. Looking good so far! Rust has a great onboarding experience! Even for my fancy cross-compiling case.

I've noticed a pattern in my dev work lately. I'll often bang my head against a problem for a few hours one afternoon, unable to mentally crack the issue, only to leave work, enjoy my evening, and come in the next morning to solve the problem in less than 15 minutes.

I'm planning to use the GPU on my little single-board-computer to do some interesting stuff. I'm working on a JVM-based tech-stack though (because is amazing), so there's no better library for GPU support than 3!

I managed to get LWJGL 3 to cross-compile to an aarch64 platform. If you're curious, see how here:

Finally got my single-board-computer working as a USB device! :blobaww:

Now to get the host side working.

And here's a shoutout to the Linux kernel for letting me do almost all of this in user-space! :linux:

I'm trying to turn a single-board-computer into a USB device. Little did I know that was a Very Deep rabbit hole to go into. Now I'm drowning in the world of configfs and functionfs.

I'll figure out the host side later. libusb I guess?

Show more
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!