Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
szhou42 wrote:https://github.com/szhou42/osdev
My first GUI (looks familiar? )
You're buttons look upside down
Reminds me of how my own UI theme was based on the GTK theme I was using when I got started. I think my take on the design looks better, though (but I'm probably biased).
monobogdan wrote:So, if your OS POSIX compatible, why not port Wayland and GTK, and write DE on GTK?
Porting Wayland requires a huge amount of work; it either requires massive changes to Wayland and its supporting libraries or a port of almost all of Linux' user space APIs.
Wayland by default uses Mesa EGL and dbus. EGL uses DRM (Linux' user space GPU interface) and udev. The default implementations of dbus and udev are part of systemd. udev is based on sysfs and netlink sockets. systemd requires APIs like namespaces and cgroups.
While I do think that porting all this is viable it is by no means easy and many people here might not want to turn their OS into a Linux clone.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
monobogdan wrote:So, if your OS POSIX compatible, why not port Wayland and GTK, and write DE on GTK?
Perhaps some of us actually want to write desktop environments ourselves, from our own toolkits, for our OSes. Operating systems are more than just kernels.
szhou42 wrote:https://github.com/szhou42/osdev
My first GUI (looks familiar? )
You're buttons look upside down
Reminds me of how my own UI theme was based on the GTK theme I was using when I got started. I think my take on the design looks better, though (but I'm probably biased).
Kevin, please respond.
What is the name of that theme? I would like to use it on my Ubuntu. Thanks!
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
It works! I now have a virtual VBE text-mode ANSI-compatible console. For some reason modesetting only works on QEMU though... Anyone got any ideas why?
zesterer wrote:For some reason modesetting only works on QEMU though... Anyone got any ideas why?
How are you setting the mode? Where else other than QEMU have you tried your code?
I'm using "set gfxpayload=1024x768x32" in grub.cfg, and my multiboot header is requesting a linear mode with width / height of 0 (I'm told this means "go as high as you can").
I've tried my code on Bochs and real hardware (2 laptops - a newer 64-bit machine, and an older mid-2000s 32-bit machine).
zesterer wrote:I'm using "set gfxpayload=1024x768x32" in grub.cfg, and my multiboot header is requesting a linear mode with width / height of 0 (I'm told this means "go as high as you can").
I've tried my code on Bochs and real hardware (2 laptops - a newer 64-bit machine, and an older mid-2000s 32-bit machine).
Do you have bit 2 (value 4) set in your kernel's multiboot flags? Is the "mode type" field set to zero in your kernel's multiboot flags? A value of zero in the width/height fields doesn't mean "go as high as you can;" it means that your OS has no preference. You mention an old laptop from the mid 2000s; does it support 1024x768? I have a laptop from that time that cannot go higher than 1024x600.
BTW, it should work in Bochs.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
zesterer wrote:I'm using "set gfxpayload=1024x768x32" in grub.cfg, and my multiboot header is requesting a linear mode with width / height of 0 (I'm told this means "go as high as you can").
I've tried my code on Bochs and real hardware (2 laptops - a newer 64-bit machine, and an older mid-2000s 32-bit machine).
Do you have bit 2 (value 4) set in your kernel's multiboot flags? Is the "mode type" field set to zero in your kernel's multiboot flags? A value of zero in the width/height fields doesn't mean "go as high as you can;" it means that your OS has no preference. You mention an old laptop from the mid 2000s; does it support 1024x768? I have a laptop from that time that cannot go higher than 1024x600.
BTW, it should work in Bochs.
I have bit 2 set, and mode type 0 in multiboot flags. Should I specifically request a 1024x768 resolution? I've tested it on older hardware and my own newer amd64 laptop. Both machines (I've checked with vbetest in GRUB) support at least 1024x768x32 resolutions.
The fact that it isn't working with Bochs suggests to me that it's another issue, but then again I might simply not have Bochs set up correctly for VGA stuff.
I figured it out (I really should have worked this out sooner) the framebuffer was being allocated in a region of memory I didn't expect, and it was page-faulting. It didn't alert me because... well. It had no screen to print to.
That looks like a bitmap font to me. I'd be more annoyed at the cursor shape if anything (that tail should be 22.5º, not 45º).
I've been doing, huh, some serious redesigns in Indigo. New practically everything pretty much (except cursors and font, I guess). The garbage rows at the bottom will be replaced with a taskbar (acting like some sort of Alt+Tab so you don't have to explicitly quit every time). Also took a new approach to shading the buttons.
Gotta figure out how to appoach floating point to get this calculator done (or probably just do fixed point, since there's a limit to how many digits can be shown on screen and I have no intention to bother with scientific notation). Then I may upload source code (・・ )
Finally got my 64-bit OS working! I had many troubles with paging. Implementing "recursive mapping" helped me a lot.
I'm focusing now on the 64-bit version. Next big step: adding UEFI support (won't be easy).
Obsidian 64
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
)
