linux-kernel - Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49C3CB88.2000202@shipmail.org>
Date:	Fri, 20 Mar 2009 17:59:52 +0100
From:	Thomas Hellström <thomas@...pmail.org>
To:	Greg KH <greg@...ah.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Thomas Hellstrom <thellstrom@...are.com>,
	David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	Daniel Stone <daniel@...ishbar.org>,
	Richard Purdie <rpurdie@...ux.intel.com>,
	Sindhudweep Sarkar <sindhudweep.sarkar@...il.com>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core
 changes

Greg KH wrote:
> On Fri, Mar 20, 2009 at 03:00:32PM +0000, Alan Cox wrote:
>   
>>>> By the same logic, would you support including the proprietary NVIDIA
>>>> driver while we wait for Nouveau to catch up?
>>>>         
>>> The license of the NVIDIA driver does not allow that to even be a
>>> possibility.
>>>       
>> I'm not convinced this is any different. If you accept the 3D changes you
>> step into a dangerous world of estoppel and since it has many
>> rightsholders also the wonderful world of contributory infringement. It
>> really really needs lawyers to look into it.
>>     
>
> I would hope that Intel's lawyers would have done such a thing before
> releasing the kernel and xorg code under the licenses that they did :)
>
>   
>> Now the other way to do it that might be more productive and simpler
>> would be to rip all the 3D crap out of that driver and just include the
>> minimum needed 2D bits for the open source X driver. Makes the code
>> smaller and cleaner, avoids an legal questions and lets people get on
>> with real work.
>>     
>
> Hm, that sounds fine to me.
>
> Does that mean that all of these drm patches that I posted are _only_
> needed for the 3d portions of the driver?  If I rip out the portions of
> the psb kernel driver that need these changes, do I end up with an
> working 2d driver as well?  Richard and Thomas, any thoughts here?
>
> thanks,
>
> greg k-h
>
>   
Greg,
Let's not forget the video stuff. I'm not sure about the status of that.

But all the other patches are needed for 2D functionality and kernel 
modesetting.
If you want to strip 3D you can strip.

psb_schedule.[ch] - The 3D scheduler.
psb_xhw.c - The interface to the binary X server module.
psb_scene.c - The 3D scene tracker.

and anything that appears unused after that.
This means you lose Render acceleration and textured video and 
downscaling in the X server as well,
although accelerated rotation should still work, since it uses the 2D 
engine.

I think the video acceleration sits in

psb_msvdx.c
psb_msvdxinit.c
lnc_topaz.c
lnc_topazinit.c

/Thomas



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/