Hi, Laurent-san
I tested this patch by kms-tests scripts and modetest on R-Car Gen3.
On 2022/06/10 8:55, Laurent Pinchart wrote:
There's no reason to require the primary plane to always be at the
bottom of the stack, as the VSP supports arbitrary ordering of planes,
and the KMS API doesn't have
Hello Laurent-san
Thank you for your reviews and advices.
I'll fix this patch series following your advice.
Thanks,
Esaki
On 2022/01/24 7:50, Laurent Pinchart wrote:
Hello Esaki-san,
On Fri, Jan 14, 2022 at 07:17:51PM +0900, Tomohito Esaki wrote:
If only linear modifier is advertised, since
On 2022/01/18 18:53, Andy Shevchenko wrote:
On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
On 2022/01/14 23:16, Andy Shevchenko wrote:
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't sp
Thank you for your reviews.
On 2022/01/14 23:16, Andy Shevchenko wrote:
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
...
+ const uint64_t default_modifiers[] = {
+ DRM_
Thank you for your reviews.
On 2022/01/15 1:50, Daniel Vetter wrote:
On Wed, Dec 22, 2021 at 02:27:25PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers. However, there are legacy drivers such as radeon that do not
support modifiers
Hi,
Thank you for your comment.
On 2022/01/14 2:56, Bas Nieuwenhuizen wrote:
I think we'll also want to do a conditional disable for DC
(drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c) since it only
enables modifiers on newer HW. Something like "if (modifiers == NULL)
fb_modifiers_not_suppo
Hi Daniel-san,
Thank you for your comments.
On 2022/01/13 22:44, Daniel Stone wrote:
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the
Hi, Simon
On 2022/01/06 8:57, Simon Ser wrote:
Thanks for working on this! I've pushed a patch [1] to drm-misc-next which
touches the same function, can you rebase your patches on top of it?
[1]: https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
I understand. I will rebase th
Hi Daniel-san,
On 2021/11/30 22:20, Daniel Stone wrote:
On Tue, 30 Nov 2021 at 08:44, Esaki Tomohito wrote:
On 2021/11/18 23:05, Laurent Pinchart wrote:
On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote:
Laurent's concern is that the DRM core should handle this rather than
, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote:
On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote:
Weston compositor (v5.0.0 or later) uses the DRM API to get the
supported modifiers and determines if the sprite plane can be used by
comparing the modifiers with the client
12:32, Laurent Pinchart
wrote:
On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote:
On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote:
Weston compositor (v5.0.0 or later) uses the DRM API to get the
supported modifiers and determines if the sprite plane can be used by
comp
On 2021/06/23 20:41, Pekka Paalanen wrote:
> On Wed, 23 Jun 2021 18:22:47 +0900
> Esaki Tomohito wrote:
>
>> On 2021/06/23 17:39, Pekka Paalanen wrote:
>>> On Wed, 23 Jun 2021 15:56:05 +0900
>>> Esaki Tomohito wrote:
>>>
>>>> Hi,
>
On 2021/06/23 17:39, Pekka Paalanen wrote:
> On Wed, 23 Jun 2021 15:56:05 +0900
> Esaki Tomohito wrote:
>
>> Hi,
>> Thank you all for your comments.
>>
>> On 2021/06/22 17:12, Pekka Paalanen wrote:
>>> On Tue, 22 Jun 2021 13:03:39 +0900
>>> Es
On 2021/06/23 17:04, Michel Dänzer wrote:
> On 2021-06-22 9:57 a.m., Pekka Paalanen wrote:
>> On Tue, 22 Jun 2021 13:02:59 +0900
>> Esaki Tomohito wrote:
>>
>>> Hi, Thomas
>>> Thank you for reply.
>>>
>>> On 2021/06/21 16:10, Thomas
Hi,
Thank you all for your comments.
On 2021/06/22 17:12, Pekka Paalanen wrote:
> On Tue, 22 Jun 2021 13:03:39 +0900
> Esaki Tomohito wrote:
>
>> Hi, Enrico Weigelt
>> Thank you for reply.
>>
>> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote:
>
Hi, Maxime
Thank you for reply.
On 2021/06/21 18:24, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jun 21, 2021 at 09:10:19AM +0200, Thomas Zimmermann wrote:
>> Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
>>> Virtual DRM splits the overlay planes of a display controller into multiple
>>> virtual device
Hi, Rob
Thank you for the error report and advice.
I will recheck DT binding.
Best regards
Tomohito Esaki
On 2021/06/22 2:40, Rob Herring wrote:
> On Mon, 21 Jun 2021 15:44:02 +0900, Tomohito Esaki wrote:
>> Add device tree bindings documentation for virtual DRM.
>>
>> Signed-off-by: Tomohito Es
Hi, Sam
Thank you for looking at the details.
I will fix it according to your comment.
Best regards
Tomohito Esaki
On 2021/06/22 0:55, Sam Ravnborg wrote:
> Hi Tomohito
>
> On Mon, Jun 21, 2021 at 03:44:00PM +0900, Tomohito Esaki wrote:
>> Virtual DRM splits the resources of an overlay plane in
Hi, Enrico Weigelt
Thank you for reply.
On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote:
> On 21.06.21 08:27, Tomohito Esaki wrote:
>
> Hi,
>
>> Virtual DRM splits the overlay planes of a display controller into multiple
>> virtual devices to allow each plane to be accessed by each pr
Hi, Thomas
Thank you for reply.
On 2021/06/21 16:10, Thomas Zimmermann wrote:
> Hi
>
> Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
>> Virtual DRM splits the overlay planes of a display controller into
>> multiple
>> virtual devices to allow each plane to be accessed by each process.
>>
>> This m
20 matches
Mail list logo
