There are situations when a backend DRM driver makes a buffer bigger size than a frontend buffer.
For example, i915 driver counts a stride by a multiplication of a display width in pixesl on a number of bytes per pixel
and aligns it up to 64 bytes. Then a size of the buffer is counted by a multiplication of the stride on a display height.
So we have the backend buffer is bigger than the frontend buffer with an unaligned stride.
It causes a crash when bytes are coping from the frontend buffer to the backend buffer with the size of the backend buffer.
In a case when we do not use zero-copying the situation can be fixed by coping of lines of the frontend buffer to beginning of lines of the backend buffer one by one.
This fix is only suitable in the case without zero-copying. In the case of zero-copying a frontend should prepare its buffer with a corresponding stride.
There is a warning alarms about the situation.
Fix of crash when strides are different
There are situations when a backend DRM driver makes a buffer bigger size than a frontend buffer. For example, i915 driver counts a stride by a multiplication of a display width in pixesl on a number of bytes per pixel and aligns it up to 64 bytes. Then a size of the buffer is counted by a multiplication of the stride on a display height. So we have the backend buffer is bigger than the frontend buffer with an unaligned stride. It causes a crash when bytes are coping from the frontend buffer to the backend buffer with the size of the backend buffer.
In a case when we do not use zero-copying the situation can be fixed by coping of lines of the frontend buffer to beginning of lines of the backend buffer one by one.
This fix is only suitable in the case without zero-copying. In the case of zero-copying a frontend should prepare its buffer with a corresponding stride. There is a warning alarms about the situation.
Signed-off-by: Alexander Sychev santucco@gmail.com