Piotr Gluszenia Slawinski wrote:
There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more
Piotr Gluszenia Slawinski wrote:
> There is no point supporting companies that give you a little bit of
> information in exchange they want the support that being in a mainline
> kernel gives. Its an unfair exchange of knowledge and time, and if they
> claim they have to make a profit then it
Piotr Gluszenia Slawinski wrote:
>> There is no point supporting companies that give you a little bit of
>> information in exchange they want the support that being in a mainline
>> kernel gives. Its an unfair exchange of knowledge and time, and if they
>> claim they have to make a profit then its
-- Forwarded message --
From: Timothy Meade
Date: Thu, Jul 1, 2010 at 8:38 PM
Subject: Closed source userspace graphics drivers with an open source
kernel component
To: Saravana Kannan
Cc: LKML , dri-devel
, linux-arm-msm at vger.kernel.org,
jcrouse at codeaurora.org
On Thu, Ju
on the same GLES layer that Android uses, essentially making X
and open environments a second class citizen on modern mobile hardware.
I hope those making the decision will take this into consideration.
--
Timothy Meade (tmzt on freenode)
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100701/5ac429a2/attachment-0001.html>
There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more unfair.
also, they seem to do it
On Thu, 2010-07-01 at 20:42 -0400, Timothy Meade wrote:
> -- Forwarded message --
> Hello. I've been working with the developers on the htc-linux project
> and following the progress of Android on MSM devices closely for a few
> years. I've been excitied to see DRM/DRI replace PM
-- Forwarded message --
From: Timothy Meade
Date: Thu, Jul 1, 2010 at 8:38 PM
Subject: Closed source userspace graphics drivers with an open source
kernel component
To: Saravana Kannan
Cc: LKML , dri-devel
, linux-arm-...@vger.kernel.org,
jcro...@codeaurora.org
On Thu, Jul 1, 2
On Thu, Jul 1, 2010 at 8:18 PM, Saravana Kannan wrote:
> Dave Airlie wrote:
>
>> This is more about initial development stages. We maintain kernel
>> API/ABI for all in-tree drivers, however before we put a driver into
>> mainline, we usually need to redo the crazy interfaces that vendors
>> have
Dave Airlie wrote:
This is more about initial development stages. We maintain kernel
API/ABI for all in-tree drivers, however before we put a driver into
mainline, we usually need to redo the crazy interfaces that vendors
have come up with. Like 32/64 alignment, passing userspace addresses
into t
I thought Intel shelved Larrabee.
~ C.
On Thu, Jul 1, 2010 at 4:51 PM, Piotr Gluszenia Slawinski
wrote:
>> We are going to start to see a number of companies in the embedded
>> space submitting 3D drivers for mobile devices to the kernel. I'd like
>> to clarify my position once so they don't all
I thought Intel shelved Larrabee.
~ C.
On Thu, Jul 1, 2010 at 4:51 PM, Piotr Gluszenia Slawinski
wrote:
>> We are going to start to see a number of companies in the embedded
>> space submitting 3D drivers for mobile devices to the kernel. I'd like
>> to clarify my position once so they don't all
On Thu, Jul 01, 2010 at 10:35:34AM -0400, Alex Deucher wrote:
> On Thu, Jul 1, 2010 at 10:07 AM, Pasi K?rkk?inen wrote:
> > On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi K?rkk?inen wrote:
> >> > >>
> >> > >> I am not sure your patch is right, my guess is that devices field of
> >> > >> radeon con
We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my position once so they don't all come asking the same
questions.
one of options for future would be equipping gpu's with additional
processing fo
Dave Airlie wrote:
> This is more about initial development stages. We maintain kernel
> API/ABI for all in-tree drivers, however before we put a driver into
> mainline, we usually need to redo the crazy interfaces that vendors
> have come up with. Like 32/64 alignment, passing userspace addresses
On Fri, Jul 2, 2010 at 10:08 AM, Daniel Walker wrote:
> On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:
>
>> > Oh, man .. It seems like any driver model that straddles userspace and
>> > kernel space is kind of asking for trouble (my opinion anyway)..
>> >
>> > Would you accept a userspace c
On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:
> > Oh, man .. It seems like any driver model that straddles userspace and
> > kernel space is kind of asking for trouble (my opinion anyway)..
> >
> > Would you accept a userspace component that supported some subset of the
> > features ? You
On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:
> > Oh, man .. It seems like any driver model that straddles userspace and
> > kernel space is kind of asking for trouble (my opinion anyway)..
> >
> > Would you accept a userspace component that supported some subset of the
> > features ? You
On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi K?rkk?inen wrote:
> > >>
> > >> I am not sure your patch is right, my guess is that devices field of
> > >> radeon connector structure btw the HDMI & DVI connector are different
> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's no
On Mon, Jun 21, 2010 at 09:17:14PM +0300, Pasi K?rkk?inen wrote:
> > >
> > > I am not sure your patch is right, my guess is that devices field of
> > > radeon connector structure btw the HDMI & DVI connector are different
> > > and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions(+), 1
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h| 37
From: Ben Skeggs
Original behaviour will be preserved for drivers that don't implement
disable() hooks for an encoder.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/drm_crtc_helper.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions(+), 1
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h| 37
On Fri, Jul 2, 2010 at 9:29 AM, Daniel Walker wrote:
> On Fri, 2010-07-02 at 08:57 +1000, Dave Airlie wrote:
>> On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker wrote:
>> > On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
>> >> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
>> >> > Now thi
https://bugs.freedesktop.org/show_bug.cgi?id=28876
--- Comment #2 from Yann Dirson 2010-07-01 16:33:46 PDT ---
Created an attachment (id=36668)
--> (https://bugs.freedesktop.org/attachment.cgi?id=36668)
Xorg log file for 2nd X server (the one that triggers the lockup)
I can now reproduce the bu
https://bugs.freedesktop.org/show_bug.cgi?id=28876
--- Comment #2 from Yann Dirson 2010-07-01 16:33:46 PDT
---
Created an attachment (id=36668)
--> (https://bugs.freedesktop.org/attachment.cgi?id=36668)
Xorg log file for 2nd X server (the one that triggers the lockup)
I can now reproduce the b
On Fri, 2010-07-02 at 08:57 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker wrote:
> > On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> >> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
> >> > Now this is just my opinion as maintainer of the drm, and doesn't
>
On Fri, 2010-07-02 at 08:57 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker
> wrote:
> > On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> >> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
> >> > Now this is just my opinion as maintainer of the drm, and doesn'
On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
> > Now this is just my opinion as maintainer of the drm, and doesn't
> > reflect anyone or any official policy, I've also no idea if Linus
> > agrees or not.
> >
> > We are going to start to
On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker wrote:
> On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
>> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
>> > Now this is just my opinion as maintainer of the drm, and doesn't
>> > reflect anyone or any official policy, I've also no idea i
https://bugs.freedesktop.org/show_bug.cgi?id=28430
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|dri-de...@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=28509
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|dri-de...@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=26326
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|dri-de...@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=28430
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbarnes at virtuousgeek.org|dri-devel at
lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=28509
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbarnes at virtuousgeek.org|dri-devel at
lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=26326
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbarnes at virtuousgeek.org|dri-devel at
lists.freedesktop
On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
> > Now this is just my opinion as maintainer of the drm, and doesn't
> > reflect anyone or any official policy, I've also no idea if Linus
> > agrees or not.
> >
> > We are going to start to
On Wed, 23 Jun 2010 13:19:55 +0200, Dan Carpenter wrote:
> intel_cleanup_ring_buffer() calls drm_gem_object_unreference() (as
> opposed to drm_gem_object_unreference_unlocked()) so it needs to be
> called with "struct_mutex" held. If we don't hold the lock, it triggers
> a BUG_ON(!mutex_is_locked
n-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100701/c3c052c2/attachment.pgp>
On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie wrote:
> Now this is just my opinion as maintainer of the drm, and doesn't
> reflect anyone or any official policy, I've also no idea if Linus
> agrees or not.
>
> We are going to start to see a number of companies in the embedded
> space submitting 3D d
Now this is just my opinion as maintainer of the drm, and doesn't
reflect anyone or any official policy, I've also no idea if Linus
agrees or not.
We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my
https://bugs.freedesktop.org/show_bug.cgi?id=28876
--- Comment #1 from Yann Dirson 2010-07-01 14:46:07 PDT ---
And the relevant boot-time kernel logs are as follows (eg. shows KMS
initialized):
Jun 30 18:35:40 home kernel: [ 15.720780] pci :01:05.0: PCI INT A -> GSI
18 (level, low) -> IRQ
https://bugs.freedesktop.org/show_bug.cgi?id=28876
--- Comment #1 from Yann Dirson 2010-07-01 14:46:07 PDT
---
And the relevant boot-time kernel logs are as follows (eg. shows KMS
initialized):
Jun 30 18:35:40 home kernel: [ 15.720780] pci :01:05.0: PCI INT A -> GSI
18 (level, low) -> IRQ
https://bugs.freedesktop.org/show_bug.cgi?id=28876
Summary: [radeon HD4250] Frequent lockups while screen locked
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critica
https://bugs.freedesktop.org/show_bug.cgi?id=28876
Summary: [radeon HD4250] Frequent lockups while screen locked
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critica
https://bugs.freedesktop.org/show_bug.cgi?id=27541
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|dri-de...@lists.freedesktop
On Thu, Jul 1, 2010 at 1:03 PM, Jordan Crouse wrote:
> For about a year and a half, the Qualcomm Linux team has been working to
> support
> the OpenGL ES 3D core in the Snapdragon processor. The hardware made its
> debut
> in the Nexus One and has subsequently been used in a few other commercial
https://bugs.freedesktop.org/show_bug.cgi?id=27541
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbarnes at virtuousgeek.org|dri-devel at
lists.freedesktop
On Thu, Jul 1, 2010 at 1:03 PM, Jordan Crouse wrote:
> For about a year and a half, the Qualcomm Linux team has been working to
> support
> the OpenGL ES 3D core in the Snapdragon processor. ?The hardware made its
> debut
> in the Nexus One and has subsequently been used in a few other commercial
https://bugs.freedesktop.org/show_bug.cgi?id=27563
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|dri-de...@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=27563
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbarnes at virtuousgeek.org|dri-devel at
lists.freedesktop
For about a year and a half, the Qualcomm Linux team has been working to support
the OpenGL ES 3D core in the Snapdragon processor. The hardware made its debut
in the Nexus One and has subsequently been used in a few other commercial
products since then. To support the 3D GPU we wrote a kernel ba
For about a year and a half, the Qualcomm Linux team has been working to support
the OpenGL ES 3D core in the Snapdragon processor. The hardware made its debut
in the Nexus One and has subsequently been used in a few other commercial
products since then. To support the 3D GPU we wrote a kernel b
https://bugs.freedesktop.org/show_bug.cgi?id=10471
--- Comment #2 from Chris Rankin 2010-07-01 12:55:51
PDT ---
[patch 079/149] drm/radeon: r100/r200 ums: block ability for userspace app to
trash 0 page and beyond
http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00405.html
Hmm, "badness"
https://bugs.freedesktop.org/show_bug.cgi?id=10471
--- Comment #2 from Chris Rankin 2010-07-01
12:55:51 PDT ---
[patch 079/149] drm/radeon: r100/r200 ums: block ability for userspace app to
trash 0 page and beyond
http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00405.html
Hmm, "badness"
https://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #10 from Chris Rankin 2010-07-01 12:53:39
PDT ---
I've just noticed this patch being added to 2.6.32.x:
[patch 079/149] drm/radeon: r100/r200 ums: block ability for userspace app to
trash 0 page and beyond
http://lkml.indiana.edu/h
https://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #10 from Chris Rankin 2010-07-01
12:53:39 PDT ---
I've just noticed this patch being added to 2.6.32.x:
[patch 079/149] drm/radeon: r100/r200 ums: block ability for userspace app to
trash 0 page and beyond
http://lkml.indiana.edu/h
On Thu, Jul 1, 2010 at 10:07 AM, Pasi K?rkk?inen wrote:
> On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi K?rkk?inen wrote:
>> > >>
>> > >> I am not sure your patch is right, my guess is that devices field of
>> > >> radeon connector structure btw the HDMI & DVI connector are different
>> > >> and
Connectors with a shared ddc line can be connected to different
encoders.
Reported by Pasi K?rkk?inen on dri-devel
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_connectors.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/dri
On Thu, Jul 1, 2010 at 2:49 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Original behaviour will be preserved for drivers that don't implement
> disable() hooks for an encoder.
>
> Signed-off-by: Ben Skeggs
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/drm_crtc_helper.c | ? 22 ++
On Thu, Jul 01, 2010 at 10:35:34AM -0400, Alex Deucher wrote:
> On Thu, Jul 1, 2010 at 10:07 AM, Pasi Kärkkäinen wrote:
> > On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi Kärkkäinen wrote:
> >> > >>
> >> > >> I am not sure your patch is right, my guess is that devices field of
> >> > >> radeon con
On Thu, Jul 1, 2010 at 10:07 AM, Pasi Kärkkäinen wrote:
> On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi Kärkkäinen wrote:
>> > >>
>> > >> I am not sure your patch is right, my guess is that devices field of
>> > >> radeon connector structure btw the HDMI & DVI connector are different
>> > >> and
Connectors with a shared ddc line can be connected to different
encoders.
Reported by Pasi Kärkkäinen on dri-devel
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_connectors.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/driver
On Thu, Jul 1, 2010 at 2:49 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Original behaviour will be preserved for drivers that don't implement
> disable() hooks for an encoder.
>
> Signed-off-by: Ben Skeggs
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 22 ++
On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi Kärkkäinen wrote:
> > >>
> > >> I am not sure your patch is right, my guess is that devices field of
> > >> radeon connector structure btw the HDMI & DVI connector are different
> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's no
On Mon, Jun 21, 2010 at 09:17:14PM +0300, Pasi Kärkkäinen wrote:
> > >
> > > I am not sure your patch is right, my guess is that devices field of
> > > radeon connector structure btw the HDMI & DVI connector are different
> > > and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
https://bugs.freedesktop.org/show_bug.cgi?id=28869
Summary: [r300g] Tiny and Big doesn't run
Product: Mesa
Version: git
Platform: Other
URL: http://www.tinyandbig.com/download/
OS/Version: All
Status: NEW
Sever
https://bugs.freedesktop.org/show_bug.cgi?id=28869
Summary: [r300g] Tiny and Big doesn't run
Product: Mesa
Version: git
Platform: Other
URL: http://www.tinyandbig.com/download/
OS/Version: All
Status: NEW
Sever
Okay same tree as yesterday, with the fix for the regression Markus
reported (good fast work by Alex), fix for resume on one of my laptops,
Rafael's resume fix, and a dynpm fix that I missed.
Otherwise:
one fb layer fix in a flag I introduced,
the rest are drm fixes:
radeon fixes: the larger o
https://bugs.freedesktop.org/show_bug.cgi?id=5901
Bernhard Rosenkraenzer changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=5901
Bernhard Rosenkraenzer changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: ht
75 matches
Mail list logo
