Markus Volk
e57c26ea29
Mesa 22.2.2 is a bug fix release which fixes bugs found since the 22.2.1 release. New features None Bug fixes radv: Crash in dEQP-VK.ray_query.misc.dynamic_indexing glthread: radeonsi: offset textures in game starsector with glthread enabled Crashing on Windows VM Exanima renders with the wrong colors. nouveau: tegra124: GL_OUT_OF_MEMORY error Changes freedreno: Fix graphic glitches on a4xx and a5xx nir/lower_system_values: Fix cs_local_index_to_id with variable workgroups pan/mdg: Lower PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK on Midgard pan/mdg: Fix 16-bit alignment with spiller nir: Fix nir_fmax_abs_vec_comp gallium/vl: Add opaque rgb pixel formats aco/spill: Fix spilling of Phi operands tu: Reset whether there is DS resolve for dynamic subpass gallivm: handle llvm coroutines for llvm > 15 nouveau: treat DRM_FORMAT_INVALID as implicit modifier docs: Add sha256 sum for 22.2.1 .pick_status.json: Update to 243aa6b2ec0c2626b1333ba666a6d6d60ede8505 .pick_status.json: Update to c4482a3c1a973975eb27ac284a18bebca24f7876 .pick_status.json: Update to 3eed5931edf6e5f45378b013ca21f98f17af2b34 .pick_status.json: Update to b02e9ef35a0446019cda9473e4c355c7cc4bb24d .pick_status.json: Mark 4c7a44413a07d3fb314f786e047bb7212c082a6c as denominated .pick_status.json: Mark dbd022f2ab43ff0a9ecc05c61123467e25f109de as backported turnip: Don’t use the dynamic color write enable during non-dynamic. gallium/u_threaded_context: remove stale comment r300: don’t use smooth line if not requested r600/sfn: Always start a new CF after a KILL instruction r600/sfn: don’t propagate registers into conditional test virgl: Report CONSTANT_BUFFER_SIZE according to GL_MAX_UNIFORM_BLOCK_SIZE vulkan/runtime: don’t lookup the pipeline disk cache if disabled anv: initialization pipeline layout to 0s anv: add missing tracepoint clc/clover: Link clang statically when shared-llvm is disabled zink: clamp line_stipple_factor to 1 if stipple is disabled zink: unset rp_changed after initializing renderpass attachments zink: disable fbfetch when flushing clears vulkan/wsi: Add dep_libudev to idep dependencies gallium/va: vaDeriveImage to check PIPE_VIDEO_SUPPORTS_CONTIGUOUS_PLANES_MAP d3d12: Implement cap PIPE_VIDEO_SUPPORTS_CONTIGUOUS_PLANES_MAP zink: fix invalid Offset set for variables which do not need an offset zink: stop enabling minmax filtering when not supported zink: fix isNan mismatch between NIR and SPIR-V util/conf: enable init to zero workaround for Exanima util/radeonsi: enable zerovram workaround for Exanima radv: add radv_zero_vram workarounds for OpenGL games glthread: fix matrix stack depth tracking glthread: leave dlist dispatch in place for Begin/End util: Turn -DWINDOWS_NO_FUTEX to be pre_args - add a PACKAGECONFIG for perfetto support (From OE-Core rev: a68121557f72ebccc92adaec0df2b43abe11869d) Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit cbcaff0b4cc349706b9847f4262746b43adba209) Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
The project works using a mailing list patch submission process. Patches should be sent to the mailing list for the repository the components originate from (see below). Throughout the Yocto Project, the README files in the component in question should detail where to send patches, who the maintainers are and where bugs should be reported.
A guide to submitting patches to OpenEmbedded is available at:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
There is good documentation on how to write/format patches at:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.