Re: [Mesa-dev] Fwd: [PATCHv2 6/9] gallium: rename DRM_API_HANDLE_TYPE* WINSYS_HANDLE_TYPE*
On Tue, Jun 16, 2015 at 3:44 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Tue, Jun 16, 2015 at 3:33 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Jun 16, 2015 at 2:42 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi Marek On Mon, Jun 15, 2015 at 10:21 PM, Marek Olšák mar...@gmail.com wrote: The idea of drm_driver.h and the DRM prefix is that it's meant to be Linux-specific, and winsys_handle should be considered an opaque structure by most state trackers. I think VMWare have their own definition of winsys_handle for Windows. Is this in upstream? I couldn't find it. I don't think so. If they have downstream patch to mesa, it's unfair to make such guesses to reject a patch. They should speak up and propose an alternative in this case, or simply patch it differently. The terms like KMS, SHARED (= FLINK), and FD (= DMABUF) are very DRM-specific, so they shouldn't be considered a standard gallium/winsys interface. Perhaps they could be renamed so other terms, not drm-specific, could be introduced? DRM_API_HANDLE_TYPE_SHARED - WINSYS_HANDLE_TYPE_DRM_FLINK DRM_API_HANDLE_TYPE_KMS - WINSYS_HANDLE_TYPE_DRM_KMS DRM_API_HANDLE_TYPE_FD - WINSYS_HANDLE_TYPE_DRM_DMABUF It was possible to introduce a drisw-specific winsys struct before the gbm kms_swrast driver, but since then both headers are used simultaneously, so a common structure seems necessary. It's still Linux-specific though, so DRM_* seems more appropriate than WINSYS_HANDLE_*. Ok, but my point is to not make it drm specific, so a shmid handle can be use by drisw. OK, I suppose your latest proposition of renaming the types to WINSYS_HANDLE_TYPE_DRM_* makes sense here. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [PATCHv2 6/9] gallium: rename DRM_API_HANDLE_TYPE* WINSYS_HANDLE_TYPE*
Hi On Tue, Jun 16, 2015 at 3:33 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Jun 16, 2015 at 2:42 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi Marek On Mon, Jun 15, 2015 at 10:21 PM, Marek Olšák mar...@gmail.com wrote: The idea of drm_driver.h and the DRM prefix is that it's meant to be Linux-specific, and winsys_handle should be considered an opaque structure by most state trackers. I think VMWare have their own definition of winsys_handle for Windows. Is this in upstream? I couldn't find it. I don't think so. If they have downstream patch to mesa, it's unfair to make such guesses to reject a patch. They should speak up and propose an alternative in this case, or simply patch it differently. The terms like KMS, SHARED (= FLINK), and FD (= DMABUF) are very DRM-specific, so they shouldn't be considered a standard gallium/winsys interface. Perhaps they could be renamed so other terms, not drm-specific, could be introduced? DRM_API_HANDLE_TYPE_SHARED - WINSYS_HANDLE_TYPE_DRM_FLINK DRM_API_HANDLE_TYPE_KMS - WINSYS_HANDLE_TYPE_DRM_KMS DRM_API_HANDLE_TYPE_FD - WINSYS_HANDLE_TYPE_DRM_DMABUF It was possible to introduce a drisw-specific winsys struct before the gbm kms_swrast driver, but since then both headers are used simultaneously, so a common structure seems necessary. It's still Linux-specific though, so DRM_* seems more appropriate than WINSYS_HANDLE_*. Ok, but my point is to not make it drm specific, so a shmid handle can be use by drisw. -- Marc-André Lureau ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [PATCHv2 6/9] gallium: rename DRM_API_HANDLE_TYPE* WINSYS_HANDLE_TYPE*
On 06/16/2015 07:44 AM, Marc-André Lureau wrote: Hi On Tue, Jun 16, 2015 at 3:33 PM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: On Tue, Jun 16, 2015 at 2:42 PM, Marc-André Lureau marcandre.lur...@gmail.com mailto:marcandre.lur...@gmail.com wrote: Hi Marek On Mon, Jun 15, 2015 at 10:21 PM, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: The idea of drm_driver.h and the DRM prefix is that it's meant to be Linux-specific, and winsys_handle should be considered an opaque structure by most state trackers. I think VMWare have their own definition of winsys_handle for Windows. Is this in upstream? I couldn't find it. I don't think so. If they have downstream patch to mesa, it's unfair to make such guesses to reject a patch. They should speak up and propose an alternative in this case, or simply patch it differently. I don't think these changes will cause us any trouble. Maybe the WINSYS_HANDLE_TYPE_* values should be an enum type so that the compiler can catch unhandled switch cases and gdb can display the names instead of numbers. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
