On Mon, Aug 22, 2016 at 4:12 PM, wrote:
>
> 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 ack
On Fri, Aug 19, 2016 at 8:46 PM, Rob Clark wrote:
> perhaps, but if the target audience for driver specific APIs is
> libdrm/mesa, which already uses stdint types, then I fail to see the
> point..
>
> It is a bit difference scenario for some of the core kms ioctls which
> are not driver specific.
On Fri, Aug 19, 2016 at 6:32 PM, Rob Clark wrote:
> tbh, I'm all in favor of making it easier to sync kernel headers to
> libdrm, etc.
>
> But kernel *does* have stdint types. Just (for some reason that
> completely baffles me) not in stdint.h so we can't include that from
> the uapi headers the
On Thu, Aug 4, 2016 at 3:01 PM, Daniel Vetter wrote:
> tbh, most if not all arm drivers are gpl only, and due to code sharing and
> refactoring I'd say a lot of that has leaked all over drm. IANAL and all
> that, but personally I believe that the entire idea of drm being MIT is
> walking on ever
I believe this driver is extremely useful, and I see possible issues with
the fact that the driver is GPL Only. This driver is critical for devices
that lack a proper DRM driver, and locking it into GPL Only could lead to
issues with porting the system over to platforms like FreeBSD,
DragonFlyBSD,
I like the idea of the whole DRM Text mode driver set, and would you be
open to changing the license to (or possibly adding a dual license option)
involving the MIT[1], BSD 2-clause[2], or BSD 3-clause[3]. This would
simplify the porting of this driver to other platforms ( for example
FreeBSD, Dra
