Re: [Xorg] Introduce DRI_VERSION?
On Sun, Jun 20, 2004 at 11:27:56AM -0700, Eric Anholt wrote: > On Sun, 2004-06-20 at 11:17, Ian Molton wrote: > > On Thu, 17 Jun 2004 11:00:33 -0700 > > Alan Coopersmith <[EMAIL PROTECTED]> wrote: > > > > > The big dri merge seems a good time to label snapshot 6.7.0.90 or > > > however we want to start identifying the pre-6.7.1 snapshots. (How > > > do we want to do that?) > > > > that .90 numbering is hideous. whats wrong with -preX ? > > Yeah, here's a vote for that, as well. And for tarring a snapshot at > this point, if we could. It doesn't fit into x.y.z.a, that's why. Internally, KDE at least maps its versions to numbers (e.g. 3.0a1 -> 2.99.1/029901). Also sucks for us packagers (2.9+3.0alpha1 as version numbers are horrific, and this braindamage is all through Debian). I see the argument for it, but the argument against is compelling; in this case we need numeracy anyway, so we might as well shoot for consistency. -- Daniel Stone<[EMAIL PROTECTED]> freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
Re: [Xorg] Introduce DRI_VERSION?
On Sun, 2004-06-20 at 11:17, Ian Molton wrote: > On Thu, 17 Jun 2004 11:00:33 -0700 > Alan Coopersmith <[EMAIL PROTECTED]> wrote: > > > The big dri merge seems a good time to label snapshot 6.7.0.90 or > > however we want to start identifying the pre-6.7.1 snapshots. (How > > do we want to do that?) > > that .90 numbering is hideous. whats wrong with -preX ? Yeah, here's a vote for that, as well. And for tarring a snapshot at this point, if we could. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
On Thu, 17 Jun 2004 11:00:33 -0700 Alan Coopersmith <[EMAIL PROTECTED]> wrote: > The big dri merge seems a good time to label snapshot 6.7.0.90 or > however we want to start identifying the pre-6.7.1 snapshots. (How > do we want to do that?) that .90 numbering is hideous. whats wrong with -preX ? --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? The big dri merge seems a good time to label snapshot 6.7.0.90 or however we want to start identifying the pre-6.7.1 snapshots. (How do we want to do that?) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas Thomas, Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. Again: What I suggest has nothing to do with binary compatibility. It is just for compiling one and the same DDX code with different DRI versions. However, I understand that this is something not many would need. Perhaps I am just too kind to people stuck with Debian stable (XFree86 4.1)...? ;) > As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? Erm got me, didn't consider that. Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? Yes, sure. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle -> drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Jens Owen wrote: Thomas Winischhofer wrote: If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? I guess I'm not sure what the point is. Adding that define to xf86drm.h would let you know that you should be using structures from drm.h that have *always* existed. Given that the structures have always existed in drm.h with the same binary format as the ones in xf86drm.h (which is the whole reason for the changes!), there's no reason to have any '#ifdef OLD_XF86DRM_H' stuff in the code. Just new the structures from drm.h and be done with it. Code using the structures from drm.h will compile no matter what version of xf86drm.h is being used. Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? None of these changes should have anything to do with binary compatibility. The only changes that have been made (so far) to xf86drm.h affect source-level compatibilty. When the changes are made that affect binary compatibility on LP64 systems, they will be no source-level compatibility problems. That's why things are being done in the order that they're being done. :) --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Jens Owen wrote: Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle -> drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas Thomas, Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle -> drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
