On Mon, 22 Aug 2016, Daniel Vetter wrote:
> On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov
> wrote:
>>
>> All I can think of is that you (?) are porting some changes from the
>> kernel to libdrm or vice-versa. In the latter case please _don't_ do
>> that. Work with your changes in upstream kerne
On Mon, 22 Aug 2016, Emil Velikov wrote:
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.
>
My opinio
On Sat, 20 Aug 2016, Emil Velikov wrote:
>
> If you or any !Linux folks are around on XDC we should really sit down
> and untangle some/all of these issues.
>
> Thanks
> Emil
>
If there was to be some sort of BoF (doesn't have to be formal, and
could be an after-hours event), I would inves
On Tue, 17 May 2016, Francois Tigeot wrote:
> Hi Randy,
>
> randyf at sibernet.com wrote:
>>
>>If you are interested in the primary Solaris source, you will really
>> want to looking at:
>>
>> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel
>
> Thanks. This do
On Tue, 17 May 2016, Francois Tigeot wrote:
>
>>> On the other hand, the non-Linux code path really is unused. I didn't want
>>> to be too intrusive in my patch but it's probably best to just remove it.
>>>
>> There is more to this world than Linux and BSD, there's Solaris as
>> well. Even though
On Sun, 5 Apr 2015, Emil Velikov wrote:
>> Note that the move of KMS drivers to this repo is recent, so there is little
>> history of their evolution.
>>
> Right, so things are a few newer than I thought, but still a bit off
> from upstream drm. Not too shocking though considering the amount of
Sorry, went to drafts and not to send...
>>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>>> cruft for which, I would like to think, there are no more users.
>>>
>>> Obviously the latter can be confirmed by Randy and friends.
>>
>> I'm somewhat confused by this statement,
>
>> Alternatively can we:
>> (1) move the wrapper to xf86drmMode.h itself, or
>> (2) move this inline helper function out of xf86drmMode.h and into
>> the two libdrm tests that use it (or a shared test helper .h [0])
>> (3) remove the inline and make drm_property_type_is a non-inline
>> functi
>
> Was honestly hoping that patch #1 is not required as:
> - Getting the drm.h header in sync with the kernel will be annoying.
Indeed.
I have a version of drm.h that works with Solaris and *should* still
work with all other consumers, but as I still have a ways to get fully to
speed, am
