[Mesa-dev] [PATCH 04/11] dri_interface: drop __NOT_HAVE_DRM_H magic

Ian Romanick idr at freedesktop.org
Mon Jul 20 11:36:21 PDT 2015


On 07/09/2015 01:12 PM, Emil Velikov wrote:
> On 9 July 2015 at 18:50, Ian Romanick <idr at freedesktop.org> wrote:
>> On 07/08/2015 10:07 AM, Emil Velikov wrote:
>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>> ---
>>>  include/GL/internal/dri_interface.h | 11 -----------
>>>  1 file changed, 11 deletions(-)
>>>
>>> diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
>>> index c827bb6..c0545b1 100644
>>> --- a/include/GL/internal/dri_interface.h
>>> +++ b/include/GL/internal/dri_interface.h
>>> @@ -40,20 +40,9 @@
>>>  #ifndef DRI_INTERFACE_H
>>>  #define DRI_INTERFACE_H
>>>
>>> -/* For archs with no drm.h */
>>> -#if defined(__APPLE__) || defined(__CYGWIN__) || defined(__GNU__)
>>> -#ifndef __NOT_HAVE_DRM_H
>>> -#define __NOT_HAVE_DRM_H
>>> -#endif
>>> -#endif
>>> -
>>> -#ifndef __NOT_HAVE_DRM_H
>>
>> Shouldn't this get changed to use HAVE_LIBDRM as in later patches?
> I thought about that, but that depends on if the versions of xserver
> that we care about define it. From a quick look that is not the case
> for older xservers, on the other hand drm* users which explicitly
> include drm.h. If others don't mind when/if things break, I'm fine
> using HAVE_LIBDRM here.

Two questions come to mind...

1. Which X server versions build?

2. How hard would it be to patch the broken versions to work?  It seems
like it should be pretty easy, right?

If all of the versions that we think people actually care about work,
then I don't think we should worry.

>> I
>> guess drm_context_t and drm_drawable_t are ABI, so they shouldn't ever
>> change.  It does feel a little icky to redefine them when not necessary.
>>
> Yes it is rather nasty. Note that all of the "junk" is DRI1 stuff. I
> was thinking about nuking/moving it, but with the see the "old dri
> loader new module, and vice versa" topic still open, I've decided to
> leave thing as is.
> 
> -Emil



More information about the mesa-dev mailing list