THe KMS AddFB call can fail for any reason at all: format/modifier not
suitable, stride not aligned, allocation not contiguous, etc. If this
happens with Weston's own buffers, the result is bad - no composition
output.
Failing AddFB from user-supplied buffers though, is not an error. The
user can'
We effectively require it as we don't react to dmabuf_format,
only to dmabuf_modifiers, so there's a chance we may not get
the supported formats information at all.
Signed-off-by: Emilio Pozuelo Monfort
---
v4: No changes here.
clients/simple-dmabuf-drm.c | 12 +---
1 file changed, 1 in
We want 0..255 values, not 0..254.
Signed-off-by: Emilio Pozuelo Monfort
---
New patch.
clients/simple-dmabuf-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 4f88f12e..198d88e8 100644
--- a/clients/simple-
No need to write libdrm driver specific code for each supported
driver, we can just let GBM call the right one for us now.
Signed-off-by: Emilio Pozuelo Monfort
---
v4: now with working NV12, (thanks Daniel!).
clients/simple-dmabuf-drm.c | 411
configure.ac
Just rely on getting the supported formats through the dmabuf
extension.
Signed-off-by: Emilio Pozuelo Monfort
---
v4: no changes.
clients/simple-dmabuf-drm.c | 11 ---
configure.ac| 2 +-
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/clients/simple-dma
On 11/07/18 13:55, Daniel Stone wrote:
> Hi Emilio,
>
> On Wed, 11 Jul 2018 at 12:53, Emilio Pozuelo Monfort
> wrote:
>> As for NV12 support: I tried to make gbm support that in
>> backends/dri/gbm_dri.c by adding a mapping to gbm_dri_visuals_table
>> from GBM_FORMAT_NV12 to __DRI_IMAGE_FOURCC_N
Hi all,
I have a display device that supports up to three different display
buffers: one graphic layer and two video layers. The graphic layer is at
the top (zpos=2).
I'm using Weston (DRM backend) with a Qt5 application at full screen
(graphic layer). Weston is using pixel format XR24 even
Hi Jonas,
What do you think of these patches?
Thanks,
Simon
On June 29, 2018 11:12 AM, wrote:
> From: Markus Ongyerth w...@ongy.net
>
> Hi,
>
> This is a v2 of a rather old patch series I more or less forgot about [1].
>
> The previous version of patch 1 is [2]
> The patch 2 and 3 are based on
> Provides the ability to emulate keyboards by applications. Complementary to
> input-method protocol.
>
> The interface is a mirror copy of wl_keyboard, with removed serials, and added
> seat binding.
>
> ---
>
> Hello,
>
> thank you for giving me a lot of useful feedback in the last round. I appl
Just a heads-up, I just merged a branch that fixes trackpoint acceleration
in libinput. The previous approach was simply broken, the new one is quite
similar to what we had before anyway - calculating speed from the deltas and
applying the acceleration curve from that. The curve is adjusted for
tra
10 matches
Mail list logo