[PATCH] Merging Render code into r128_exa.c
Kevin Brace
kevinbrace at gmx.com
Mon Aug 22 07:27:23 UTC 2016
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
More information about the xorg-driver-ati
mailing list