• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Porting AbiWord

Started by miturbide, 2007.05.17, 04:26:53

Previous topic - Next topic

miturbide


Supporting thread for the Porting AbiWord bounty. The original and old bounty thread can be found here.

Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

demetrioussharpe

Quote from: miturbide on 2007.05.17, 04:26:53

Supporting thread for the Porting AbiWord bounty. The original and old bounty thread can be found here.



This is quite an old bounty, is it still wanted?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

melf

I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.
/Mikael

demetrioussharpe

Quote from: melf on 2011.05.11, 15:56:30
I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.

Must it use Odin? If it's possible to do a native version, is that acceptable?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Andi710

I guess everyone agrees that using ODIN is no benefit in itself and a native version would certainly be preferable. However, I wonder if one really urgently needs Abiword if a recent port of OOo and many good (though older) OS/2 native workd processors are around (like Describe, Papyrus etc.)

If looking for bounties, why don't you open a new one? I personally would rather be willing to sponsor something like an update to SNAP graphics driver to a selected number of current chipsets (1 desktop, 1 mobile). Including multiscreen cababilities and 2D acceleration, maybe rotation (even if not dynamic, as PM cannot chnge resolution on the fly).

demetrioussharpe

Quote from: Andi710 on 2011.05.11, 19:14:14
I guess everyone agrees that using ODIN is no benefit in itself and a native version would certainly be preferable. However, I wonder if one really urgently needs Abiword if a recent port of OOo and many good (though older) OS/2 native workd processors are around (like Describe, Papyrus etc.)

If looking for bounties, why don't you open a new one? I personally would rather be willing to sponsor something like an update to SNAP graphics driver to a selected number of current chipsets (1 desktop, 1 mobile). Including multiscreen cababilities and 2D acceleration, maybe rotation (even if not dynamic, as PM cannot chnge resolution on the fly).

Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread (http://www.os2world.com/forum/index.php/topic,1940.msg19520.html#msg19520) & the GL/2 page (http://svn.netlabs.org/gl2) to understand why.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

melf

Quote from: demetrioussharpe on 2011.05.11, 18:16:50
Quote from: melf on 2011.05.11, 15:56:30
I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.

Must it use Odin? If it's possible to do a native version, is that acceptable?

No this was not a wish, just a comment of maybe questionable value  ;)
/Mikael

Ben

Quote from: demetrioussharpe on 2011.05.11, 19:42:43
Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread ...to understand why.

That's interesting news indeed Dee.

From the other thread on this topic I thought that you were building, (GL/2 as), an addition to the video system, not a complete replacement.

Just how extensive is this?

...in layman's terms please... :)


demetrioussharpe

Quote from: Ben on 2011.05.11, 20:42:24
Quote from: demetrioussharpe on 2011.05.11, 19:42:43
Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread ...to understand why.

That's interesting news indeed Dee.

From the other thread on this topic I thought that you were building, (GL/2 as), an addition to the video system, not a complete replacement.

Just how extensive is this?

...in layman's terms please... :)



Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Ben

Quote from: demetrioussharpe on 2011.05.11, 21:01:32
Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.

OK.

If communications have been successful then you are telling me... us... that GL/2 is not a replacement for SNAP, (et al), in that they, (or anything equivalent, past, present or future), will be completely obsolete; Unnecessary.

So, OS/2 will no longer need video drivers from a card-specific  POV?

Is that correct?


demetrioussharpe

Quote from: Ben on 2011.05.11, 22:10:02
Quote from: demetrioussharpe on 2011.05.11, 21:01:32
Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.

OK.

If communications have been successful then you are telling me... us... that GL/2 is not a replacement for SNAP, (et al), in that they, (or anything equivalent, past, present or future), will be completely obsolete; Unnecessary.

So, OS/2 will no longer need video drivers from a card-specific  POV?

Is that correct?



Driver specific cards will still be necessary, but they won't be of the same type as SNAP or GRADD. They'll be 3D drivers, the api will be easier to cope with, & most of the data that's necessary for porting them could be taken directly from the DRI/DRM guys. Either way, driver development will be easier in any ways; but the benefits should dwarf all of the negatives.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

rudi

#11
Quote from: demetrioussharpe on 2011.05.11, 23:54:06
the api will be easier to cope with

How do you know ?

Quote from: demetrioussharpe on 2011.05.11, 23:54:06
most of the data that's necessary for porting them could be taken directly from the DRI/DRM guys

That's actually the crucial part. The important questions for me are:

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" ?

2.) Is this DRI/DRM API stable or will it change every two weeks or so ?

3.) Does DRI/DRM support a significant number of chipsets on the market ?

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 ?

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.

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.

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.

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.

