OSDev.org

Korona wrote:

octacone wrote:That is actually impressive! Btw what do you mean by native graphics driver? Setting a bad pixel clock? What is your method, VESA or VGA?

I'm using neither VESA nor VGA. I manipulate the native registers of the graphics card (i.e. I set a pixel clock, display timings, program the framebuffer address and enable graphics output). The driver can set any mode (e.g. 1920x1080@32bpp) that is supported by the card and the monitor. I do not have to use the BIOS or any third party functionality. However keep in mind that the driver is tied to Intel G45 and similar chipsets.

It is easy to extend this to hardware double/triple/whatever buffering on VSYNC, hardware mouse cursors, hardware overlays (i.e. displaying a second framebuffer inside a window) and multiple monitors. My code does not support acceleration (BLTing or shaders) yet though.

Wow, that's incredible. Is your code open-source? I'd love to take a look at it in order to see what you're doing; Intel's documentation is a little overwhelming for someone without extensive experience of embedded systems like me. Given that it's the Intel G45, is this driver also compatible with most Intel HD integrated graphics chips?

zesterer wrote:Wow, that's incredible. Is your code open-source? I'd love to take a look at it in order to see what you're doing; Intel's documentation is a little overwhelming for someone without extensive experience of embedded systems like me. Given that it's the Intel G45, is this driver also compatible with most Intel HD integrated graphics chips?

Yes, my code is available here on github (beware of C++ operator overloading). I did not push the DDC code for getting EDID information without the BIOS yet (which is required to discover the video modes that a connected monitor supports). I also did not spend much time on cleaning up the code yet. I plan to write a wiki page that explains how to do the mode set.

About portability to other graphics chips: The driver as-is should work for all (non-mobile) third generation Intel graphics chips from this list (i.e. all card produced in 2006-2009). There would be minor changes required for generation 3 chips. I don't think it is worthwhile to support anything below generation 3.

For later generations: Regarding the display registers there are two notable overhauls in Intel HD graphics chips: The first is the introduction of Ironlake and the second the introduction of Haswell. All chips in between do not need many changes in the driver. The greatest difference between Ironlake and G45 is that Ironlake shares clock sources between different display pipelines so you need a mechanism to allocate clock sources (which is trivial if you only use one display pipe). I did not yet look into the changes introduced with Haswell.

That being said I do think that it is possible to support those generations if you want to. I do not think that writing a mode setting driver for the newer generations is much more complicated than writing a mode setting driver for the G45. The hardware might be a bit more complex but it is also much better documented. I did not choose G45 because it is easy; I just chose it because that is the hardware that I had available .

Korona wrote:

zesterer wrote:Wow, that's incredible. Is your code open-source? I'd love to take a look at it in order to see what you're doing; Intel's documentation is a little overwhelming for someone without extensive experience of embedded systems like me. Given that it's the Intel G45, is this driver also compatible with most Intel HD integrated graphics chips?

Yes, my code is available here on github (beware of C++ operator overloading). I did not push the DDC code for getting EDID information without the BIOS yet (which is required to discover the video modes that a connected monitor supports). I also did not spend much time on cleaning up the code yet. I plan to write a wiki page that explains how to do the mode set.

...

Thanks a lot for this info, that's really helpful. I'd love to see a wiki page that gives a high-level explanation of it all: modesetting as run-time would be great.

My integer-to-text routine has a particular way to handle 0x80000000 (it was supposed to show -2147483648):



It was fixed, the routine was going through 31 bits because I was stupid enough to assume the MSB would be clear after making the integer positive. Go figure. (no, division wouldn't do the job because I'm on a decades old CPU and that'd take ages, besides I only get 16-bit division which only makes it worse =P took a different approach by adding BCD numbers instead)

EDIT: if anybody is interested on the routine (without the bug, that is):
http://gendev.spritesmind.net/forum/vie ... f=2&t=2573

Sik wrote:My integer-to-text routine has a particular way to handle 0x80000000 (it was supposed to show -2147483648):



It was fixed, the routine was going through 31 bits because I was stupid enough to assume the MSB would be clear after making the integer positive. Go figure. (no, division wouldn't do the job because I'm on a decades old CPU and that'd take ages, besides I only get 16-bit division which only makes it worse =P took a different approach by adding BCD numbers instead)

Is your OS public/open source? I love it's ideas (and the OS itself) and would love to study your code.
EDIT: if the source isn't available I would still like to test it in a VM.

Not yet, I want to finish the calculator first =/ (I need to come up with an easy division algorithm, I've been slacking off on that) Though yes I do intend to release the source code.

Sik wrote:Not yet, I want to finish the calculator first =/ (I need to come up with an easy division algorithm, I've been slacking off on that) Though yes I do intend to release the source code.

Thanks for telling me!

Sik wrote:My integer-to-text routine has a particular way to handle 0x80000000 (it was supposed to show -2147483648):



It was fixed, the routine was going through 31 bits because I was stupid enough to assume the MSB would be clear after making the integer positive. Go figure. (no, division wouldn't do the job because I'm on a decades old CPU and that'd take ages, besides I only get 16-bit division which only makes it worse =P took a different approach by adding BCD numbers instead)

EDIT: if anybody is interested on the routine (without the bug, that is):
http://gendev.spritesmind.net/forum/vie ... f=2&t=2573

Nice interface!

Double Buffering fail :p The blue is meant to cover the screen (Still haven't fixed this problem)

"repz movsd" in a console screen clear function instead of "repz stosd"

On the flipside, now you have a random number generator.

With a period of 1, where the seed comes from another RNG, and the generated number is the seed itself.

Sik wrote:On the flipside, now you have a random number generator.

This was exactly my first thought...

I have just as many questions.

Crashed when troubled in mutex.