On Mon, 03 Apr 2017, Russell King - ARM Linux wrote:
> So what the _hell_ do you think _this_ sentence means? It _was_ shared
> with you.
>
> The following series is what I came up with, although I've had no time
> to test it.
>
> which was in the mail which was the
On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > I sent a reminder on 20th February about it, and we discussed it, and I
> > said at the time I did not have time to test your patch. Ville commented
> > on
On Mon, Apr 03, 2017 at 02:13:48PM +0100, Russell King - ARM Linux wrote:
> On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > > I sent a reminder on 20th February about it, and we discussed it, and I
> > >
On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> > > > The
On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> The calculation of the framebuffer's start address was wrongly using
> the CRTC's x and y position rather than the one of the source
> framebuffer. To fix that we need to update the plane_check code to
> call
On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> > > The calculation of the framebuffer's start address was wrongly using
> > > the CRTC's x
On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> > The calculation of the framebuffer's start address was wrongly using
> > the CRTC's x and y position rather than the one of the source
> > framebuffer. To
The calculation of the framebuffer's start address was wrongly using
the CRTC's x and y position rather than the one of the source
framebuffer. To fix that we need to update the plane_check code to
call drm_plane_helper_check_state() to clip the src and dst coordinates.
While there so some minor