search

oscourse-tsinghua / rcore_plus

Rust version of THU uCore OS. Linux compatible.
MIT License
172 stars 26 forks source link

Develop GUI subsystem #9

Open wangrunji0408 opened 5 years ago

wangrunji0408 commented 5 years ago
Blealtan commented 5 years ago

Would like to work on VESA and later on more. Are we going to be with VESA 2.0 and do all rendering in kernel mode, or VESA 3.0 for better performance? Guessing rendering fully in protected mode is possible for rcore.

Huanqi Cao from Advanced OS Lecture 2019

Edit: just realized VirtIOGpu implementation already exists, but found no usage in base repo (damn GitHub no forked repo code search). What's the latest plan? Gonna provide multiple drivers?

wangrunji0408 commented 5 years ago

Sorry I forgot to reply...

Graphics driver is now working on riscv(VritIO GPU) and aarch64(Raspi3 GPU). VESA on x86 is what needs to be done.

GUI is a long term plan and I don't have any idea now. But we have an expert: @equation314 . Maybe we can discuss future plan and designs here.

Welcome to join us!

Harry-Chen commented 5 years ago

Currently, I extract the frame buffer driver and console driver out of aarch64 architecture to the universal driver folder. All platform-specific code is decoupled from the driver and moved into board crates.

Now the work is in mipsel branch, will be merged to master once we successfully compile it...

Blealtan commented 5 years ago

I'm now working on VESA on x86_64, just FYI.

Blealtan commented 5 years ago

Forget about VESA; it requires VM86 to work, thus we have to go back to 32 bit protected mode every time touching it. Old-school guys may like it but I don't and @jiegec neither.

I'm working on the VMWare SVGA II driver. It's present in QEMU with -vga vmware. As a PCI device it seems rather simple to get on with.

image image

wangrunji0408 commented 5 years ago

Recently I followed this tutorial and successfully enabled VESA 1024x768x24bpp in real mode in bootloader (commit). It has a linear framebuffer, so there's no need to call any BIOS functions after going to long mode. And it works on real PC!

WechatIMG1052

Now we have graphic mode on all platforms! I think it's time to standardize them and implement Linux framebuffer. Then we will be one step closer to real world GUI applications.

Blealtan commented 5 years ago

Congrats!

Have you investigated how to get VESA working in 64 bit long mode? AFAIK it requires switching to 32 bit protected mode with VESA 3 or real mode with VESA 2. It's really annoying I would say.

wangrunji0408 commented 5 years ago

Congrats!

Have you investigated how to get VESA working in 64 bit long mode? AFAIK it requires switching to 32 bit protected mode with VESA 3 or real mode with VESA 2. It's really annoying I would say.

It seems there's no way to call VESA functions in long mode. And they only use these BIOS calls in bootloader. OS usually directly controls the graphic card via driver...

P.S. Recommend an answer in Zhihu: 计算机底层是如何访问显卡的？

Blealtan commented 5 years ago

Yes I'm aware of that, I'm familiar with GPU actually (but not VESA a while ago). But when you need to inform graphic unit to do something, e.g. switching (double) frame buffer, you still need to do VESA calls. Switching to protected mode, do protected mode commands, switching back is required whenever some VESA function is really needed. But anyway you can just setup a single frame buffer with everything settled, and just use it all along the way. Neither efficient nor elegant, but works; might be a good position as a fallback/beginning of impl (as is in most OS running on x86(-64)) though.