Hi
Am 04.07.19 um 16:15 schrieb Noralf Trønnes:
>>> Hm, why do you think that?
>>
>> Drivers may already come with their own shadow buffer. Cirrus is an
>> example of that. It uses shmem buffer objects as shadow fbs and
>> internally updates the device frame buffer in its dirty callback. Using
>>
Den 04.07.2019 13.10, skrev Thomas Zimmermann:
> Hi
>
> Am 04.07.19 um 12:18 schrieb Noralf Trønnes:
>>
>>
>> Den 04.07.2019 09.43, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 03.07.19 um 21:27 schrieb Noralf Trønnes:
Den 03.07.2019 10.32, skrev Thomas Zimmermann:
> DRM client
Hi
Am 04.07.19 um 12:18 schrieb Noralf Trønnes:
>
>
> Den 04.07.2019 09.43, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 03.07.19 um 21:27 schrieb Noralf Trønnes:
>>>
>>>
>>> Den 03.07.2019 10.32, skrev Thomas Zimmermann:
DRM client buffers are permanently mapped throughout their lifetime. This
Den 04.07.2019 09.43, skrev Thomas Zimmermann:
> Hi
>
> Am 03.07.19 um 21:27 schrieb Noralf Trønnes:
>>
>>
>> Den 03.07.2019 10.32, skrev Thomas Zimmermann:
>>> DRM client buffers are permanently mapped throughout their lifetime. This
>>> prevents us from using generic framebuffer emulation for
Hi
Am 03.07.19 um 21:27 schrieb Noralf Trønnes:
>
>
> Den 03.07.2019 10.32, skrev Thomas Zimmermann:
>> DRM client buffers are permanently mapped throughout their lifetime. This
>> prevents us from using generic framebuffer emulation for devices with
>> small dedicated video memory, such as ast
Den 03.07.2019 10.32, skrev Thomas Zimmermann:
> DRM client buffers are permanently mapped throughout their lifetime. This
> prevents us from using generic framebuffer emulation for devices with
> small dedicated video memory, such as ast or mgag200. With fb buffers
> permanently mapped, such
DRM client buffers are permanently mapped throughout their lifetime. This
prevents us from using generic framebuffer emulation for devices with
small dedicated video memory, such as ast or mgag200. With fb buffers
permanently mapped, such devices often won't have enougth space left to
display