@lists.sourceforge.net
Cc: Greg KH; Richard Lee; Harald Welte; Bruce Chang; Joseph Chan; Benjamin Pan
(Fremont)
Subject: Solution to SGI code in closed 3D drivers? (was Re: [Patch 0/3]
Resubmit VIA Chrome9 DRM via_chrome9 for upstream)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
XGI previously had this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
XGI previously had this problem, and I suspect VIA is having the same
problem now. They want to release the code to their 3D driver, but it's
based on a version of the OpenGL sample implementation licensed from
SGI. However, the SI has since been rel
Hello Robert:
> I appreciate the efforts that VIA is making towards supporting their
> customers. I have had users asking me for hardware acceleration with VIA
> chips in FreeBSD for a while now. Many users will be satisfied with a good
> hardware accelerated 2D solution. A 3D driver is certa
2009/7/20 Greg KH :
> On Mon, Jul 20, 2009 at 10:34:09PM +0200, Harald Welte wrote:
>> On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote:
>>
>> > Did VIA consider cooperation with distributions? Maybe they could
>> > sponsor some single Mesa developers? What about The Linux Driver
>> >
On Tue, Jul 21, 2009 at 12:28:35AM +0100, Alan Cox wrote:
> > I think "tightly integrated" could do with some clarification here.
> > qcserial was accepted despite not being functional without a closed
> > userspace component - an open one's since been rewritten to allow it to
>
> It got as far
> I think "tightly integrated" could do with some clarification here.
> qcserial was accepted despite not being functional without a closed
> userspace component - an open one's since been rewritten to allow it to
It got as far as staging with a good deal of complaint. I am not sure it
would ha
2009/7/21 Stephane Marchesin :
> 2009/7/20 Thomas Hellström :
>>
>> 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 int
2009/7/20 Thomas Hellström :
>
> 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
On Mon, Jul 20, 2009 at 10:34:09PM +0200, Harald Welte wrote:
> On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote:
>
> > Did VIA consider cooperation with distributions? Maybe they could
> > sponsor some single Mesa developers? What about The Linux Driver
> > Project: http://linuxdrive
On Mon, Jul 20, 2009 at 04:16:20PM +0100, Alan Cox wrote:
> > If the common agreement of the linux community is to *NOT* allow these
> > drivers in, so be it, then be honest and go ahead and tell the driver
> > writers. Don't make them respin their development trying to fix minor
> > flaws when
"Andrey Panin" writes:
> * Users are still on mercy of binary blob supplier. Will this blob run on
> arm ?
> Or powerpc ? Or even x86_64 ? Will it be compatible with XOrg X.Y ?
> Nobody knows that and there is no gain for users too.
Actually there is a loss - users see the kernel (or partial)
On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote:
> Did VIA consider cooperation with distributions? Maybe they could
> sponsor some single Mesa developers? What about The Linux Driver
> Project: http://linuxdriverproject.org/ ? Maybe they would like to
> cooperate? I'm looking for so
Hi Bruce,
On Mon, Jul 20, 2009 at 11:52:47AM +0800, brucech...@via.com.tw wrote:
> We are now preparing our new 2D source which need DRM support for the 3D HW
> acceleration for EXA and will release it in public domain within 1 month too.
> I believe it can be a good start for the DRM verificatio
On Mon, Jul 20, 2009 at 11:57:45AM -0400, Christoph Hellwig wrote:
> Greg still claims that qcserial could be used by rebooting from Windows,
> right?
I think any argument that involves us requiring open userspace but
allows us to get away with using Windows as a firmware loader is a
dubious on
2009/7/21 Thomas Hellström :
> Stephane Marchesin wrote:
>>>
>>> You obviously got all this completely wrong.
>>>
>>> I avoid writing closed source drivers whenever I can, I'm not whining and
>>> I'm not trying to push any of them. The code VIA is trying to submit has
>>> not
>>> been written by me
Stephane Marchesin wrote:
>> You obviously got all this completely wrong.
>>
>> I avoid writing closed source drivers whenever I can, I'm not whining and
>> I'm not trying to push any of them. The code VIA is trying to submit has not
>> been written by me nor anybody I know. All VIA code I and the
2009/7/21 Peter Zijlstra :
> On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote:
>> Politics:
>> It's true that sometimes some people don't like the code or what it
>> does. But when this is the underlying cause of NAK-ing a driver I think
>> it's very important that this is clearly stated,
> You obviously got all this completely wrong.
>
> I avoid writing closed source drivers whenever I can, I'm not whining and
> I'm not trying to push any of them. The code VIA is trying to submit has not
> been written by me nor anybody I know. All VIA code I and the companies I've
> worked for has
> Greg still claims that qcserial could be used by rebooting from Windows,
> right? In that it would still be extremly borderline to me, but it's
qcserial has a firmware loader app nowdays (someone wrote one in April)
http://www.codon.org.uk/~mjg59/gobi_loader/
indeed Matthew wrote it 8)
-
On Mon, Jul 20, 2009 at 04:52:26PM +0100, Matthew Garrett wrote:
> I think "tightly integrated" could do with some clarification here.
> qcserial was accepted despite not being functional without a closed
> userspace component - an open one's since been rewritten to allow it to
> work. Do we def
> If the common agreement of the linux community is to *NOT* allow these
> drivers in, so be it, then be honest and go ahead and tell the driver
> writers. Don't make them respin their development trying to fix minor
> flaws when their driver won't get in anyway!
The existing policy based on wh
Peter Zijlstra wrote:
> On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote:
>
>> Politics:
>> It's true that sometimes some people don't like the code or what it
>> does. But when this is the underlying cause of NAK-ing a driver I think
>> it's very important that this is clearly stated
Christoph Hellwig wrote:
>
>
> I think you're just trying to push your agenda.
>
> I think you're just trying to defend your business writing closed source
> drivers. Drivers that aren't usable without binary blobs don't have
> a business in the kernel tree, and your whining doesn't help it. Yo
> * fully functional GPL user-space driver.
>
> How can you argue that something as tailor made as a DRM interface can
> be used without it being a derived work?
Our prior policy has been to reject such stuff (both the Intel wireless
driver regulatory daemon and the GMX driver)
--
On 201, 07 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote:
> Hi!
>
> It appears that GPL'd DRM drivers for closed-source user-space
> clients are becoming more common, and the situation appears to be
> causing a lot of unnecessary work from people wanting their drivers
> in the mainstream ke
On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote:
> Politics:
> It's true that sometimes some people don't like the code or what it
> does. But when this is the underlying cause of NAK-ing a driver I think
> it's very important that this is clearly stated, instead of inventing
> various
On Mon, Jul 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote:
> Hi!
>
> It appears that GPL'd DRM drivers for closed-source user-space clients
> are becoming more common, and the situation appears to be causing a lot
> of unnecessary work from people wanting their drivers in the mainstream
t; From: zaj...@gmail.com [mailto:zaj...@gmail.com]
> Sent: Monday, July 20, 2009 1:23 AM
> To: Uros Nedic
> Cc: Harald Welte; dri-devel@lists.sourceforge.net; Richard Lee;
> gre...@suse.de; Bruce Chang; Joseph Chan; Benjamin Pan (Fremont)
> Subject: Re: [Patch 0/3] Resubmit VIA Ch
t; Richard Lee; gre...@suse.de;
Bruce Chang; Joseph Chan; Benjamin Pan (Fremont)
Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
W dniu 19 lipca 2009 18:57 użytkownik Uros Nedic napisał:
> If there are small amount of people with enough knowledge to write
> dev
t: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Fri, 2009-07-17 at 13:37 +0200, Harald Welte wrote:
[...]
> 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 wa
W dniu 19 lipca 2009 18:57 użytkownik Uros Nedic napisał:
> If there are small amount of people with enough knowledge to
> write device drivers, let AMD, VIA, Intel and others make some
> small one week school and call people from this community to
> teach them how to do that. This way total cost
W dniu 19 lipca 2009 12:22 użytkownik Harald Welte
napisał:
> Hi Rafal and others.
>
> On Sat, Jul 18, 2009 at 07:37:50PM +0200, Rafał Miłecki wrote:
>
>> > 4) VIA does not have the resources to write an entirely new 3D driver for
>> > Chrome9, especially since future products contain a differen
ty drivers.
Uros Nedic
Belgrade, Serbia
> Date: Sun, 19 Jul 2009 12:22:09 +0200
> From: haraldwe...@viatech.com
> To: zaj...@gmail.com
> Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> CC: dri-devel@lists.sourceforge.net; richard...@via.co
Hi Rafal and others.
On Sat, Jul 18, 2009 at 07:37:50PM +0200, Rafał Miłecki wrote:
> > 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 foc
2009/7/17 Harald Welte :
> 1) VIA's 3D Xorg driver cannot be released as FOSS since it cotains 3rd party
> licensed code
>
> (...)
>
> 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.
On Sat, Jul 18, 2009 at 03:37:46PM +0200, Rafa?? Mi??ecki wrote:
> 2009/7/17 :
> > This DRM code is kernel space part of a matching Xorg driver that we are
> > going thru final review to be submitted to xorg.
>
> What do you mean by Xorg driver?! DDX driver like openChrome?! Last
> time you decid
se.de; Bruce
Chang; Joseph Chan; dri-devel@lists.sourceforge.net
Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/17 :
> This DRM code is kernel space part of a matching Xorg driver that we
> are going thru final review to be submitted to xorg.
What do you m
enjamin Pan (Fremont); Richard Lee; gre...@suse.de;
> Bruce Chang; Joseph Chan; dri-devel@lists.sourceforge.net
> Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for
> upstream
>
> On Fri, 2009-07-17 at 13:37 +0200, Harald Welte wrote:
> [...]
>> So far I was
2009/7/17 :
> This DRM code is kernel space part of a matching Xorg driver that we are
> going thru final review to be submitted to xorg.
What do you mean by Xorg driver?! DDX driver like openChrome?! Last
time you decided to work on openChrome, didn't you?
--
Rafał Miłecki
---
Lee; gre...@suse.de;
Bruce Chang; Joseph Chan; dri-devel@lists.sourceforge.net
Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for
upstream
On Fri, 2009-07-17 at 13:37 +0200, Harald Welte wrote:
[...]
> So far I was not aware that there is an absolute precondition of
exis
On Fri, Jul 17, 2009 at 9:37 PM, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
>> On Fri, Jul 17, 2009 at 4:36 PM, wrote:
>> > To whom it may ceoncern:
>> > The following 3 patches are the DRM kernel module that support VIA
>> > Chorme9 GFX chipset. They ar
On Fri, Jul 17, 2009 at 15:23, Keith Whitwell wrote:
>
>
> Maybe VIA can provide some userspace code without putting together an
> entire driver.
>
> A handful of standalone programs that exercise the interface would help
> evaluate the interfaces and might be sufficient to serve as guide to
> some
...@via.com.tw;
benjamin...@viatech.com
Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for
upstream
On Fri, 2009-07-17 at 04:37 -0700, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
> > On Fri, Jul 17, 2009 at 4:36 PM, wrote:
> > > To wh
On Fri, 2009-07-17 at 04:37 -0700, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
> > On Fri, Jul 17, 2009 at 4:36 PM, wrote:
> > > To whom it may ceoncern:
> > >The following 3 patches are the DRM kernel module that support VIA
> > > Chorme9 GFX chipset. T
On Fri, 2009-07-17 at 13:37 +0200, Harald Welte wrote:
[...]
> 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?
It's hard to review if the interface is sane
On Fri, Jul 17, 2009 at 13:37, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
>> On Fri, Jul 17, 2009 at 4:36 PM, wrote:
>> > To whom it may ceoncern:
>> >The following 3 patches are the DRM kernel module that support VIA
>> > Chorme9 GFX chipset. They are
On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
> On Fri, Jul 17, 2009 at 4:36 PM, 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
On Fri, Jul 17, 2009 at 4:36 PM, 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 wr
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.
Thanks and Best Regards
Bruce C. Chang
49 matches
Mail list logo
