rust-osdev / vga

Library to program vga hardware.
Apache License 2.0
54 stars 14 forks source link

contribution #11

Open gldan opened 4 years ago

gldan commented 4 years ago

Are there any plans for this project? I want to contribute to this but don't know the plan.

RKennedy9064 commented 4 years ago

Nothing is currently set in stone, but the next thing I'd like to add is a mode x writer since that seems to be the mode that most of the cool graphical features were implemented in. Once mode x is added I'd love to add a lot of the features from chapter 38+ of this book https://github.com/jagregory/abrash-black-book.

I've been referencing it a lot and it seems like there's a lot of cool things that can be added to this crate. The main issue I've seen so far is that a lot of the more advanced features require memory allocation, so if someones kernel doesn't have that they can't be used. One approach I was thinking was gating some of the more advanced features behind an allocator config in cargo so the base crate can be used by anyone, and users with an allocator can enable the advanced features.

I'm pretty open to improvements and ideas, so if you have any suggestions I'd love to hear them.

RKennedy9064 commented 4 years ago

@gldan One thing I started looking into recently was the fact that qemu has support for 2 ati radeon cards listed here.

qemu: -device ati-vga. ✓ VGA compatible ✓ vgabios support ✗ no UEFI support Emulates two ATI SVGA devices, the model property can be used to pick the variant. model=rage128p selects the "Rage 128 Pro" and model=rv100 selects the "Radeon RV100".

I have the documentation for the rage128p card, so thought might be a good starting point. I tried running my existing vga code using that device with qemu and it ran as expected. This might be a good card to try and emulate for some of the more advanced graphics features since its built into qemu and the documentation seems decent.

tsatke commented 1 year ago

I'm just going to hijack this issue - I've submitted two PRs with functionality that I currently implemented myself in the kernel. I would like to further contribute (after those two PRs, otherwise I'm afraid it gets too messy with dependencies between branches).

If you can provide some input about your compatibility plans and maybe even a roadmap, I'd also like to become a maintainer of this crate if you're open to that @RKennedy9064 .