Develop GUI subsystem

Question

Develop GUI subsystem

wangrunji0408 opened this issue 5 years ago · comments

Enable VESA on x86.
Use crate console_traits to unify console output.
Use crate embedded-graphics to unify graphics output.
Implement OpenGL

Blealtan · Answer 1 · Mon Mar 04 2019 22:46:01 GMT+0800 (China Standard Time)

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?

Runji Wang · Answer 2 · Tue Mar 12 2019 12:15:32 GMT+0800 (China Standard Time)

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!

Shengqi Chen · Answer 3 · Thu Apr 04 2019 00:30:48 GMT+0800 (China Standard Time)

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 · Answer 4 · Thu Apr 11 2019 13:03:29 GMT+0800 (China Standard Time)

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

Blealtan · Answer 5 · Fri Apr 12 2019 14:52:05 GMT+0800 (China Standard Time)

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.

Runji Wang · Answer 6 · Mon May 13 2019 21:22:22 GMT+0800 (China Standard Time)

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!

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 · Answer 7 · Tue May 14 2019 12:08:15 GMT+0800 (China Standard Time)

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.

Runji Wang · Answer 8 · Tue May 14 2019 13:44:28 GMT+0800 (China Standard Time)

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 · Answer 9 · Wed May 15 2019 10:34:55 GMT+0800 (China Standard Time)

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.