Hi Connor,
> What's wrong with keeping the two separate files? FWIW, I got the idea
> to do this from the mach64 driver.
I was trying to get rid of "#include "r128_exa.render.c" statement from
r128_exa.c.
Personally, I do not think it is desirable to include large number of lines of
code in the middle of the code by including a .c file.
I have never done such a practice, and I do not believe it is very common in
the industry.
If you can get rid of the "#include," and as a alternative, reference external
functions inside r128_exa_render.c, then I think it is okay.
I do not want to get into a turf war with you over code, but I have noticed
that development pace of r128 has slowed down considerably over the past 2
years.
While the development of OpenChrome I am involved with (and I am the only
developer for that matter) will continue indefinitely (for now), I have been
thinking of expanding my development coverage to DDXs other than OpenChrome.
Since I own several variations of RAGE 128, you added EXA support, and RAGE 128
Pro supports AGP 1.5V signaling, I feel like there are still some people out
there who might want the device driver stack to be developed further.
Since I was able to fix several bugs of OpenChrome, and was also able to added
new features (i.e., DVI support) to OpenChrome, I feel like I can help improve
other DDXs that have been neglected.
I will make it clear that I am not trying to remove you from r128 DDX
development.
The patch I submitted is sort of a test case to see if it will be feasible for
me to contribute to r128 DDX development.
Since all of my time I spent on improving OpenChrome has been to improve the
display device detection (there is more work to be done in this area), I will
like to apply this experience to r128 DDX.
I am also thinking of looking into the EXA rendering bug that persists in r128
DDX.
Regards,
Kevin Brace
_______________________________________________
xorg-driver-ati mailing list
[email protected]
https://lists.x.org/mailman/listinfo/xorg-driver-ati
