Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

[Dave Airlie <airlied@gmail.com>]

2009/7/21 Stephane Marchesin <marchesin@icps.u-strasbg.fr>:
> 2009/7/20 Thomas Hellström <thomas@shipmail.org>:
>>
>> Stephane,
>> Some comments on how these things has been handled / could be handled.
>>>
>>> I would like to raise a couple of real-life issues I have in mind:
>>>
>>> * First example, let's say VIA gets their Chrome9 DRM merged into the
>>> kernel. Now let's say I reverse engineer the hardware (or use the docs
>>> whenever they're available) and write a 3D component that needs
>>> modifications to the existing DRM interface (or maybe I realize I need
>>> a completely new DRM). Then who gets the upper hand? Do I have to keep
>>> compatibility with user space binary modules that I do not care about?
>>>
>>
>> If there is a serious OS project, I'd start a new DRM driver.
>> That's sort of what may happen with openChrome vs via..
>>
>
> Well, for user space, there can be as many drivers as you want for a
> given device. But the DRM policy always was one driver per hardware so
> as to avoid confusing people, so what you're proposing is in fact not
> possible. In that case, this would even deter a fully open source
> driver as it would have to keep the same interface as some (possibly
> unsupported) driver.

Well with KMS it sort of changes that a small bit, since a KMS driver really
isn't required to share old interfaces, since having a KMS enabled
kernel will break any
userspace that is out there just by setting up the hw different. as
long as the old
code is still available in the backwards compat manner it should all be fine.

We've also had two drm drivers before, i830 and i915 supported a lot
of the same hw
and it mostly worked, if you looked at it from a kernel perspective.

Dave.