Re: nv driver obscurities...
On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Have you looked at the glint driver ? All the register are accessed using nice named macros, taken out of the corresponding documentation. Or are you speaking about another 3dlabs driver i don't know about ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. I'm not trying to fix a bug in the trident or 3dlabs drivers however. However, if I were, I also don't have hardware specs for trident or 3dlabs hardware, and as such, symbolic names would be easier to deal with in both of those, or any other video drivers as well. A moot point however I suppose, as none of those drivers is ever likely to have any major work done on them in the future other than by their respective existing driver maintainers. Let's hope and pray that none of the existing maintainers gets hit by a bus, or we're screwed. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. Alex --- Sven Luther [EMAIL PROTECTED] wrote: On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Have you looked at the glint driver ? All the register are accessed using nice named macros, taken out of the corresponding documentation. Or are you speaking about another 3dlabs driver i don't know about ? Friendly, Sven Luther __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Some time ago, there was a chap in New Zealand who was attempting to reverse engineer and documaent what all the nvidia registers did, -plus get DMA going for various ops. Google may turn up something - I don't have a URL to hand. The last I heard came from a couple of years back however. Stephen -- Experience is the name everyone gives to their mistakes - Oscar Wilde ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, 10 Nov 2003, Alex Deucher wrote: Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: nv driver obscurities... Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. That doesn't make it good practice. Symbolic names let people know what things are for, or provide clues at least. They also help to avoid many typo related problems. For example someone mistakenly saying 0x35c somewhere would much more easily go unnoticed than a symbolic name. That's why we have structured programming constructs such as macros to begin with - to make programming more readable and easier to understand. But obviously the point I'm trying to make is a debateable one, and I'm not going to change my mind on my thoughts regarding symbolic names, and I expect you and others aren't going to throw away years of programming and change your opinions either. We both now know what each other's opinions on the topic is, and that none of us are going to convince the other to change their opinion or their coding practices, so further discussion/debate is probably not useful as far as development is concerned. Let's just respectfully agree to disagree with each other on coding practice, and move on without further discussion. Thanks. Respectfully yours, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, Nov 10, 2003 at 06:38:24AM -0800, Alex Deucher wrote: Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. Maybe the old 3dlabs XFree86 3.3 server was in this case, but the glint driver has had nice symbolic names since a long time. 3Dlabs is even quite free in releasing full NDAed documentation, unlike other companies. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
I agree with you that symbolic names are better in just about all respects. I'm just saying that the nv driver is not the only one that doesn't do it. That's it for me. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: On Mon, 10 Nov 2003, Alex Deucher wrote: Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: nv driver obscurities... Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. That doesn't make it good practice. Symbolic names let people know what things are for, or provide clues at least. They also help to avoid many typo related problems. For example someone mistakenly saying 0x35c somewhere would much more easily go unnoticed than a symbolic name. That's why we have structured programming constructs such as macros to begin with - to make programming more readable and easier to understand. But obviously the point I'm trying to make is a debateable one, and I'm not going to change my mind on my thoughts regarding symbolic names, and I expect you and others aren't going to throw away years of programming and change your opinions either. We both now know what each other's opinions on the topic is, and that none of us are going to convince the other to change their opinion or their coding practices, so further discussion/debate is probably not useful as far as development is concerned. Let's just respectfully agree to disagree with each other on coding practice, and move on without further discussion. Thanks. Respectfully yours, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Fri, 7 Nov 2003, Mark Vojkovich wrote: Everywhere in the driver hex values are given premultiplied by 4 it seems, and specified as VALUE/4. The register pointers are dword pointers. The register offsets are byte offsets. They are written as VALUE/4 so that I can grep for VALUE. This is done so that it's easier for me to maintain. Converting everything to dword offsets will make my job more difficult. Ah, ok. I'm not sure why you are bringing this up. I'm bringing it up because I have no idea how Nvidia hardware works, have no Nvidia documentation, the source code of the driver is quite obfuscated by not using symbolic names for things, and that was one obfuscation that I thought might be something that could be cleaned up. Having no way of knowing why it is coded the way it is other than making a random guess, or by asking someone who does know, how is one supposed to find out why it is coded this way? I would think it would be obvious that since I am maintaining it, it would be in the form that is easiest for me to maintain. Sure, that works fine for me if that is the case, at least once it is known that there is a valid reason, and that it is done intentionally. But don't assume that I can mind read the intentions of an obfuscated driver. Would you prefer other developers and potential developers did not ask questions at all, and instead went off and worked on other projects? Seems every time someone asks for information on how something works in the codebase that they don't understand, or asks for clarification on something, they can't get a straight or clear answer. It's really no wonder volunteers get put off from contributing to the XFree86 project. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Mike A. Harris wrote: On Fri, 7 Nov 2003, Mark Vojkovich wrote: Everywhere in the driver hex values are given premultiplied by 4 it seems, and specified as VALUE/4. The register pointers are dword pointers. The register offsets are byte offsets. They are written as VALUE/4 so that I can grep for VALUE. This is done so that it's easier for me to maintain. Converting everything to dword offsets will make my job more difficult. Ah, ok. I'm not sure why you are bringing this up. I'm bringing it up because I have no idea how Nvidia hardware works, have no Nvidia documentation, the source code of the driver is quite obfuscated by not using symbolic names for things, and that was one obfuscation that I thought might be something that could be cleaned up. Having no way of knowing why it is coded the way it is other than making a random guess, or by asking someone who does know, how is one supposed to find out why it is coded this way? I would think it would be obvious that since I am maintaining it, it would be in the form that is easiest for me to maintain. Sure, that works fine for me if that is the case, at least once it is known that there is a valid reason, and that it is done intentionally. But don't assume that I can mind read the intentions of an obfuscated driver. Would you prefer other developers and potential developers did not ask questions at all, and instead went off and worked on other projects? Seems every time someone asks for information on how something works in the codebase that they don't understand, or asks for clarification on something, they can't get a straight or clear answer. It's really no wonder volunteers get put off from contributing to the XFree86 project. Well, gee, Mike... You're question was filled with negative assumptions about why the driver might be 'obfuscated'. You shouldn't take offense if Mark is a little short with you. Focus on asking a question, leaving off the insinuations, and you'll get better answers. A shorter question like I'd find it clearer if the nv driver used #defines for registers rather than hardcoded values. Does anyone object to changing it? would tend to go over smoother. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Kevin Brosius wrote: Well, gee, Mike... You're question was filled with negative assumptions about why the driver might be 'obfuscated'. You shouldn't take offense if Mark is a little short with you. Focus on asking a question, leaving off the insinuations, and you'll get better answers. A shorter question like I'd find it clearer if the nv driver used #defines for registers rather than hardcoded values. Does anyone object to changing it? would tend to go over smoother. I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. I suppose I should have thought my posting out more clearly before asking my original question. My response didn't take my original mail into account either, of which I had forgotten my wording. My apologies for the flame. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Mike A. Harris wrote: I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. Mike, I really can't imagine how symbolic names would help you if you don't have hardware docs. (Well, unless one uses names like BIT_7_IS_FOR_INTERLACE_BIT_6_IS_FOR_DOUBLESCAN_BITS_5_4_ARE) For me as a developer, if I have the choice between for example SetReg(Part2Port,0x43,0x27); or SetReg(Part2Port,RTVFILCNT,0x27); I will certainly go for the first variant. Datasheets usually are sorted by register number. Using the number instead of a name saves me from 1) remembering the symbolic name I or the datasheet gave the register (Was that with '_' or without in the middle? Did I use caps?), and 2) grepping BOTH the driver AND the datasheet (or my defs.h) every time I check or debug stuff. Just my humble $.2 Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Thomas Winischhofer wrote: I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. Mike, I really can't imagine how symbolic names would help you if you don't have hardware docs. (Well, unless one uses names like BIT_7_IS_FOR_INTERLACE_BIT_6_IS_FOR_DOUBLESCAN_BITS_5_4_ARE) For me as a developer, if I have the choice between for example SetReg(Part2Port,0x43,0x27); or SetReg(Part2Port,RTVFILCNT,0x27); I will certainly go for the first variant. Datasheets usually are sorted by register number. Using the number instead of a name saves me from 1) remembering the symbolic name I or the datasheet gave the register (Was that with '_' or without in the middle? Did I use caps?), and 2) grepping BOTH the driver AND the datasheet (or my defs.h) every time I check or debug stuff. Just my humble $.2 Having zero datasheet, but having symbolic names is more likely to give useful information than is 0x43. It isn't a substitute for full documentation by far, but it is better than nothing, especially if you are a volunteer trying to fix something for someone else, the more information you have the better. Using non symbolic names is like surfing the web with IP addresses only, the obvious difference to this analogy being that domain names don't always remain pointing to the same IP address. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: On Sun, 9 Nov 2003, Thomas Winischhofer wrote: I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. Mike, I really can't imagine how symbolic names would help you if you don't have hardware docs. (Well, unless one uses names like BIT_7_IS_FOR_INTERLACE_BIT_6_IS_FOR_DOUBLESCAN_BITS_5_4_ARE) For me as a developer, if I have the choice between for example SetReg(Part2Port,0x43,0x27); or SetReg(Part2Port,RTVFILCNT,0x27); I will certainly go for the first variant. Datasheets usually are sorted by register number. Using the number instead of a name saves me from 1) remembering the symbolic name I or the datasheet gave the register (Was that with '_' or without in the middle? Did I use caps?), and 2) grepping BOTH the driver AND the datasheet (or my defs.h) every time I check or debug stuff. Just my humble $.2 Having zero datasheet, but having symbolic names is more likely to give useful information than is 0x43. It isn't a substitute for full documentation by far, but it is better than nothing, especially if you are a volunteer trying to fix something for someone else, the more information you have the better. Using non symbolic names is like surfing the web with IP addresses only, the obvious difference to this analogy being that domain names don't always remain pointing to the same IP address. -- Mike A. Harris __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Fri, 7 Nov 2003, Mike A. Harris wrote: Everywhere in the driver hex values are given premultiplied by 4 it seems, and specified as VALUE/4. The register pointers are dword pointers. The register offsets are byte offsets. They are written as VALUE/4 so that I can grep for VALUE. This is done so that it's easier for me to maintain. Converting everything to dword offsets will make my job more difficult. I'm not sure why you are bringing this up. I would think it would be obvious that since I am maintaining it, it would be in the form that is easiest for me to maintain. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
