How do you know ?
Because, this isn't my first time writing drivers or using driver APIs.
1.) Is DRI/DRM considered as something that is going to stay alive for while or is there a chance that in a half year the Linux guys find something else more "kewl" ?
It doesn't matter if they switch to something else or not, the code that's available is still available regardless of their API. GL/2 isn't a DRI/DRM interface. DRI/DRM is just where current drivers already exist, so if there's something that needs to be researched where else would you expect to look??? Besides, it's not just the Linux guys who use DRI/DRM, other (less volitile) *nix derivatives also use it.
2.) Is this DRI/DRM API stable or will it change every two weeks or so ?
Once again, it doesn't matter. The code that we need isn't in the driver API, it's in the parts of the driver that actually do the setup & rendering.
3.) Does DRI/DRM support a significant number of chipsets on the market ?
Significantly more with 3d acceleration than we currently support right now, considering that we currently have ZERO hardware 3d acceleration. And why would 3d acceleration be so important compared to the 2d acceleration that we have partial support for? Because the 2d drawing can be subsumed by the 3d support.
4.) Is the majority of source code for DRI/DRM available or is it usual that hardware vendors deliver the most interesting parts in form of object files only ?
Available. The only major vendor not supporting it is nVidia & that's 1 vendor out of 3 major vendors. With the other 2 major vendors being AMD & Intel, we're still doing pretty good with the number of available devices.
5.) Is DRI/DRM tightly integrated into the Linux/Unix or whatever OS it was originally developed for ? I.e. does it use features that the OS/2 kernel does not support and that are hard / impossible to implement correctly.
Moot point, GL/2 isn't DRI/DRM & never will be.
Given the limited human resources we have, the original source code (Linux ?) should be compilable for OS/2 without major changes. IMHO, just using the source code as reference documentation to write specialized OS/2 drivers is still too much effort.
Hmmm....the old 'it's too hard' complaint. It's funny how you're complaining, but I'm the one who's actually writing the code.
Furthermore: why do you want to replace the GRADD architecture ? Both, SNAP and Panorama are GRADDs themselves. Why can't your proposed "2D Driver/GL Client" be a GRADD as well ? If you drop GRADD, you either have to also drop WINOS2 (not a problem for me, but others might feel different) or create a separate "GL Client" for this.
The snapshot of SNAP that I've seen shows no indication of being a GRADD driver. Actually, it seems to be quite the opposite, though I could be wrong. And even if it was a GRADD driver, so what? It's still a crappy interface & it's not even the real OS/2 video driver interface, it's a wrapper. How do I know? Because I have the 2d driver DDK that IBM released initially & it covers both GRADD & the original video drivers. Also, no my 2D Driver/GL Client isn't a GRADD driver, it's based on the real IBM video driver interface, which GRADD is a wrapper around. WinOS2 is also a moot point. Look, it's time to move on out of the 90's. We have to be willing to advance. Honestly, WinOS2 is a henderance anyway & needs to be replaced with full Win32 & Win64 replacements. And even if those replacements aren't available for quite some time. It's not even an issue, since the compositing layer is supposed to be able to support multiple clients. It's not really an issue to add a client for the WinOS2 subsystem. Sure, it's hard to get people to do the work, but stop trying to piss on the one's who're actually doing it. Or you'll find yourself left in the past, like the last version of OS/2 that was produced & sold by IBM.
Furthermore, I'm going to need you to pay more attention to what's going on. It's not as if all of the info isn't out there available. Also, I've made my diagrams & source code freely available (which I didn't have to do). I also make a serious effort to give updates in the OpenGL DDK thread. If you disagree with my plans, then fine; but if you're not doing something to help progress things, then get out of the way.
BTW, your drawings suggest, that PMGRE.DLL calls into GRADD.SYS. That's not true. PMGRE.DLL (which is only a forwarder into PMMERGE) doesn't know anything about GRADD.SYS. This driver is just a helper for VMAN.DLL, which provides services (map memory, set MTRRs) to the GRADDs (SDDGRADD, VBE2GRAD, GENGRADD, MGAGRADD, M64GRADD, S3GRADD etc..) and controls their loading. These services could even be used by the 3D driver, given that I see no reason why it can't be a GRADD as well that just provides a different set of functionality. The PM "display driver" used by any GRADD-based system is GRE2VMAN.DLL, which is actually a rather thin translation layer between PM's GRE functions and the GRADD/VMAN API. In order to support WINOS2, there are two other translation layers - one for seamless and one for fullscreen windows sessions - so that in the end all drawing goes through the same unified interface defined by GRADD. This includes the possibility for a GRADD driver not to implement certain functionality and let the framework emulate it by means of SOFTDRAW.DLL.
Ok, let me stop you right here. First, if I had every single part of the GRADD architecture listed, I'd end up with a diagram that's far too complicated. You may not realize it, but I draw these diagrams in MS Paint. MS PAINT!!! How detailed would you expect a diagram to be when it's created in MS Paint??? My diagram gives an overall picture of what's going on. It doesn't matter if GRADD.SYS is communicated to directly by the PM graphics engine. The point is, by the time it's all said & done, the rendering ends up in the GRADD subsystem. And if you didn't know, VMAN.DLL & GRE2VMAN.DLL are both part of the GRADD subsystem & as are the list of backend drivers that you've listed (SDDGRADD, VBE2GRAD, GENGRADD, MGAGRADD, M64GRADD, S3GRADD etc..)
I know that I don't know everything about graphics, but I know my shit. It sounds like you're too close to the code, so much to the point that you're in love with it. Well, guess what? Unless you're going to write an advanced rendering system for OS/2 to push it into the future, sit down & shut it. It's hard enough to work on such a task without people (who're doing nothing) trying to tell me why my path is doomed or that I don't know what I know. Has it ever occurred to you to just see where this is all going? I mean, you're sitting here wasting time asking me about stuff that I've already put out in a forum thread that's already created for this particular subject. It seems as though you're sole purpose is to cast doubt on my work. If your goal is to troll, then do so elsewhere, the OS/2 community is already beaten & battered enough. We don't need any more torment & FUD.