Re: nv driver obscurities...

2003-11-10 Thread Sven Luther
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...

2003-11-10 Thread Mike A. Harris
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...

2003-11-10 Thread Alex Deucher
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...

2003-11-10 Thread Stephen Hocking
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...

2003-11-10 Thread Mike A. Harris
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...

2003-11-10 Thread Sven Luther
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...

2003-11-10 Thread Alex Deucher
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...

2003-11-09 Thread Mike A. Harris
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...

2003-11-09 Thread Kevin Brosius
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...

2003-11-09 Thread Mike A. Harris
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...

2003-11-09 Thread Thomas Winischhofer
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...

2003-11-09 Thread Mike A. Harris
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...

2003-11-09 Thread Alex Deucher
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


nv driver obscurities...

2003-11-07 Thread Mike A. Harris
I'm curious about some of the obscurity in the nv driver.  In 
particular, almost everywhere in the driver, registers are 
addressed numerically, and not by symbolic names.  That on it's 
own is obscure enough to make things difficult to tell what's 
going on, but we know the deal with Nvidia documentation well 
enough, so I won't bother to worry about that much...

Various people have commented though about certian obscurities 
like the following being rather odd:

chip-Rop= (RivaRop   *)(chip-FIFO[0x/4]);

Why 0x/4 and not just plain 0x?  Everywhere 
in the driver hex values are given premultiplied by 4 it seems, 
and specified as VALUE/4.

Was that done just to intentionally obfuscate the driver source 
further?  Or was the original driver (or current driver for that 
matter) actually maintained elsewhere with real symbolic names 
and whatnot, and then obfuscation scripts ran over them prior to 
committing to the XFree86 tree?

Would cleanups that remove this obfuscation and make the driver 
more readable be considered useful, and potentially accepted?  Or 
is there some other reason I'm missing as to why the driver is so 
obfuscated?


-- 
Mike A. Harris

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: nv driver obscurities...

2003-11-07 Thread Mark Vojkovich
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