Hi Hans,
On Thursday 07 June 2012 11:13:30 Hans Verkuil wrote:
> Hi Laurent!
>
> I completely missed this when you posted this a week ago, but thank you for
> doing this. One suggestion: cross-post the next version to linux-media as
> well: I think this is useful for V4L2 as well.
I didn't think
From: M?rton N?meth
The field obejct_idr of struct drm_via_private was introduced with the
commit
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc
.
In that patch idr_init(&dev->object_name_idr) was called instead of
idr_init(&
On 10.06.2012 21:22, Alex Deucher wrote:
> On Sun, Jun 10, 2012 at 11:59 AM, Rafa? Mi?ecki wrote:
>> After recent changes HDMI code is ready to be enabled on DCE5. This
>> patch just changes conditions to execute already present code on DCE5.
>>
>> Signed-off-by: Rafa? Mi?ecki
>> ---
>> Dave: I kn
Hi Tomasz,
On Friday 08 June 2012 16:31:31 Tomasz Stanislawski wrote:
> Hi Laurent and Subash,
>
> I confirm the issue found by Subash. The function vb2_dc_kaddr_to_pages does
> fail for some occasions. The failures are rather strange like 'got 95 of
> 150 pages'. It took me some time to find the
From: Márton Németh
The field obejct_idr of struct drm_via_private was introduced with the
commit
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc
.
In that patch idr_init(&dev->object_name_idr) was called instead of
idr_init(&
2012/6/10 Christian König :
> On 10.06.2012 21:22, Alex Deucher wrote:
>>
>> On Sun, Jun 10, 2012 at 11:59 AM, Rafał Miłecki wrote:
>>>
>>> After recent changes HDMI code is ready to be enabled on DCE5. This
>>> patch just changes conditions to execute already present code on DCE5.
>>>
>>> Signed-
2012/6/10 Rafa? Mi?ecki :
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafa? Mi?ecki
> ---
> Dave: I know it's common to accept patches adding IDs even while merge
> window's closed
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.
Signed-off-by: Rafa? Mi?ecki
---
Dave: I know it's common to accept patches adding IDs even while merge
window's closed. Is this OK for you to take this patch
On Sun, Jun 10, 2012 at 11:59 AM, Rafa? Mi?ecki wrote:
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafa? Mi?ecki
> ---
> Dave: I know it's common to accept patches adding IDs even
On 10.06.2012 21:22, Alex Deucher wrote:
On Sun, Jun 10, 2012 at 11:59 AM, Rafał Miłecki wrote:
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.
Signed-off-by: Rafał Miłecki
---
Dave: I know it's common t
https://bugs.freedesktop.org/show_bug.cgi?id=35622
Christopher Egert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sun, Jun 10, 2012 at 11:59 AM, Rafał Miłecki wrote:
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafał Miłecki
> ---
> Dave: I know it's common to accept patches adding IDs even
Hi,
I'm currently trying to make use of OML_sync_control extension to schedule
presentation of video frames in xbmc.
I've run into somewhat of a snag. It seem the spec doesn't specify what
time the UST clock really is, nor can i find any mention of it elsewhere
in docs.
Code wise it seem to be
Hi
The recently added gbm gallium target
(./src/gallium/targets/gbm/gbm.c) requires HAVE_DRM_PIPE_LOADER for
pipe_loader_drm_probe(). Otherwise, the compiler fails with an
unresolved function-name.
However, HAVE_DRM_PIPE_LOADER is not defined when compiling i915 only,
so I need to compile gallium
2012/6/10 Rafał Miłecki :
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafał Miłecki
> ---
> Dave: I know it's common to accept patches adding IDs even while merge
> window's closed
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.
Signed-off-by: Rafał Miłecki
---
Dave: I know it's common to accept patches adding IDs even while merge
window's closed. Is this OK for you to take this patch
https://bugs.freedesktop.org/show_bug.cgi?id=35622
Christopher Egert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi,
I'm currently trying to make use of OML_sync_control extension to schedule
presentation of video frames in xbmc.
I've run into somewhat of a snag. It seem the spec doesn't specify what
time the UST clock really is, nor can i find any mention of it elsewhere
in docs.
Code wise it seem to be
On Fri, Jun 8, 2012 at 3:56 PM, Erik Gilling wrote:
>> I guess my other thought is that implicit vs explicit is not
>> mutually exclusive, though I'd guess there'd be interesting
>> deadlocks to have to debug if both were in use _at the same
>> time_. :-)
>
> I think this is an approach worth inve
Hi
The recently added gbm gallium target
(./src/gallium/targets/gbm/gbm.c) requires HAVE_DRM_PIPE_LOADER for
pipe_loader_drm_probe(). Otherwise, the compiler fails with an
unresolved function-name.
However, HAVE_DRM_PIPE_LOADER is not defined when compiling i915 only,
so I need to compile gallium
20 matches
Mail list logo
