Hiding a monitor from all apps except one

ible for someone to interfere with it then, > > Dave. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/9b98a32b/attachment-0001.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

On 03/26/2014 08:08 PM, David Herrmann wrote: > Hi > > On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom > wrote: >> The master management was previously protected by the >> drm_device::struct_mutex. >> In order to avoid locking order violations in a reworked dropped master >> security check in

[Bug 76659] Display does not return from DPMS off using ATI drivers

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/27fe2547/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

-- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/c3482feb/attachment.html>

Hiding a monitor from all apps except one

c/connectors attached to them, with an X server running on that node, > that is independent of X server running on other nodes maybe, > > Dave. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/abf230bc/attachment.html>

[Bug 76320] libpciaccess requires xorg-macros when it may not be available on all target platforms (ones lacking Xorg)

, right? Using it isn't actually relying on xorg to function. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/f00bd

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

Hi On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom wrote: > The master management was previously protected by the > drm_device::struct_mutex. > In order to avoid locking order violations in a reworked dropped master > security check in the vmwgfx driver, break it out into a separate >

[PATCH 03/16] drm: Make control nodes master-less v3

Hi On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom wrote: > Like for render-nodes, there is no point in maintaining the master concept > for control nodes, so set the struct drm_file::master pointer to NULL. > > At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always >

[PATCH 04/16] drm: Improve on minor type helpers v2

Hi On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom wrote: > Add a drm_is_legacy() helper, constify argument to drm_is_render_client(), > and use / change helpers where appropriate. > > v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context. Could we avoid using "legacy" for

[PATCH] acpi: allow non-optimus setups to load vbios from acpi

There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/23339f08/attachment.html>

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

Hi Jean-Fran?ois, On Tuesday 25 March 2014 16:55:48 Jean-Francois Moine wrote: > On Mon, 24 Mar 2014 23:39:01 +0100 Laurent Pinchart wrote: > > On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote: > > > The 'slave encoder' structure of the tda998x driver asks for glue > > > between the DRM

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

TML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/8c54d5ea/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140326/b9bee745/attachment.html>

[Bug 76320] libpciaccess requires xorg-macros when it may not be available on all target platforms (ones lacking Xorg)

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/5c51ba9d/attachment.html>

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

Hi Lucas, On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach wrote: > Hi Alexandre, > > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot: >> Hi everyone, > [...] >> >> A few lines of hacks (not included here) are still needed to deal with cached >> mappings triggering external aborts

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

Am 26.03.2014 14:03, schrieb Alex Deucher: > On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig > wrote: >> From: Christian K?nig >> >> If the IB test fails we don't want to reset the card over >> and over again, just accept that it isn't working. >> >> Signed-off-by: Christian K?nig >> Cc:

[Nouveau] [PATCH] nouveau: safen up nouveau_device list usage against concurrent access

On Thu, Mar 13, 2014 at 12:05 PM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin Already said on IRC, but for posterity: Reviewed-by: Ben Skeggs > --- > nouveau/nouveau.c | 29 - > nouveau/private.h | 3 ++- > 2 files changed, 30 insertions(+), 2 deletions(-) >

[PATCH 00/16] Atomic/nuclear modeset/pageflip

ktop.org/archives/dri-devel/attachments/20140326/57872928/attachment.html>

[Nouveau] [PATCH 12/12] drm/nouveau: support for probing GK20A

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote: > Set the correct subdev/engine classes when GK20A (0xea) is probed. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 > 1 file changed, 20 insertions(+) > > diff

[PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding wrote: > On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote: >> GK20A does not embed a dedicated COPY engine and thus cannot allocate >> the copy channel that nouveau_accel_init() attempts to create. It also >> lacks any display

[PATCH 10/12] drm/nouveau/graph: add GK20A support

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote: > Add a GR device for GK20A based on NVE4, with the correct classes > definitions (GK20A's 3D class is 0xa297). > > Most of the NVE4 code can be used on GK20A, so make relevant bits of > NVE4 available to other chips as well. This will

[Nouveau] [PATCH 09/12] drm/nouveau/graph: pad firmware code at load time

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote: > Pad the microcode to a multiple of 0x40, otherwise firmware will fail to > run from non-prepadded firmware files. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 > 1 file

[PATCH 08/12] drm/nouveau/graph: enable when using external firmware

On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding wrote: > On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote: > [...] >> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c >> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c >> index 6ef8bf181b2d..f997a18f5760 100644 >>

[PATCH 00/16] Atomic/nuclear modeset/pageflip

t to scale. That said, I'd be happy to be proven wrong -- if the hypothetical atomic2 ioctl has a kernel counterpart that I'm comfortable recommending to vendors, being able to write a single generic HWC HAL would be good for Android too. -- next part -- An HTML attachment was

[Nouveau] [PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists

On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding wrote: > On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote: >> Some chips that use system memory exclusively (e.g. GK20A) do not >> expose 2 BAR regions. For them only BAR1 exists, and it should be used >> for USERD mapping. Do not

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding wrote: > On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote: >> GK20A's timer is directly attached to the system timer and cannot be >> calibrated. Skip the calibration phase on that chip since the >> corresponding registers do not

[Bug 76501] fences regression

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140326/a35c534f/attachment.html>

[Bug 76501] fences regression

went away. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/028c7fa6/attachment-0001.html>

[PATCH] drm/nouveau: don't suspend/resume display on runtime s/r

From: Dave Airlie This should ensure we don't hit a locking problem when someone wakes us up via a connector, we should never go into suspend while the display is on anyways. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +--- 1 file

[PATCH] drm/nouveau: fail runtime pm properly.

From: Dave Airlie If we were on a non-optimus device, we'd return -EINVAL, this would lead to the over engineered runtime pm system to go into an error state, subsequent get_sync's would fail, so we'd never be able to open the device again. (like really get_sync shouldn't

[Bug 76501] fences regression

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/6b086c01/attachment.html>

[PATCH] drm: Try to acquire modeset lock on panic or sysrq

Hi On Tue, Mar 25, 2014 at 1:25 PM, Thierry Reding wrote: > From: Thierry Reding > > Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc" > causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to > complain loudly during a kernel panic or sysrq processing. This is >

[PATCH v2 4/4] Documentation: drm: describing plane alpha and color blending property

Hi On Tue, Mar 25, 2014 at 3:32 PM, wrote: > From: Sagar Kamble > > v2: Added description for "src-color" and "constant-alpha" property. > > Cc: Rob Landley > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Laurent Pinchart > Cc: David Herrmann >

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

From: Christian K?nig If the IB test fails we don't want to reset the card over and over again, just accept that it isn't working. Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_ring.c | 1 + 1 file changed, 1

Hiding a monitor from all apps except one

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/ca9bc6bb/attachment.html>

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

Hi Alexandre, Am Mittwoch, den 26.03.2014, 15:33 +0900 schrieb Alexandre Courbot: > Hi Lucas, > > On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach > wrote: > > Hi Alexandre, > > > > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot: > >> Hi everyone, > > [...] > >> > >> A few lines

[PATCH 00/16] Atomic/nuclear modeset/pageflip

On Thu, Mar 20, 2014 at 03:34:19PM -0700, Greg Hackmann wrote: > On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark wrote: > > > > Hm, do you have some pointers to read up on this? I still think a more > > > elaborate fail scheme is overkill, but maybe reading a bit of android > > code > > > convinces

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

On Wed, Mar 26, 2014 at 9:50 AM, Christian K?nig wrote: > Am 26.03.2014 14:03, schrieb Alex Deucher: > >> On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig >> wrote: >>> >>> From: Christian K?nig >>> >>> If the IB test fails we don't want to reset the card over >>> and over again, just accept

[RFC] dma-buf: Implement test module

se let me know. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/8b9d4745/attachment.sig>

[PATCH v3 2/3] drm/panel: add ld9040 driver

The patch adds LD9040 parallel RGB panel driver with SPI control interface. The driver uses drm_panel framework. Signed-off-by: Andrzej Hajda --- v2: removed useless include v3: added SPI dependency to Kconfig --- drivers/gpu/drm/panel/Kconfig| 7 + drivers/gpu/drm/panel/Makefile

[PATCH] drm/nouveau: fail runtime pm properly.

On Wed, Mar 26, 2014 at 12:09 AM, Dave Airlie wrote: > From: Dave Airlie > > If we were on a non-optimus device, we'd return -EINVAL, this would > lead to the over engineered runtime pm system to go into an error > state, subsequent get_sync's would fail, so we'd never be able > to open the

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig wrote: > From: Christian K?nig > > If the IB test fails we don't want to reset the card over > and over again, just accept that it isn't working. > > Signed-off-by: Christian K?nig > Cc: stable at vger.kernel.org You might want to add the link

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Tue, Mar 25, 2014 at 06:42:13PM -0400, Mikulas Patocka wrote: > > > On Mon, 24 Mar 2014, Daniel Vetter wrote: > > > >> Like I've said the entire teardown sequence for legacy drm drivers is > > >> terminally busted, so the only hope we have is to reapply this missing > > >> duct-tape which

exynos-drm HDMI PHY configuration values

On Tue, Mar 25, 2014 at 2:52 PM, Daniel Drake wrote: > Hi Sean, > > In your commit "drm/exynos: hdmi: support extra resolutions using > drm_display_mode timings" you added several more HDMI PHY configs to > exynos-drm. Thanks for that. > > Can you explain where these magic numbers came from? >

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

https://bugzilla.kernel.org/show_bug.cgi?id=22312 --- Comment #10 from Alex Deucher --- If you are running a 3.13 or newer kernel, try appending radeon.runpm=0 to the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

https://bugzilla.kernel.org/show_bug.cgi?id=22312 --- Comment #9 from Alex Deucher --- (In reply to Chris Nystrom from comment #8) > Yes. I am having this exact error message with a live Fedora 20 DVD on a > Dell OptiPlex 780 with a PCIe ASUS Radeon R7 240 video card. The desktop > never comes

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

https://bugzilla.kernel.org/show_bug.cgi?id=22312 Chris Nystrom changed: What|Removed |Added CC||cnystrom at gmail.com --- Comment #8