[Mesa-dev] Fwd: [PATCHv2 6/9] gallium: rename DRM_API_HANDLE_TYPE* WINSYS_HANDLE_TYPE*
Marek Olšák
maraeo at gmail.com
Tue Jun 16 06:57:52 PDT 2015
On Tue, Jun 16, 2015 at 3:44 PM, Marc-André Lureau
<marcandre.lureau at gmail.com> wrote:
> Hi
>
> On Tue, Jun 16, 2015 at 3:33 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> On Tue, Jun 16, 2015 at 2:42 PM, Marc-André Lureau
>> <marcandre.lureau at gmail.com> wrote:
>> > Hi Marek
>> >
>> > On Mon, Jun 15, 2015 at 10:21 PM, Marek Olšák <maraeo at 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
More information about the mesa-dev
mailing list