Both types are already binary equal: both are enums using the same bit values,
but from compiler's perspective they're still different types, so it's warning.
> ../glamor/glamor_trapezoid.c:123:47: warning: implicit conversion from
> enumeration type 'PictFormatShort' (aka 'enum _PictFormatShort') to different
> enumeration type 'pixman_format_code_t' [-Wenum-conversion]
> 123 | image = pixman_image_create_bits(picture->format,
> | ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~^~~~~~
> 1 warning generated.
The PICT_* fields, values and macros are relics from pre-pixman days (pixman,
historically, essentially is the PICT_* stuff moved out to separate library)
This has been a practical way for doing the transition from the old internal
PICT_* code to pixman. Now it's time to finish it all up and drop the extra
glue layer.
In order to make it smooth, and also providing backwards compatibility for
drivers (until they all keep up), just aliasing the types and adding #define's
for the enum values.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This change is necessary to fix a segfault in intel driver at CloseScreen.
sna_early_close_screen() releases the glyph cache using FreePicture(), which needs
PictureScreen private of pScreen. It has already been released by PictureScreenClose(),
which is a pre-hook, and segfault occurs. Hence it is necessary to move
PictureScreenClose() to post-hooks.
Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
this adds dummy pointers in place of removed fields in some structs, only for
SDK headers, to preserve ABI
some of these fix segfaults for nvidia driver, some are preemptive
Signed-off-by: dasha_uwu <dasha@linuxping.win>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All relevant things are now in dix/colormap_priv.h, so no need
to include colormapst.h anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it shouldn't practically happen, better adding a trivial check,
just in case. The check is really cheap and possibly optimized-out.
| ../render/filter.c: In function ‘SetPicturePictFilter’:
| ../render/filter.c:388:36: warning: dereference of possibly-NULL ‘new_params’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 388 | pPicture->filter_params[i] = params[i];
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it practically should never happen, but just in case, and
for silencing the analyzer, add an extra check here (which doesn't
cost us much).
| ../render/picture.c: In function ‘cpAlphaMap’:
| ../render/picture.c:1002:30: warning: dereference of NULL ‘screen’ [CWE-476] [-Wanalyzer-null-dereference]
| 1002 | id = res->info[screen->myNum].id;
| | ~~~~~~^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it's probably never happening, but still better to protect from it,
just in case. The extra cost of it hard to measure on today's machines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ancient pict_f_vector and pixman_f_vector macros have been a fallout
from long ago transition to pixman and had been removed quite a while ago.
Unfortunately, Intel driver (which is not under our reign) hasn't been
kept up to date yet. So re-adding the compat macro, until Intel driver
team had a chance to keep up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1778>
