Hello Giovanni, On Thu, 3 Jul 2014 11:14:48 +0200 Giovanni Campagna <scampa.giova...@gmail.com> wrote:
> 2014-07-03 10:48 GMT+02:00 Boris BREZILLON > <boris.brezil...@free-electrons.com>: > > Hello Giovanni, > > > > I have recently been working on a DRM/KMS driver which does not support > > OpenGL rendering (it only provides plane composition functionalities): > > [1]. > > > > If I understand correctly you patch series might solve some of the > > issues I am facing. > > It might get your working EGL, but it's not a complete solution, > because buffer management is limited to linear CPU-addressable "dumb" > buffers, which is probably not the most efficient choice (altough how > much slower it gets depends on the driver and on the HWl). > > > I'm trying to get wayland working with HW cursor and several planes, > > the problem is that it depends on GBM to provides drm plane and drm > > cursor support. > > > > I tried to get EGL working with my DRM device and it always ask for an > > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this > > point). > > > > First of all, am I mistaken in thinking this series could solve my > > issue ? > > Indeed, using my patch stack (patches 2 and 3) you will have a working > GBM device that will allocate GPU memory using the "dumb" interface. > If your driver is then able to upload this buffers to the plane HW (or > directly capable of allocating in GPU memory), that may be good enough > for you. > OTOH, this will not provide the wayland clients with the ability to > render directly to the plane buffers, because the "dumb" interface > does not provide global names that can be shared between processes, > therefore clients will have to render into a shared memory location, > that then the wayland compositor (weston, I assume) will have to > memcpy into a GBM allocated buffer. > If you want to avoid that, you will need to design an ioctl interface > for your driver to allocate buffers, then write a "winsys" for the > userspace side that uses those ioctls (directly or through libdrm) - > first it allocates the buffer with your driver specific ioctl and then > calls GEM_FLINK to get the global name, which can be passed to weston > and in there to gbm_bo_import(). > If your HW is uncapable of GL rendering (and thus you want to use SW > rendering always) is quite likely that your driver will not be that > different from > dri_kms_swrast, except that will be able to share buffers (patch 3) > using GEM names. I'm just curious: what are you using this dri_kms_swrast implementation for ? Okay, my real question here is: Is there other people trying to do what I'm doing or do you need it for another use case :-) ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
