[PATCH v5 xserver 1/7] dix: Add dixPrivatesCreated helper function

[Hans de Goede]

Hi,

On 06-09-16 16:41, Keith Packard wrote:
> Hans de Goede <hdegoede at redhat.com> writes:
>
>> From: Dave Airlie <airlied at redhat.com>
>>
>> This is a preparation patch for adding prime hw-cursor support.
>
> I'm fine with this function, but the prime hw-cursor support which uses
> it is a pretty ugly kludge, depending on the hot-plugged device never
> actually needing a hw cursor.

To be clear, hot-plugged hw-cursor capable GPUs will still
work fine after this patch-set, they just will end up using
a sw-cursor. Which means that for users of hot-plugged hw-cursor
capable GPU scenario will be of no worse then they are
today (and if the Xserver is restarted after plugging
the GPU they too will benefit and get hw cursor support).

Note that hot-plugged hw-cursor capable GPUs are a quite
rare use-case, while as OTOH laptops with hybrid graphics
and slave outputs are used by tons of people. Our current
story here where we draw a software cursor over the
frontbuffer, which with composting DEs gets changed
every frame) leads to a flickering or sometimes even
invisible cursor and this really is a bad user experience,
esp. in the year 2016.

All those many users of laptops with hybrid graphics
and slave outputs will benefit from this patch-set,
the user experience really is much much better.

Note I'm not saying that we should not fix the
hot-plugged hw-cursor capable GPU case, but that
requires changes to dix/privates.c which really are
orthogonal to this patch-set.

In the mean time this patch-set contains all of
3 lines of code in the hw-cursor patch to deal with
the privates issue and force sw-cursor fallback,
3 lines which can easily be removed once
dix/privates.c is fixed to allow relocating the
per screen cursor data.

TL;DR: Yes this is not ideal, but the workaround
is tiny and the improvements this patch-set brings
are large, so I do not consider this a blocker.

Regards,

Hans