mainnika/weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix indentation all through the project

Browse Source 
Fixes a “regression” from 04918f3b0b, but
also other missed pieces.
This commit is contained in:
Emmanuel Gil Peyrot
2021-07-31 17:25:41 +02:00
committed by Link Mauve
parent 48cd15ed44
commit eff793ab46
25 changed files with 96 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files
libweston/backend-drm/drm-virtual.c
+2 -2
View File
@@ -62,8 +62,8 @@ drm_virtual_crtc_create(struct drm_backend *b, struct drm_output *output)
crtc->pipe = 0;
/* Poisoning the pointers as CRTC's of virtual outputs should not be
* added to the DRM-backend CRTC list. With this we can assure (in
* function drm_virtual_crtc_destroy()) that this did not happen. */
* added to the DRM-backend CRTC list. With this we can assure (in
* function drm_virtual_crtc_destroy()) that this did not happen. */
crtc->link.prev = POISON_PTR;
crtc->link.next = POISON_PTR;
libweston/backend-drm/fb.c
+7 -7
View File
@@ -238,13 +238,13 @@ drm_fb_get_from_dmabuf(struct linux_dmabuf_buffer *dmabuf,
.modifier = dmabuf->attributes.modifier[0],
};
/* We should not import to KMS a buffer that has been allocated using no
* modifiers. Usually drivers use linear layouts to allocate with no
* modifiers, but this is not a rule. The driver could use, for
* instance, a tiling layout under the hood - and both Weston and the
* KMS driver can't know. So giving the buffer to KMS is not safe, as
* not knowing its layout can result in garbage being displayed. In
* short, importing a buffer to KMS requires explicit modifiers. */
/* We should not import to KMS a buffer that has been allocated using no
* modifiers. Usually drivers use linear layouts to allocate with no
* modifiers, but this is not a rule. The driver could use, for
* instance, a tiling layout under the hood - and both Weston and the
* KMS driver can't know. So giving the buffer to KMS is not safe, as
* not knowing its layout can result in garbage being displayed. In
* short, importing a buffer to KMS requires explicit modifiers. */
if (dmabuf->attributes.modifier[0] == DRM_FORMAT_MOD_INVALID)
return NULL;
libweston/backend-drm/state-propose.c
+7 -7
View File
@@ -114,7 +114,7 @@ drm_output_destroy_zpos_plane(struct drm_plane_zpos *plane_zpos)
static bool
drm_output_check_plane_has_view_assigned(struct drm_plane *plane,
struct drm_output_state *output_state)
struct drm_output_state *output_state)
{
struct drm_plane_state *ps;
wl_list_for_each(ps, &output_state->plane_list, link) {
@@ -140,12 +140,12 @@ drm_output_plane_has_valid_format(struct drm_plane *plane,
fb->format->format);
if (fmt) {
/* We never try to promote a dmabuf with DRM_FORMAT_MOD_INVALID
* to a KMS plane (see drm_fb_get_from_dmabuf() for more details).
* So if fb->modifier == DRM_FORMAT_MOD_INVALID, we are sure
* that this is for the legacy GBM import path, in which a
* wl_drm is being used for scanout. Mesa is the only user we
* care in this case (even though recent versions are also using
* dmabufs), and it should know better what works or not. */
* to a KMS plane (see drm_fb_get_from_dmabuf() for more details).
* So if fb->modifier == DRM_FORMAT_MOD_INVALID, we are sure
* that this is for the legacy GBM import path, in which a
* wl_drm is being used for scanout. Mesa is the only user we
* care in this case (even though recent versions are also using
* dmabufs), and it should know better what works or not. */
if (fb->modifier == DRM_FORMAT_MOD_INVALID)
return true;