Eric Anholt writes:
> Keith Packard writes:
>
>> Michel Dänzer writes:
>>
>>> On 08.04.2014 17:13, Keith Packard wrote:
Michel Dänzer writes:
> Yes, that works fine now in Xephyr. The only remaining obvious problem
> there is the xfwm4 window decoration corruption regression
Keith Packard writes:
> Michel Dänzer writes:
>
>> On 08.04.2014 17:13, Keith Packard wrote:
>>> Michel Dänzer writes:
>>>
Yes, that works fine now in Xephyr. The only remaining obvious problem
there is the xfwm4 window decoration corruption regression from the
master branch.
>>
Michel Dänzer writes:
> On 08.04.2014 17:13, Keith Packard wrote:
>> Michel Dänzer writes:
>>
>>> Yes, that works fine now in Xephyr. The only remaining obvious problem
>>> there is the xfwm4 window decoration corruption regression from the
>>> master branch.
>>
>> Ok, looks like that's caused
On 08.04.2014 17:13, Keith Packard wrote:
> Michel Dänzer writes:
>
>> Yes, that works fine now in Xephyr. The only remaining obvious problem
>> there is the xfwm4 window decoration corruption regression from the
>> master branch.
>
> Ok, looks like that's caused by glamor re-using FBOs that wer
Michel Dänzer writes:
> Yes, that works fine now in Xephyr. The only remaining obvious problem
> there is the xfwm4 window decoration corruption regression from the
> master branch.
Ok, looks like that's caused by glamor re-using FBOs that were too large
for tile pixmaps. Oddly, the texture fetc
On Mon, 2014-04-07 at 23:36 -0700, Keith Packard wrote:
> Michel Dänzer writes:
>
> > E.g. the GtkComboBox test leaves artifacts outside of the gtkperf
> > window, or also just scrolling the gtkperf widget containing the test
> > results.
> >
> > I think at least part of the problem is using glCo
Michel Dänzer writes:
> The radeon driver doesn't use the glamor_*_nf() entrypoints, it leaves
> all the rendering and fallback handling to glamor.
Cool. That makes things more similar, unlike uxa which mixes glamor and
legacy rendering code in the same driver.
> E.g. the GtkComboBox test leave
On Die, 2014-04-01 at 16:01 -0700, Keith Packard wrote:
> Michel Dänzer writes:
>
> > Sounds great, but...
> >
> > Patch 11 breaks Xorg for me with radeonsi. It looks like solid fills are
> > basically not rendered at all anymore, so e.g. only the text is visible
> > in an xterm window. Then late
Michel Dänzer writes:
> Sounds great, but...
>
> Patch 11 breaks Xorg for me with radeonsi. It looks like solid fills are
> basically not rendered at all anymore, so e.g. only the text is visible
> in an xterm window. Then later patches make it even worse, resulting in
> just a black screen inste
Markus Wick writes:
> This patch series is a very nice cleanup. I like the new way how this
> functions should be implemented, but the shader generator. Plain GLSL +
> predefined header are less confusing and more flexible imo.
>
> We also have to figure out on which gl extension we want to rel
This patch series is a very nice cleanup. I like the new way how this
functions should be implemented, but the shader generator. Plain GLSL +
predefined header are less confusing and more flexible imo.
We also have to figure out on which gl extension we want to rely on. eg
I don't think we sho
On Die, 2014-03-18 at 22:09 -0700, Keith Packard wrote:
> This replaces all of the X core rendering code in glamor with shiny
> new stuff. This is the second time around for this code, it now passes
> the X test suite for Xlib chapter 9 (thanks to Eric's work making that
> run under piglit). And, i
This replaces all of the X core rendering code in glamor with shiny
new stuff. This is the second time around for this code, it now passes
the X test suite for Xlib chapter 9 (thanks to Eric's work making that
run under piglit). And, it also now runs correctly when debugging with
tiny FBOs tiling t
13 matches
Mail list logo
