Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

[Dave A. <ai...@gm...>]

On Fri, Jul 17, 2009 at 9:37 PM, Harald Welte<Har...@vi...> wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
>> On Fri, Jul 17, 2009 at 4:36 PM, <Bru...@vi...> wrote:
>> > To whom it may ceoncern:
>> >    The following 3 patches are the DRM kernel module that support VIA Chorme9 GFX chipset. They are based on 2.6.31-rc3. Please kindly help to integrate into kernel.
>> >
>>
>> Is there a userspace, or available documentation to write a userspace
>> to use this code.
>
> Dear David, the situation is still like it was some time ago:
>

Is there an open source DDX to set this up?

>
> 4) VIA does not have the resources to write an entirely new 3D driver for
>   Chrome9, especially since future products contain a different, incompatible
>   GPU.  I think it's much more useful to focus the resources at getting things
>   "right" for those future products.
>
> So, as you can see, the situation is far from being perfect.  However, it could
> also be much worse.
>
> I would be the first person to argue in favour of having some FOSS userspace
> code against this DRM kernel driver - but I can also understand the practical
> constraints.  Given that the technical issues (32bit ioctl compat, ...) can be
> adressed, I would hope the driver can get merged.
>
> So far I was not aware that there is an absolute precondition of existing 3D FOSS
> userspace code to get a DRM driver merged.  Yes, we all want it.  But is it a strong
> requirement?

We definitely need something to exercise the interface, how do we ever
know if we
break this interface directly or indirectly. The code as-is is of no
use to the Linux kernel
or open source communities. We cannot ship this in a distro and have
it do anything.

So the question is why would you want this upstream? if you need a
binary DDX and
a binary 3D driver why don't you just keep shipping this out of tree?

Dave.