Ok this one includes all the minor feedback from last week, and should
satisfy Daniel and Jakob enough to get their Reviewed-bys.
You can ignore the final patch in the series; it's a WIP power saving
feature, but the other ones are working well here.
Thanks,
Jesse
___
On Thu, 3 Nov 2011 22:20:00 +
Alan Cox wrote:
> > We're talking about gpus, there's no way an application will talk to them
> > than through some nice cozy abstraction layer like OpenGl, X, ... Even
> > Wayland has gbm to do the low-level kms scanout allocation.
>
> You are talking about sca
On Thu, 3 Nov 2011 13:55:50 -0500
Rob Clark wrote:
> On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes
> wrote:
> > On Thu, 3 Nov 2011 18:29:14 +0100
> > Daniel Vetter wrote:
> >
> >> Hi all,
> >>
> >> I've discussed this a bit on irc and consensus seems to be "some ugliness
> >> due to interface
On Thu, Nov 03, 2011 at 05:47:43PM +, Alan Cox wrote:
> > In short decoding these fourcc values with all their implicit assumptions
> > about offset, strides and whatnotelse will be one giant switch mess. Not
> > my idea of a nice kernel interface. Also practically guaranteed to result
> > in s
On Thu, 3 Nov 2011 18:29:14 +0100
Daniel Vetter wrote:
> Hi all,
>
> I've discussed this a bit on irc and consensus seems to be "some ugliness
> due to interface impendance mistmatches in the kernel? who cares ...". I
> agree that there's not a fundamental problem with fourcc and planar yuv
> th
Hi all,
I've discussed this a bit on irc and consensus seems to be "some ugliness
due to interface impendance mistmatches in the kernel? who cares ...". I
agree that there's not a fundamental problem with fourcc and planar yuv
that can't be fixed with a bunch of boilerplate code with the assorted
On Thu, 3 Nov 2011 15:11:55 +0100
Daniel Vetter wrote:
> On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote:
> > In response to feedback, I've adjusted the new addfb2 ioctl to take per
> > component pitch and offset args. Generally, the offset[0] field will be
> > 0, but it's conceivab
On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote:
> In response to feedback, I've adjusted the new addfb2 ioctl to take per
> component pitch and offset args. Generally, the offset[0] field will be
> 0, but it's conceivable that some metadata could be stored at the start
> of a given b
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
Similarly