demetrioussharpe

Quote from: rudi on 2011.05.16, 11:34:11
How do you know ?

Because, this isn't my first time writing drivers or using driver APIs.

Quote1.) 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.

Quote2.) 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.

Quote3.) 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.

Quote4.) 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.

Quote5.) 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.

QuoteGiven 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.

QuoteFurthermore: 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.

QuoteBTW, 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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

rudi

QuoteHmmm....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

You said that the old OS/2 video driver interface should become obsolete within a year. So let's see...

QuoteThe snapshot of SNAP that I've seen shows no indication of being a GRADD driver

SNAP divides the driver in an OS dependent part (the shell driver that on OS/2 is a GRADD) and a hardware dependent part contained in *.BPD files. BPD stands for "Binary Portable Driver", which means that these *.BPD files can be used unchanged on any OS that runs an x86 CPU and that has a matching shell driver. If you have only looked at the latter, then you clearly see no relationship to GRADD.

QuoteIt's still a crappy interface & it's not even the real OS/2 video driver interface, it's a wrapper

It may be crappy and it is a wrapper. However, the question (which I'm not answering) is whether it is good enough to reach the goal with minimal effort or if it is required to kick it out for real technical reasons.

QuoteWinOS2 is also a moot point

I said that I don't need it. But I cannot tell about others.

QuoteI've made my diagrams & source code freely available (which I didn't have to do)

If you want to get people involved, then you better do so.

QuoteIt seems as though you're sole purpose is to cast doubt on my work. If your goal is to troll ...

I'm trying to get an idea of what you are doing. But it looks like you only want replies from non-technical people that say: "Ohh, ahh - here comes the new Messiah".


demetrioussharpe

Quote from: rudi on 2011.05.17, 09:37:43
You said that the old OS/2 video driver interface should become obsolete within a year. So let's see...

Even if it takes longer than a year, at least I'm doing something about the situation, what're you doing?

QuoteSNAP divides the driver in an OS dependent part (the shell driver that on OS/2 is a GRADD) and a hardware dependent part contained in *.BPD files. BPD stands for "Binary Portable Driver", which means that these *.BPD files can be used unchanged on any OS that runs an x86 CPU and that has a matching shell driver. If you have only looked at the latter, then you clearly see no relationship to GRADD.

Are you dense? I never said that SNAP was a GRADD driver. Actually, I said the opposite. The only thing that SNAP & GRADD have in common is that they're wrappers around the true video driver interface. If you go back & reread what I wrote, you'll see where I wrote that "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", which was in response to you calling it a GRADD driver. Stop trying to put words in my mouth.

QuoteIt may be crappy and it is a wrapper. However, the question (which I'm not answering) is whether it is good enough to reach the goal with minimal effort or if it is required to kick it out for real technical reasons.

If you're not bothering to write any code that gives 3d support & makes 2d support rather trivial, why do you care either way? I could understand if you were planning on writing some code. It won't even matter if your goal was to start a project that rival's mine, at least you'd be doing something. At this point, you seem to be doing nothing but trying to shoot down someone who's bothered to actually do something about the current situation.

QuoteI said that I don't need it. But I cannot tell about others.

You brought it up, so I addressed it. Obviously, you brought it up for a reason, so don't get all butt-hurt when I address it.

QuoteIf you want to get people involved, then you better do so.

I really don't care if people get involved or not. I started the GL/2 project not expecting people to want to join. Let's be honest, this is the kind of work that no one really wants to do. If there were people who wanted to get involved on a coding level, a project would've been started before I started GL/2. I do my diagrams in order to keep people informed, so they don't think that the project's dead. The last thing we need is a project that raises up people's hopes, & then dies out.

QuoteI'm trying to get an idea of what you are doing. But it looks like you only want replies from non-technical people that say: "Ohh, ahh - here comes the new Messiah".

Cut the BS. If you really want to get a true idea of what I'm doing then visit the project page, look at the code in the svn repo, read & chat on the OpenGL ddk thread, hell you can even email me personally. That's how you get an idea of what I'm doing. Attacking me is NOT the way to get an idea of what I'm doing. Trying to make it look as though I don't know what I'm talking about is the surefire way to piss me off. If you have real questions or something useful to contribute, then I'm here & I'm willing to talk about it; I'm really not a bad guy. But I have very short patience for being pissed on. I'm not the new Messiah, I never claimed to be. I'm just a guy who's sick & tired of things being the way they are & opted to sit down & start writing code, instead of bitching & moaning about it. If you're so technical & all-knowing, what are you contributing to the fight?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!