| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
GBM_BO_USE_CURSOR_64X64 is kept so that existing users of GBM continue to
build, but it no longer rejects widths or heights other than 64.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79809
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
This should give the caller some information of what called the error.
For the gbm_bo_import() case, for instance, it is possible to know if
the import is not supported or the error was caused by an invalid
parameter.
Reviewed-by: Emil Velikov <[email protected]>
|
| |
|
|
|
|
|
| |
Add a new import type that lets us create a gbm bo from a
DMA-BUF file descriptor.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
|
| |
Add gbm function to get a DMA-BUF file descriptor for a gbm bo.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
|
|
| |
It's only used in this one file as far as I can tell, and exporting a
symbol named 'devices' from a shared library is a recipe for trouble.
Reviewed-by: Emil Velikov <[email protected]>
|
| |
|
|
|
|
|
|
| |
Probably depending on compiler settings, the definition can be hidden,
so undefined reference error can be encountred during linking.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75528
Reviewed-by: Emil Velikov <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This symbol is internal and was never part of the API.
Unused by any of the gbm backends, it makes sense to
simply not export it.
Cc: Kristian Høgsberg <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additionally this commit removes the following exported functions
_gbm_udev_device_new_from_fd()
_gbm_fd_get_device_name()
_gbm_log()
All three were erroneously marked as exported since their inception.
Neither of them has ever been a part of the API thus there should be
no users of them.
Cc: Chad Versace <[email protected]>
Cc: Kristian Høgsberg <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
| |
We use pitch for 'pixels per row' and stride for 'bytes per row' pretty
consistently in mesa and most other places, so rename the gbm API.
|
| |
|
|
|
| |
This generalizes and replaces gbm_bo_create_for_egl_image. gbm_bo_import
will create a gbm_bo from either an EGLImage or a struct wl_buffer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but there
was never a mechanism initialize a buffer suitable for use with KMS
hw cursors. The hw cursor bo is typically not compatible with anything EGL
can render to, and thus there's no way to get data into such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu->gpu pixel transfer business.
Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
| |
This allows the user to associate some data to a gbm_bo and get a
callback when the bo is destroyed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea here is to be able to create an egl window surface from a
gbm_surface. This avoids the need for the surfaceless extension and
lets the EGL platform handle buffer allocation, while keeping the user
in charge of somehow presenting the buffers (using kms page flipping,
for example).
gbm_surface_lock_front_buffer() locks a surface's front buffer and
returns a gbm bo representing it. This bo should later be returned
to the gbm surface using gbm_surface_release_buffer().
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GBM needs the buffer format in order to communicate with DRM and clients
for things like scanout.
So track the DRI format requested in the various back ends and use it to
return the DRI format back to GBM when requested. GBM will then map
this into the GBM surface type (which is in turn based on the DRM fb
format list).
Signed-off-by: Jesse Barnes <[email protected]>
|
| | |
|
| | |
|
| |
|
