On Wed, Mar 23, 2011 at 6:30 AM, Keith Packard kei...@keithp.com wrote:
On Tue, 22 Mar 2011 10:27:13 +1000, Dave Airlie airl...@gmail.com wrote:
My first solution involves throwing the XFree86 DDX out and starting
again, but this didn't seem like it would be acceptable.
Yeah, wrecking every
On Wed, Mar 23, 2011 at 6:39 PM, Keith Packard kei...@keithp.com wrote:
On Wed, 23 Mar 2011 16:03:59 +1000, Dave Airlie airl...@gmail.com wrote:
All it does is split the protocol screen struct out from the screen struct
and reworks the code to get the screen struct via the protocol screen
in
On Wed, 23 Mar 2011 20:30:21 +1000, Dave Airlie airl...@gmail.com wrote:
Yeah I was trying to get there in easier proveable steps.without doing
a big change.
I was hoping that splitting the data out into the protocol screen would
be a pretty simple step; DDX bits using those fields would get
On Tue, 22 Mar 2011 10:27:13 +1000
Dave Airlie airl...@gmail.com wrote:
So I've been trying to work out how to add GPU offload support to the
X server in some sort of useful fashion.
Currently the prototype, just creates two screens, one for each GPU,
and does some DRI2 magic to make the
Yuck... yeah tying this into the DDX looks ugly no matter what. Maybe
you should just punt and support it under Wayland only. :)
What does this look like from the app side? How does a given app end
up running on the offload GPU? Is there a GLX or EGL extension that
adds bits to the config
So I've been trying to work out how to add GPU offload support to the
X server in some sort of useful fashion.
Currently the prototype, just creates two screens, one for each GPU,
and does some DRI2 magic to make the front buffer shared.
However this leads to a lot of uglies on the protocol end,
