On 08/09/2016 04:08 PM, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
> wrote:
>> Hmm.
>>
>> I don't have a strong opinion on this, but IMO the original idea of
>> allowing a user-space driver to optimize away the dirty calls isn't a
>> bad one.
>> Since the xf86-video-v
On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
wrote:
> Hmm.
>
> I don't have a strong opinion on this, but IMO the original idea of
> allowing a user-space driver to optimize away the dirty calls isn't a
> bad one.
> Since the xf86-video-vmware always assumed that all drms it has to deal
> wit
Hmm.
I don't have a strong opinion on this, but IMO the original idea of
allowing a user-space driver to optimize away the dirty calls isn't a
bad one.
Since the xf86-video-vmware always assumed that all drms it has to deal
with has this property set it's not using it.
The modesetting driver could
It was added way back together with the dirty_fb ioctl, but neither
generic xfree86-modesetting nor the vmware driver use it. Everyone is
supposed to just unconditionally call the dirtyfb when they do
frontbuffer rendering.
And since unused uabi is bad uabi (there's reasons we require open
source
