Proposal for a low-level Linux display framework

> 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

Proposal for a low-level Linux display framework

Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/c776a516/attachment.pgp>

[PATCH] io-mapping: ensure io_mapping_map_atomic _is_ atomic

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

Proposal for a low-level Linux display framework

> 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

Proposal for a low-level Linux display framework

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

[PATCH 2/2] drm/radeon: Hold the CS mutex across suspend/resume.

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(-)

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

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

Proposal for a low-level Linux display framework

> 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

Proposal for a low-level Linux display framework

> 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

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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>

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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 >>

Proposal for a low-level Linux display framework

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

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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;

Whitespace cleanups in drm/i915

ed... 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>

Proposal for a low-level Linux display framework

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

Curious experiences with a Radeon on the fritz

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

Proposal for a low-level Linux display framework

> 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

Proposal for a low-level Linux display framework

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

[PATCH] drm/gem: add functions to get/put pages

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 +

Proposal for a low-level Linux display framework

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 >>

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

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

Proposal for a low-level Linux display framework

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

Proposal for a DRM-compliant GPU command scheduler

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

Proposal for a low-level Linux display framework

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

[Bug 22030] r200: Texture loads fail randomly

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).

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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

[PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms

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

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

-- 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>

[Bug 32326] [R200] DRM version check only looks at minor number.

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=41039 >

[Bug 22030] r200: Texture loads fail randomly

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

Proposal for a low-level Linux display framework

esktop.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>

Proposal for a low-level Linux display framework

e=Matt_Turner.tar.gz=2= > 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>

Proposal for a low-level Linux display framework

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>

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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; >>

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

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

Proposal for a low-level Linux display framework

e Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/628a25f8/attachment.pgp>

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

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

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

ackard 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>

[Linaro-mm-sig] [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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, >> +

[Bug 40904] New: Radeon 9100 (R200): GPU lockup using blender

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

[PATCH v2 4/5] DRI2: Expose API to set drawable swap limit.

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

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

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

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

ady. -- 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>

Re: [BUG] drm/radeon: locking problems with page_flip

On 09-13 11:29, Michel Dänzer wrote: On Die, 2011-09-13 at 05:49 +0200, Witold Baryluk wrote: I yeasterday discovered pretty nasty issue in radeon / drm code, and page_flip locking code on my ThinkPad T43. Does the patch below fix the problem? From

Re: [Linaro-mm-sig] [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

On Thu, Sep 15, 2011 at 6:53 AM, Rob Clark robdcl...@gmail.com wrote: On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom tho...@shipmail.org wrote: +static struct drm_ioctl_desc samsung_ioctls[] = { +       DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE, samsung_drm_gem_create_ioctl, +                  

Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

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-

[Bug 40904] New: Radeon 9100 (R200): GPU lockup using blender

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

Proposal for a low-level Linux display framework

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

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault samuel.thiba...@ens-lyon.org 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

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com 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

Re: Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote: On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com 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

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@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 Linux display framework, upon which everything else is built, and fb and v4l2 are changed to use DRM. I'd

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 10:50:32 -0500 Keith Packard kei...@keithp.com wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@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 Linux display framework, upon

Re: Proposal for a low-level Linux display framework

On 09/15/2011 03:50 PM, Keith Packard wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@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 Linux display framework, upon which everything else is built,

Re: Proposal for a low-level Linux display framework

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 code

Re: Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@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 Linux display framework, upon which everything

Re: Proposal for a low-level Linux display framework

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 infrastructure

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat florianschandi...@gmx.de wrote: On 09/15/2011 03:50 PM, Keith Packard wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com wrote: 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if the

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com 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

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com 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

Re: Proposal for a low-level Linux display framework

Sending from a mobile, pardon my terseness. ~ C. On Sep 15, 2011 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com wrote: While the DRM has

Re: Proposal for a low-level Linux display framework

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 alexdeuc...@gmail.com wrote: On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Thu, Sep 15, 2011 at 19:52, Alex Deucher

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat florianschandi...@gmx.de 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

[PATCH 2/2] drm/radeon: Hold the CS mutex across suspend/resume.

From: Michel Dänzer michel.daen...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- 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

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

From: Michel Dänzer michel.daen...@amd.com 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

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a écrit : On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault samuel.thiba...@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

Re: Proposal for a low-level Linux display framework

Hi Tomi, On Thu, Sep 15, 2011 at 9:07 PM, Tomi Valkeinen tomi.valkei...@ti.com 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

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com wrote: 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if the

Re: Proposal for a low-level Linux display framework

On 09/15/2011 05:52 PM, Alex Deucher wrote: On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat florianschandi...@gmx.de wrote: On 09/15/2011 03:50 PM, Keith Packard wrote: On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com wrote: 1) It's part of DRM, so it

Re: Proposal for a low-level Linux display framework

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 special

Re: Proposal for a low-level Linux display framework

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 have

[Bug 22030] r200: Texture loads fail randomly

https://bugs.freedesktop.org/show_bug.cgi?id=22030 --- Comment #5 from Matt Turner matts...@gmail.com 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

[Bug 32326] [R200] DRM version check only looks at minor number.

https://bugs.freedesktop.org/show_bug.cgi?id=32326 --- Comment #6 from Matt Turner matts...@gmail.com 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:

Re: Proposal for a low-level Linux display framework

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 understand some

Re: Proposal for a low-level Linux display framework

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

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat florianschandi...@gmx.de 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

Re: Proposal for a low-level Linux display framework

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 own

[PATCH] io-mapping: ensure io_mapping_map_atomic _is_ atomic

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

Re: [PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

2011/9/15 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer michel.daen...@amd.com 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

Re: Curious experiences with a Radeon on the fritz

On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten mfwit...@gmail.com 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:

[Bug 22030] r200: Texture loads fail randomly

https://bugs.freedesktop.org/show_bug.cgi?id=22030 --- Comment #6 from Stefan Dösinger stefandoesin...@gmx.at 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

[PATCH] drm/gem: add functions to get/put pages

From: Rob Clark r...@ti.com 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 r...@ti.com --- drivers/gpu/drm/drm_gem.c | 87

Proposal for a DRM-compliant GPU command scheduler

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

Re: Curious experiences with a Radeon on the fritz

On Thu, Sep 15, 2011 at 22:25, Alex Deucher alexdeuc...@gmail.com wrote: On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten mfwit...@gmail.com 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

Whitespace cleanups in drm/i915

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

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen tomi.valkei...@ti.com 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

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat florianschandi...@gmx.de 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