On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen
> wrote:
>
> > 2) panel drivers, handles panel specific things. Each panel may support
> > custom commands and features, for which we need a dedicated driver. And
> > this driver is not p
> Okay, I see your problem. It's a bit strange you don't have acceleration. I
The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.
At some point I'll add hardware scrolling however by using the GTT to
implemnent
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat
wrote:
> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally
> acceptable
> would be to split it of, probably as a standalone module and s
ation/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/c776a516/attachment.pgp>
For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
pagefault_disable/_enable. The i915 driver relies on the map
actually being atomic, otherwise it can deadlock with it's own
pagefault handler in the gtt pwrite fastpath.
This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
t
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen
wrote:
> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the
I've got this nice patch from Akshay Joshi that removes almost all of
the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
going to go stale and be useless; if I merge it only to drm-intel-next,
it will be the source of endless conflicts.
However, it's a huge patch (yes, the co
> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.
GMA500 is basically a 2D or dumb frame buffer setup but with a lot of
rather complicated output and me
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built,
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
Not sure the CS ioctl can actually run concurrently with suspend/resume, but
might be better safe than sorry?
drivers/gpu/drm/radeon/radeon_device.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu
From: Michel D?nzer
This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.
This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're
> What is your problem with discontigous framebuffers? (I assume discontigous
> refers to the pages the framebuffer is composed of)
> Sounds to me like you should implement your own fb_mmap and either map it
> contigous to screen_base or implement your own fb_read/write.
> In theory you could even
> Well, I rather think that the fb API is more user centric to allow every
> program
> to use it directly in contrast to the KMS/DRM API which aims to support every
> feature the hardware has. For this the fb API should not change much, but I
> understand some additions were needed for some specia
On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API. ?The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware
, some are writable
(like overscan values).
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/731f7f2a/attachment.pgp>
On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your ow
On 09/15/2011 06:58 PM, Alan Cox wrote:
>> Well, I rather think that the fb API is more user centric to allow every
>> program
>> to use it directly in contrast to the KMS/DRM API which aims to support every
>> feature the hardware has. For this the fb API should not change much, but I
>> understa
On 09/15/2011 05:52 PM, Alex Deucher wrote:
> On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
> wrote:
>> On 09/15/2011 03:50 PM, Keith Packard wrote:
>>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen >> ti.com> wrote:
>>>
1) It's part of DRM, so it doesn't help fb or v4l2 dri
Hello, Konrad Rzeszutek Wilk.
Your review and comments are so very detail. it was very helpful. thank you
again.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Thursday, September 15, 2011 6:42 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/af0bbef6/attachment-0001.pgp>
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
> wrote:
>
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
>
> Jesse Barnes has put together a proposal much
On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
> ?* The De
> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.
There are aspects of the fb c
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is buil
From: Rob Clark
This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 87 +
include/drm/drmP.h
Hi Alan,
On 09/15/2011 05:18 PM, Alan Cox wrote:
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastru
2011/9/15 Michel D?nzer :
> From: Michel D?nzer
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated because the GPU reset can be triggered
On Thu, Sep 15, 2011 at 22:25, Alex Deucher wrote:
> On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten wrote:
>> I hope you find this adventure interesting, and I hope you
>> provide me with some insight.
>>
>> Recently, I booted my computer, a Dell Latitude D810 that has a
>> Radeon Mobility x600
On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4
Hi,
I am the main developer of the TimeGraph GPU command scheduler, which was
presented at XDC 2011 in Chicago a few days ago.
Please let me propose this approach to scheduling GPU-accelerated processes
with DRM.
This GPU scheduler will help to prioritize and isolate multiple
GPU-accelerated proc
Hi,
I am the main developer of the TimeGraph GPU command scheduler, which was
presented at XDC 2011 in Chicago a few days ago.
Please let me propose this approach to scheduling GPU-accelerated processes
with DRM.
This GPU scheduler will help to prioritize and isolate multiple
GPU-accelerated proc
From: Rob Clark
This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 87 +
include/drm/drmP.h
On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 06:58 PM, Alan Cox wrote:
>>> Well, I rather think that the fb API is more user centric to allow every
>>> program
>>> to use it directly in contrast to the KMS/DRM API which aims to support
>>> every
>>> feature t
https://bugs.freedesktop.org/show_bug.cgi?id=22030
--- Comment #6 from Stefan Dösinger 2011-09-15
15:38:26 PDT ---
Yes, I did, and I did some retesting of the r200 driver a few days ago(See bug
27069, where I complained about performance 2 years ago and still complain
about performance today).
https://bugs.freedesktop.org/show_bug.cgi?id=22030
--- Comment #6 from Stefan D?singer 2011-09-15
15:38:26 PDT ---
Yes, I did, and I did some retesting of the r200 driver a few days ago(See bug
27069, where I complained about performance 2 years ago and still complain
about performance today).
On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
> * The De
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe sh
> Okay, I see your problem. It's a bit strange you don't have acceleration. I
The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.
At some point I'll add hardware scrolling however by using the GTT to
implemnent
2011/9/15 Michel Dänzer :
> From: Michel Dänzer
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated because the GPU reset can be triggered
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
wrote:
> On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
>> While the DRM has historically targeted 3D acceleration, that is not a
>> requirement to use the DRM KMS modesetting API. ?The current fb API
>> has no concept of display controllers
On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 03:50 PM, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>>> the plan is to make DRM the core
Hi, Rob.
> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Thursday, September 15, 2011 4:42 AM
> To: Inki Dae
> Cc: linaro-dev at lists.linaro.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] RFC: omapdrm DRM
On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen
wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the c
fb code in the kernel.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/8e86dad1/attachment.pgp>
For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
pagefault_disable/_enable. The i915 driver relies on the map
actually being atomic, otherwise it can deadlock with it's own
pagefault handler in the gtt pwrite fastpath.
This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
t
On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your ow
On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 06:58 PM, Alan Cox wrote:
>>> Well, I rather think that the fb API is more user centric to allow every
>>> program
>>> to use it directly in contrast to the KMS/DRM API which aims to support
>>> every
>>> feature t
> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.
GMA500 is basically a 2D or dumb frame buffer setup but with a lot of
rather complicated output and me
On 09/15/2011 06:58 PM, Alan Cox wrote:
>> Well, I rather think that the fb API is more user centric to allow every
>> program
>> to use it directly in contrast to the KMS/DRM API which aims to support every
>> feature the hardware has. For this the fb API should not change much, but I
>> understa
https://bugs.freedesktop.org/show_bug.cgi?id=32326
--- Comment #6 from Matt Turner 2011-09-15 12:12:36 PDT ---
(In reply to comment #5)
> Created an attachment (id=41039)
View: https://bugs.freedesktop.org/attachment.cgi?id=41039
Review: https://bugs.freedesktop.org/review?bug=32326&attachment=
https://bugs.freedesktop.org/show_bug.cgi?id=32326
--- Comment #6 from Matt Turner 2011-09-15 12:12:36 PDT
---
(In reply to comment #5)
> Created an attachment (id=41039)
View: https://bugs.freedesktop.org/attachment.cgi?id=41039
Review: https://bugs.freedesktop.org/review?bug=32326&attachment
https://bugs.freedesktop.org/show_bug.cgi?id=22030
--- Comment #5 from Matt Turner 2011-09-15 12:10:31 PDT ---
Have you had access to that computer again any time in the last two years? :)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=22030
--- Comment #5 from Matt Turner 2011-09-15 12:10:31 PDT
---
Have you had access to that computer again any time in the last two years? :)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
> What is your problem with discontigous framebuffers? (I assume discontigous
> refers to the pages the framebuffer is composed of)
> Sounds to me like you should implement your own fb_mmap and either map it
> contigous to screen_base or implement your own fb_read/write.
> In theory you could even
> Well, I rather think that the fb API is more user centric to allow every
> program
> to use it directly in contrast to the KMS/DRM API which aims to support every
> feature the hardware has. For this the fb API should not change much, but I
> understand some additions were needed for some specia
On 09/15/2011 05:52 PM, Alex Deucher wrote:
> On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
> wrote:
>> On 09/15/2011 03:50 PM, Keith Packard wrote:
>>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
>>> wrote:
>>>
1) It's part of DRM, so it doesn't help fb or v4l2 drivers.
On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
>> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the core Li
Hi Tomi,
On Thu, Sep 15, 2011 at 9:07 PM, Tomi Valkeinen wrote:
> Hi,
>
> I am the author of OMAP display driver, and while developing it I've
> often felt that there's something missing in Linux's display area. I've
> been planning to write a post about this for a few years already, but I
> neve
Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a écrit :
> On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault
> wrote:
> Non-text part: multipart/mixed
> > Hello,
> >
> > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > E6420, but dual head is broken. Here is the scen
From: Michel Dänzer
This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.
This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Not sure the CS ioctl can actually run concurrently with suspend/resume, but
might be better safe than sorry?
drivers/gpu/drm/radeon/radeon_device.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu
On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat
wrote:
> Interesting that this comes from the people that pushed the latest mode
> setting
> code into the kernel. But I don't think that this will happen, the exposed
> user
> interfaces will be around for decades and the infrastru
Wasn't there a driver for qemu cirrus "hardware"?
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historical
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requ
freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/10a16b54/attachment-0001.htm>
etail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/55e6a43e/attachment.htm>
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
wrote:
> On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
>> While the DRM has historically targeted 3D acceleration, that is not a
>> requirement to use the DRM KMS modesetting API. The current fb API
>> has no concept of display controllers
On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API. The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware
On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 03:50 PM, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
>> wrote:
>>
>>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>>> the plan is to make DRM the core Linux
ith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/99ece45c/attachment.pgp>
Hi Alan,
On 09/15/2011 05:18 PM, Alan Cox wrote:
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastru
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built,
Hi, Thomas.
> -Original Message-
> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
> Sent: Wednesday, September 14, 2011 4:57 PM
> To: Inki Dae
> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
> linux-
> arm-kernel at lists.infradead.org; dri-devel at lis
> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.
There are aspects of the fb c
On 09/15/2011 03:20 AM, Inki Dae wrote:
> Hi, Thomas.
>
>
>> -Original Message-
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Wednesday, September 14, 2011 4:57 PM
>> To: Inki Dae
>> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
>> linux
On Thu, Sep 15, 2011 at 06:37:39PM +0900, Inki Dae wrote:
> Hello, Konrad Rzeszutek Wilk.
>
> Your review and comments are so very detail. it was very helpful. thank you
> again.
.. snip ..
> > > + /* FIXME: error check */
> >
> > You might as well do it now - before you do the next post
On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4
Samuel Thibault, le Thu 15 Sep 2011 09:41:06 +0200, a ?crit :
> Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> > On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault > ens-lyon.org> wrote:
> > Non-text part: multipart/mixed
> > > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is buil
.
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/628a25f8/attachment.pgp>
Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault ens-lyon.org> wrote:
> Non-text part: multipart/mixed
> > Hello,
> >
> > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > E6420, but dual head is broken. Here
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/e53b1005/attachment.pgp>
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
wrote:
> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.
I'd like to think we could
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
> wrote:
>
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
>
> Jesse Barnes has put together a proposal much
On Thu, Sep 15, 2011 at 6:53 AM, Rob Clark wrote:
> On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom
> wrote:
>>
>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>> + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>> samsung_drm_gem_create_ioctl,
>> + ?
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
wrote:
> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is pretty
On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault
wrote:
> At home only. At work, with a different VGA screen, I'm still getting
> the issue.
You're still having a problem with the LVDS screen at work with FBC
disabled? Can you send along a kernel log with drm.debug=5?
--
keith.pack...@inte
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe sh
https://bugs.freedesktop.org/show_bug.cgi?id=40904
Summary: Radeon 9100 (R200): GPU lockup using blender
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority
https://bugs.freedesktop.org/show_bug.cgi?id=40904
Summary: Radeon 9100 (R200): GPU lockup using blender
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority
On Sep 15, 2011, at 12:54 AM, Francisco Jerez wrote:
> Mario Kleiner writes:
>
>> On Sep 14, 2011, at 6:02 PM, Keith Packard wrote:
>>
>>> On Wed, 14 Sep 2011 10:05:29 -0500, Jesse Barnes
>>> wrote:
>>>
Ah thanks Mario, I blame Keith. :p I agree we should integrate
this
patch
Hello,
I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
E6420, but dual head is broken. Here is the scenario:
- Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
text console fine.
- Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
odd
On 09/15/2011 03:20 AM, Inki Dae wrote:
Hi, Thomas.
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Wednesday, September 14, 2011 4:57 PM
To: Inki Dae
Cc: 'Rob Clark'; kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
arm-ker...@lists.infradead.o
this helps them already.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/b38c039f/attachment.pgp>
94 matches
Mail list logo
