I did some work with that screen a while back https://communities.intel.com/message/224883#224883
This was with gen 1, and some early firmware.
While I was able to get it working with the adafruit graphics library I really concentrated on having it available on Xorg.
Again I have done some work to make it work with the Edison and have versions of code that runs under Arduino IDE as well as code that runs native using compile tools on the board....
I have also have done a little testing on the galileo gen 2, and I know the Arduino version runs (not terribly quick, but...)
More details on the thread: Support for the Adafruit 2.8" TFT display for Arduino Edison
I have a 2.8" TFT display connected to a Galileo Gen2. I was initially really discouraged, because the performance of the graphicstest sketch was truly miserable.
I spent the day with this display today, seeing how far I could take graphics performance. Relative to the Intel-tweaked Adafruit_ILI9341 driver, I got between 100-900x speedups, which was heartening. My initial gains were thanks to KurtE's tweaks, mostly reducing the clock divider.
Additionally, I implemented a buffered version of the Adafruit_ILI9341 class, writing to a dynamically allocated framebuffer, and only presenting the buffer at the end of each test. I'm a software guy, so I was seeking the wins where I could get them. This greatly reduced the number of SPI calls, which makes a difference when you're setting a lot of pixels individually. I copy the framebuffer five rows at a time, nearly maxxing out the 4KB transferBuffer limit. If I could bump that up to 160KB, I could reduce the number of SPI calls by another factor of ~40, which might bring us into the realm of real-time rendering.
For posterity, here are the timings I got with my tests today (all in microseconds). Note that the Buffered times are utterly dominated by the transferBuffer calls, which take 90% of the frame time.
Intel KurtE Buffered Screen fill 192774651 4730677 1825354 Text 9455304 12460079 362628 Lines 90336688 125691539 367325 Horiz/Vert Lines 15708956 1074873 362216 Rectangles (outline) 10014384 1360335 382467 Rectangles (filled) 400070832 10033802 415219 Circles (filled) 55819941 55064526 366767 Circles (outline) 39522608 55042394 363256 Triangles (outline) 28696613 39951955 362937 Triangles (filled) 129806966 25068099 375621 Rounded rects (outline) 18880964 17110463 362374 Rounded rects (filled) 434623160 22428444 410756
The takeaway for me is that Galileo is harshly bandwidth-limited over the SPI interface, but with careful management of calls, you can use this display in applications that don't require real-time responsiveness.
Source is here: https://github.com/warrenm/Adafruit_ILI9341
I don't think it'll merge cleanly with anyone else's fork, but the code is extremely straightforward, if you should care to add buffering capabilities to an existing Adafruit_GFX subclass.