| Age | Commit message (Collapse) | Author |
|---|
|
Several targets may want to reuse this code. It's pretty simple, not
sure if this is really a win.
|
|
Several software rasterizers can make use of this winsys, but there
isn't any reason why the winsys itself should know about them.
This change moves that information into the libgl-xlib target.
Need to fix up other targets making use of this winsys.
|
|
No need for the user of this winsys to supply/manage the x11 gc for
us.
|
|
Just use flush_frontbuffer directly. The flush_frontbuffer routine has
been somewhat devalued recently, but it is actually just the right
interface for our needs.
It is in pipe_screen, meaning that any wrapping (eg trace module)
will get properly unwrapped before we try and use the pipe_surface
argument for real.
If a particular co-state-tracker needs to implement this itself, it
should organize a way to allow the winsys to call back up to its
level, rather than hijacking the driver-supplied implementation.
|
|
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
|
|
Introduce xlib_drawable struct, pass this down to winsys instead of
having it use the internal data structures from glx/x11
|
