Hi,
On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote:
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > that was part of the reason to punt this problem to userspace ;-)
> >
> > In practice, the kernel drivers doesn't usually know too much about
> > the
Hi,
On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote:
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com
wrote:
that was part of the reason to punt this problem to userspace ;-)
In practice, the kernel drivers doesn't usually know too much about
the
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote:
>
>> > Turning to DRM/KMS, it seems the supported formats of a plane can be
>> > queried using drm_mode_get_plane. However, there doesn't seem to be a
>> > way to query the supported formats of a crtc? If display HW only
>> > supports scanning
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey tom.cook...@arm.com wrote:
Turning to DRM/KMS, it seems the supported formats of a plane can be
queried using drm_mode_get_plane. However, there doesn't seem to be a
way to query the supported formats of a crtc? If display HW only
supports
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz john.stu...@linaro.org wrote:
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark robdcl...@gmail.com wrote:
well, let's divide things up into two categories:
1) the arrangement and format of pixels.. ie. what userspace would
need to know if it mmap's a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey tom.cook...@arm.com wrote:
Didn't you say that programmatically describing device placement
constraints was an unbounded problem? I guess we would have to
accept that it's not possible to describe all possible constraints
and instead find a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey tom.cook...@arm.com wrote:
Didn't you say that programmatically describing device placement
constraints was an unbounded problem? I guess we would have to
accept that it's not possible to describe all possible constraints
and instead find a
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>>
>>> > So in some respects, there is a constraint on how buffers which will
>>> > be drawn to using the GPU are allocated. I don't really like the idea
>>> > of teaching the display controller
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey wrote:
>
>> >> ... This is the purpose of the attach step,
>> >> so you know all the devices involved in sharing up front before
>> >> allocating the backing pages. (Or in the worst case, if you have a
>> >> "late attacher" you at least know when no
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach wrote:
> I strongly disagree with exposing low-level hardware details like tiling
> to userspace. If we have to do the negotiation of those things in
> userspace we will end up with having to pipe those information through
> things like the wayland
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
>> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
>> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> >> Hi Rob,
>> >>
>> >> +lkml
>> >>
>> >> > >> On Fri, Jul
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> >> > We may also then have additional constraints when sharing buffers
>> >> > between the display HW and video decode or even camera ISP HW.
>> >> > Programmatically describing buffer allocation constraints is very
>> >> >
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> >> Hi Rob,
> >>
> >> +lkml
> >>
> >> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> > >> wrote:
> >> > >>
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> Hi Rob,
>>
>> +lkml
>>
>> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> > >> wrote:
>> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
>> > >> >>
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> Hi Rob,
>
> +lkml
>
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> > >> >> >also allocate buffers for the GPU. Still not sure how
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>
>> > So in some respects, there is a constraint on how buffers which will
>> > be drawn to using the GPU are allocated. I don't really like the idea
>> > of teaching the display controller DRM driver about the GPU buffer
>> > constraints, even
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey tom.cook...@arm.com wrote:
So in some respects, there is a constraint on how buffers which will
be drawn to using the GPU are allocated. I don't really like the idea
of teaching the display controller DRM driver about the GPU buffer
constraints,
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
Hi Rob,
+lkml
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com
wrote:
* It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
also allocate buffers for the GPU. Still not sure how to
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach l.st...@pengutronix.de wrote:
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
Hi Rob,
+lkml
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com
wrote:
* It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach l.st...@pengutronix.de wrote:
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
Hi Rob,
+lkml
On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey tom.cook...@arm.com wrote:
Hi Rob,
We may also then have additional constraints when sharing buffers
between the display HW and video decode or even camera ISP HW.
Programmatically describing buffer allocation constraints is very
difficult
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach l.st...@pengutronix.de wrote:
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach l.st...@pengutronix.de wrote:
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
Hi Rob,
+lkml
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach l.st...@pengutronix.de wrote:
I strongly disagree with exposing low-level hardware details like tiling
to userspace. If we have to do the negotiation of those things in
userspace we will end up with having to pipe those information through
things
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey tom.cook...@arm.com wrote:
... This is the purpose of the attach step,
so you know all the devices involved in sharing up front before
allocating the backing pages. (Or in the worst case, if you have a
late attacher you at least know when no
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark robdcl...@gmail.com wrote:
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey tom.cook...@arm.com wrote:
So in some respects, there is a constraint on how buffers which will
be drawn to using the GPU are allocated. I don't really like the idea
of teaching
28 matches
Mail list logo