On Friday, August 27th, 2021 at 16:04, Harry Wentland
wrote:
> > Is it possible to draw the cursor only on the overlay pipe (not on the
> > primary
> > pipe), even though the overlay pipe doesn't cover the whole CRTC?
> >
> > Or will the overlay pipe crop the cursor image?
> >
>
> It will be
On 2021-08-27 9:53 a.m., Simon Ser wrote:
> On Tuesday, August 24th, 2021 at 18:48, Harry Wentland
> wrote:
>
>> To elaborate on this a bit more, each HW plane's scanout engine
>> has the ability to scan out a cursor, in addition to the plane's
>> framebuffer. This cursor is drawn onto the
On Tuesday, August 24th, 2021 at 18:48, Harry Wentland
wrote:
> To elaborate on this a bit more, each HW plane's scanout engine
> has the ability to scan out a cursor, in addition to the plane's
> framebuffer. This cursor is drawn onto the plane at the scanout
> phase. Any further scaling,
Hi Nicholas!
On Tuesday, August 24th, 2021 at 16:56, Kazlauskas, Nicholas
wrote:
> It's easiest to under the hardware cursor as being constrained within
> the DRM plane specifications. Each DRM plane maps to 1 (or 2) hardware
> pipes and the cursor has to be drawn along with it. The cursor
On 2021-08-24 10:56 a.m., Kazlauskas, Nicholas wrote:
> On 2021-08-24 9:59 a.m., Simon Ser wrote:
>> Hi Rodrigo!
>>
>> Thanks a lot for your reply! Comments below, please bear with me: I'm
>> a bit familiar with the cursor issues, but my knowledge of AMD hw is
>> still severely lacking.
>>
>>
On 2021-08-24 9:59 a.m., Simon Ser wrote:
Hi Rodrigo!
Thanks a lot for your reply! Comments below, please bear with me: I'm
a bit familiar with the cursor issues, but my knowledge of AMD hw is
still severely lacking.
On Wednesday, August 18th, 2021 at 15:18, Rodrigo Siqueira
wrote:
On
Hi Rodrigo!
Thanks a lot for your reply! Comments below, please bear with me: I'm
a bit familiar with the cursor issues, but my knowledge of AMD hw is
still severely lacking.
On Wednesday, August 18th, 2021 at 15:18, Rodrigo Siqueira
wrote:
> On 08/18, Simon Ser wrote:
> > Hm. This patch
Hi Simon,
On 08/18, Simon Ser wrote:
> Hm. This patch causes a regression for me. I was using primary + overlay
> not covering the whole primary plane + cursor before. This patch breaks it.
Which branch are you using? Recently, I reverted part of that patch,
see:
Revert "drm/amd/display: Fix
Hm. This patch causes a regression for me. I was using primary + overlay
not covering the whole primary plane + cursor before. This patch breaks it.
This patch makes the overlay plane very useless for me, because the primary
plane is always under the overlay plane.
> Basically, we cannot draw
I using linux kernel 5.13 rc1, has "drm/amd/display: Reject non-zero
src_y and src_x for video planes" patch, git bisect bad commit is
"drm/amd/display: Fix two cursor duplication when using overlay", i
build kernel 5.13 many times, reboot test many times.
2021-05-11 8:37 GMT+08:00, Rodrigo
On 05/10, youling257 wrote:
> I using amd 3400g running with android-x86, this patch is a bad commit when i
> use android-x86 on amdgpu.
>
> Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported
> by plane."" is the first bad commit, cause a androidx86 run on amdgpu
>
I using amd 3400g running with android-x86, this patch is a bad commit when i
use android-x86 on amdgpu.
Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported by
plane."" is the first bad commit, cause a androidx86 run on amdgpu problem,
look the video,
On 2021-04-13 8:06 p.m., Rodrigo Siqueira wrote:
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with
14 matches
Mail list logo
