Re: VESA alternatives?
Posted: Wed Dec 23, 2015 2:36 pm
The reason I think it sucks is because I thought I'd get something more exciting... But either way, thank you all for the answers.
If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers. But ultimately, that's your choice.animefreak1233 wrote:The reason I think it sucks is because I thought I'd get something more exciting... But either way, thank you all for the answers.
You don't necessarily need the time now. There's nothing wrong with designing a system for "everything" (e.g. for native video drivers) and then only implementing a small part (e.g. whatever is the least you can do for the "no video driver" fall-back you're going to need anyway); because that avoids the "Oh, I need to redesign/rewrite a lot of things" problem if you ever do get the time later.animefreak1233 wrote:I sure as hell wish I had the time...
Intel's hardware without the GPU's processing power looks much simpler. The complexity of a hardware specific driver without processing acceleration is at the same level as the combination of VGA+VESA+v8086. It is possible to start with Intel's VGA mode documentation and next to extend a driver towards Intel's specific modes. And sometime in the future a developer with such experience will be ready to start working on the GPU's processing power utilization.Combuster wrote:If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers.
Not only that but since no major OS uses VBE 2, and the protected mode interface, many implementations actually won't work so you need to stick to the real-mode interface.tom9876543 wrote: Unfortunately VBE 2.0 was only a small improvement on 1.2, it could of been so much better.
I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later? I even ponder on single-stepping the real mode mode change code in order to understand what registers are important, but surely there should be some better source than that to get to this point?embryo2 wrote:Intel's hardware without the GPU's processing power looks much simpler. The complexity of a hardware specific driver without processing acceleration is at the same level as the combination of VGA+VESA+v8086. It is possible to start with Intel's VGA mode documentation and next to extend a driver towards Intel's specific modes. And sometime in the future a developer with such experience will be ready to start working on the GPU's processing power utilization.Combuster wrote:If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers.
Here is the latest available display part of the Programmer's Reference Manual for Intel Graphics.
And here is the list of all available specifications.
Even "just setup a LFB" is complicated and a lot of work. So no, there isn't a simple example and there won't ever be.rdos wrote:I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later?
Code: Select all
boot->enter VESA LFB mode and store base address->set up 32-bit structures->enter C code and do some drawing
I have no problem with using the VESA interface from V86 to switch video mode. That has worked for many years now. The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes. Also, in order to boot with UEFI without sacrificing video mode independence, I will eventually need to do change video mode directly against the Intel GPU rather than with the BIOS.jojo wrote:I mean, if your system's VESA implementation supports LFB then it's relatively straightforward to set up a simpleThe complex part is, as mentioned, configuring VESA from inside 32-bit code almost not even because of the complexity of the details of v86 but because it depends on either going through all of the details of setting up process management which is a whole subject unto itself or otherwise assuming that the user has set that up already in which case you can't really tell them how to start v86 helpers because you don't know how they decided to set up their process model.Code: Select all
boot->enter VESA LFB mode and store base address->set up 32-bit structures->enter C code and do some drawing
You have way less flexibility, but if you can write a booter that enters protected mode then you can add a pre-protected mode enter LFB section pretty easily. The let-the-user-pick solution to the problem of finding a sane mode can even be done before entering protected mode, so that's not an excuse.
Having a framebuffer all to myself was one of the reasons I wanted to write an OS at all when I first started, and dread over the v86 shenanegans was one of the things that made me quit when I was a kid. I think just being able to have something to play around with would be very rewarding for a beginner and provide a base of knowledge upon which a more flexible v86-based driver can be built later on, so I might start writing a tutorial for exactly the aforementioned case when I get home.
Code: Select all
in order to boot with UEFI without sacrificing video mode independence
Also just curious about that, because I haven't experienced this on any of my testing hardware so far. Are you saying that the VESA calls return entries in the supported video modes list that can't actually be entered? Not being contrarian or anything, I'm honestly just curious if that's what the story is.The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes.
There is a VESA function to return the supported video modes, but some BIOSes will only report 4x3 resolutions like 640x480 and 800x600, even when used with an LCD-display that has another resolution, often wide-format or similar. This makes the display show non-quadratic pixels, which is a big problem.jojo wrote:Also just curious about that, because I haven't experienced this on any of my testing hardware so far. Are you saying that the VESA calls return entries in the supported video modes list that can't actually be entered? Not being contrarian or anything, I'm honestly just curious if that's what the story is.The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes.
Another thing is that the Linux documentation that Intel provides has 9 different sets of manuals for different processors. Does that mean I'll need to write 9 different drivers for the Intel GPU alone? Probably not, but organizing the documentation in a "common" part and "feature" part would be far better. As it is now, I have no idea if I need to write 9 different drivers to setup LFB or not.kzinti wrote:Even "just setup a LFB" is complicated and a lot of work. So no, there isn't a simple example and there won't ever be.rdos wrote:I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later?
I'm not going to argue with that. However, there was no way that a 32-bit VESA was going to come out at that point.tom9876543 wrote:VESA VBE 2.0 is unfortunately another example of a pathetic terrible API design.
Released, yes, but only after three years in committee - they were already discussing it when VESA 1.2 was released. In any case, in 1994 there were still a number of new XTs and 286s shipping (not many, but they were cheap and no one really thought Windows was here to stay), and plenty of used ones around as well. Backwards compatibility was, sad to say, a significant concern, even for a standard applying to new motherboards.tom9876543 wrote:VBE 2.0 was released in 1994.
It's only really obvious in hindsight. More people ran MS-DOS without Windows than with it even at that point (trust me on this - I had to grapple with maintaining some MS-DOS and Windows 3.1 systems through Y2K, and saw some DOS boxes limping along as late as 2005). Windows 3.1 was still a hybrid 16/32 bit system, with the 32 bit subsystem crudely bolted on and highly unstable. No one actually believed Windows 95 would ship in 1995 (it almost didn't), or be truly 32 bit (it wasn't, not yet anyway). OS/2 had an effective market share of zero, and was mainly a 16-bit p-mode OS at the time, anyway. While Lotus 1-2-3 required protected mode, it was still mostly geared towards 16-bit p-mode, too, and the 32-bit system they used didn't play well with Windows. As for DOS extenders, those applied only to games, and no one at the time really took PC gaming seriously - remember, the shareware preview version of DOOM was less than a year old at that point, and even game developers were still leery of anything that didn't run on 8088 systems.tom9876543 wrote:The world was obviously moving to 32bit protected mode.
IIRC, there were no PCI video cards until the middle of 1994, and they only came out because VLB had problems when used in Pentium systems. While PCI was developed in 1990 (as a response to MCA and the failure of EISA, both of which were almost forgotten about by 1994), it wasn't released until 1993, and it was originally designed (and used) for high-speed multi-Ethernet adapters - it was expected to be used exclusively on servers. The high-speed video standard at the time was VESA Local Bus, which was so dependent on the 80486 architecture that it broke when Pentiums came out, and had no ability to allow multiple video cards at all. When AGP (a modified version of PCI specifically for video cards, because PCI 1.0 was actually slower than VLB) came out a few years later, it didn't really support PCI bus mastering, either. Besides, most PCs still used ISA for video until around 1996 - only gamers would bother with an accelerated card, and gaming just wasn't seen as important by anyone who wasn't a gamer themselves.tom9876543 wrote:VBE 2.0 should of made it possible for multiple PCI video cards to operate independently, with a standard way to load their 32 bit code into the address space.