This question is one I posed to the Intel Embedded support system about a year ago - that Intel just now noticed. The problem is still relevant to me, but I'm going to post my question verbatim, below, because after a year and dealing with two other platforms I'm not entirely clear on all of the issues I had at the time. Hopefully by the time someone answers I will be refreshed again...
"To set the background, I am aware that Intel is providing binary-only "driver" libraries to control the EMGD graphics hardware. I'm not disputing this decision.
I've obtained the EMGD linux distribution for my target hardware from Timesys, the distribution that Intel contracted to have created. I retrieved the source for that distribution and have ported everything that I can to the latest software versions (e.g. porting the Intel driver to work with the 4.x series kernel). The one package that I'm having issues with is Mesa. The source for the version of Mesa that's being linked to the binary-only libraries I mentioned, above, is not included in the source RPMs. As a result, I don't have anything to port to the later version of Mesa.
I'm not after proprietary information. It's clear from the output binary that the Mesa package source is being linked to the pre-compiled EMGD binary libraries. I don't want the source to the EMGD binary libraries; I really could use the Mesa source that was modified to link to those EMGD libraries, though. "
I think my issue was that the version of Xorg required to support the ancient (2010) version of Mesa is also rather ancient (Xorg ABI version 8). Getting the modified Mesa source would allow me to port the changes to support the EMGD driver libraries to a later version of Mesa and get my platform up to a reasonably current version of Xorg. My platform sports an E680 Atom processor.
Any thoughts on the availability of the Mesa source code would be greatly appreciated.
Thank you for contacting Intel Embedded Community.
We are working to give you the information that may help you as soon as possible.
Thanks for your patience and understanding.
Thank you for your response. Obviously, finding out that our fielded hardware is obsolete and entirely unsupported is quite disappointing, but at least that is now clear. When the time comes for a hardware update, now seeming to be necessary sooner rather than later, I shall suggest choosing an architecture that can be better supported in-house.