dri-devel April 2018

dri-devel@lists.freedesktop.org

267 participants
1852 discussions

[PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth
by Peter Rosin 03 Apr '18

03 Apr '18

I have an sama5d31-based system with 64MB of memory and a 1920x1080 LVDS display wired for 16-bpp. When I enable legacy fbdev support, the contiguous memory allocator invariably fails with the order-11 allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never make any good use of RGB888, so that is a wasted attempt anyway that would also waste precious memory should it succeed. Sure, I could rewrite user-space to go directly to KMS etc, and that makes the (attempted) order-11 allocation go away, replacing it with one order-10 allocation per application restart for a 1920x1080@16-bpp buffer (<4MB). But after a few restarts, order-10 allocations start to fail as well, which is only to be expected AFAIU. So, I'd rather not change user-space (which was originally written to target a smaller display) so that I at the same time get the benefit of an early pre-allocated fbdev frame-buffer that can be reused over and over. But to do that I need to tell the driver that 16-bpp is the preferred depth. Add a module parameter to do just that. Signed-off-by: Peter Rosin <peda(a)axentia.se> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) I found some inspiration regarding naming and implementation here: https://patchwork.kernel.org/patch/9848631/ I have found no feedback on that patch though, which makes me wonder if I'm perhaps barking up the wronig tree? Cheers, Peter diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index c1ea5c36b006..f0148627c221 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -29,6 +29,11 @@ #define ATMEL_HLCDC_LAYER_IRQS_OFFSET 8 +static int atmel_hlcdc_preferred_depth __read_mostly; + +MODULE_PARM_DESC(preferreddepth, "Set preferred bpp"); +module_param_named(preferreddepth, atmel_hlcdc_preferred_depth, int, 0400); + static const struct atmel_hlcdc_layer_desc atmel_hlcdc_at91sam9n12_layers[] = { { .name = "base", @@ -590,6 +595,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev) dev->mode_config.min_height = dc->desc->min_height; dev->mode_config.max_width = dc->desc->max_width; dev->mode_config.max_height = dc->desc->max_height; + dev->mode_config.preferred_depth = 24; dev->mode_config.funcs = &mode_config_funcs; return 0; @@ -658,7 +664,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev) platform_set_drvdata(pdev, dev); - drm_fb_cma_fbdev_init(dev, 24, 0); + drm_fb_cma_fbdev_init(dev, atmel_hlcdc_preferred_depth, 0); drm_kms_helper_poll_init(dev); @@ -756,6 +762,16 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev) struct drm_device *ddev; int ret; + switch (atmel_hlcdc_preferred_depth) { + case 0: /* driver default */ + case 8: + case 16: + case 24: + break; + default: + return -EINVAL; + } + ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev); if (IS_ERR(ddev)) return PTR_ERR(ddev); -- 2.11.0

3 7

[PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend
by Oleksandr Andrushchenko 03 Apr '18

03 Apr '18

From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Resending with even more checkpatch code-style fixes. Hello! Boris/Daniel, I put your R-b tags, so please do let me know if this is not acceptable, so I remove the tags. This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol from include/xen/interface/io/displif.h [2]. Accompanying backend [3] is implemented as a user-space application and its helper library [4], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [5]. ******************************************************************************* * Driver limitations ******************************************************************************* 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend allocated buffers) below are not supported at the same time. 2. Only primary plane without additional properties is supported. 3. Only one video mode supported which resolution is configured via XenStore. 4. All CRTCs operate at fixed frequency of 60Hz. ******************************************************************************* * Driver modes of operation in terms of display buffers used ******************************************************************************* Depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. ******************************************************************************* * 1. Buffers allocated by the frontend driver. ******************************************************************************* The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. ******************************************************************************* * 2. Buffers allocated by the backend ******************************************************************************* This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. I would like to thank at least, but not at last the following people/communities who helped this driver to happen ;) 1. My team at EPAM for continuous support 2. Xen community for answering tons of questions on different modes of operation of the driver with respect to virtualized environment. 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] Changes since v5: ******************************************************************************* - fixed most of scripts/checkpatch.pl warnings Changes since v4: ******************************************************************************* - updated the driver after "drm/simple-kms-helper: Plumb plane state to the enable hook" [14] - made display_mode_valid static - fixed page leak on event channel error path - changed title of the documentation to match the rest of the drivers - removed from the series the patch from Noralf Trønnes [12] as it was sent out as a standalone one Changes since v3: ******************************************************************************* - no changes to Xen related code (shared buffer handling, event channels etc.), but minor changes to xenbus_driver state machine due to re-worked unplug implementation: additional state checks added - re-worked dumb creation code to fix race condition (drm_gem_handle_create) - use drm_dev_{enter|exit} to protect code which must not run when unplugged - re-work unplug code to fully support "zombie" DRM devices on backend disconnect - implement a dedicated page flip time-out worker, remove logic from connector detect callback - move mode_valid from drm_connector_helper_funcs to drm_simple_display_pipe_funcs - use drm_gem_object_put_unlocked instead of obsolete drm_gem_object_unreference_unlocked - minor cleanups Changes since v2: ******************************************************************************* - no changes to Xen related code (shared buffer handling, event channels etc.) - rework DRM driver release with hotplug (Daniel) - squash xen_drm_front and xen_drm_front_drv as they depend on each other too heavily now - remove platform driver and instantiate DRM device from xenbus driver directly - have serializing mutex per connector, not a single one, so we don't introduce a bottle neck for multiple connectors - minor comments addressed (Daniel) Changes since v1: ******************************************************************************* - use SPDX license identifier, set license to GPLv2 OR MIT - changed midlayers to direct function calls, removed: - front_ops - gem_ops - renamed xenbus_driver callbacks to align with exisitng PV drivers - re-worked backend error handling with connector hotplug uevents - removed vblank handling so user-space doesn't have an impression we really support that - directly use front's mode_set in display enable/disable - removed BUG_ON, error handling implemented - moved driver documentation into Documentation/gpu - other comments from Xen community addressed (Boris and Juergen) - squashed Xen and DRM patches for better interrconnection visibility - for your convenience driver is available at [11] Thank you, Oleksandr Andrushchenko [1] https://wiki.xen.org/wiki/Paravirtualization_(PV)#PV_IO_Drivers [2] https://elixir.bootlin.com/linux/v4.16-rc2/source/include/xen/interface/io/… [3] https://github.com/xen-troops/displ_be [4] https://github.com/xen-troops/libxenbe [5] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in… [6] https://lists.freedesktop.org/archives/dri-devel/2017-March/136038.html [7] https://www.spinics.net/lists/dri-devel/msg164102.html [8] https://www.spinics.net/lists/dri-devel/msg164463.html [9] https://patchwork.freedesktop.org/series/38073/ [10] https://patchwork.freedesktop.org/series/38139/ [11] https://github.com/andr2000/linux/commits/drm_tip_pv_drm_v2 [12] https://patchwork.freedesktop.org/patch/175779/ [13] https://www.spinics.net/lists/dri-devel/msg170453.html [14] https://patchwork.freedesktop.org/patch/212321/ Oleksandr Andrushchenko (1): drm/xen-front: Add support for Xen PV display frontend Documentation/gpu/drivers.rst | 1 + Documentation/gpu/xen-front.rst | 43 ++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/xen/Kconfig | 30 + drivers/gpu/drm/xen/Makefile | 16 + drivers/gpu/drm/xen/xen_drm_front.c | 882 ++++++++++++++++++++++++++++ drivers/gpu/drm/xen/xen_drm_front.h | 188 ++++++ drivers/gpu/drm/xen/xen_drm_front_cfg.c | 77 +++ drivers/gpu/drm/xen/xen_drm_front_cfg.h | 37 ++ drivers/gpu/drm/xen/xen_drm_front_conn.c | 115 ++++ drivers/gpu/drm/xen/xen_drm_front_conn.h | 27 + drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 387 ++++++++++++ drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 81 +++ drivers/gpu/drm/xen/xen_drm_front_gem.c | 314 ++++++++++ drivers/gpu/drm/xen/xen_drm_front_gem.h | 43 ++ drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 79 +++ drivers/gpu/drm/xen/xen_drm_front_kms.c | 372 ++++++++++++ drivers/gpu/drm/xen/xen_drm_front_kms.h | 26 + drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 436 ++++++++++++++ drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 72 +++ 21 files changed, 3229 insertions(+) create mode 100644 Documentation/gpu/xen-front.rst create mode 100644 drivers/gpu/drm/xen/Kconfig create mode 100644 drivers/gpu/drm/xen/Makefile create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.h -- 2.16.2

1 2

[PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked
by Daniel Vetter 03 Apr '18

03 Apr '18

vboxvideo doesn't use dev->struct_mutex and therefore has no need to use gem_free_object. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Michael Thayer <michael.thayer(a)oracle.com> Cc: Colin Ian King <colin.king(a)canonical.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> --- drivers/staging/vboxvideo/vbox_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vboxvideo/vbox_drv.c b/drivers/staging/vboxvideo/vbox_drv.c index e18642e5027e..f6d26beffa54 100644 --- a/drivers/staging/vboxvideo/vbox_drv.c +++ b/drivers/staging/vboxvideo/vbox_drv.c @@ -242,7 +242,7 @@ static struct drm_driver driver = { .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, - .gem_free_object = vbox_gem_free_object, + .gem_free_object_unlocked = vbox_gem_free_object, .dumb_create = vbox_dumb_create, .dumb_map_offset = vbox_dumb_mmap_offset, .dumb_destroy = drm_gem_dumb_destroy, -- 2.16.2

6 19

[PATCH 1/3] drm/omap: fix uninitialized ret variable
by Tomi Valkeinen 03 Apr '18

03 Apr '18

audio_config function for both HDMI4 and HDMI5 return uninitialized value as the error code if the display is not currently enabled. For some reason this has not caused any issues. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> --- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index 97c88861d67a..5879f45f6fc9 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -679,7 +679,7 @@ static int hdmi_audio_config(struct device *dev, struct omap_dss_audio *dss_audio) { struct omap_hdmi *hd = dev_get_drvdata(dev); - int ret; + int ret = 0; mutex_lock(&hd->lock); diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c b/drivers/gpu/drm/omapdrm/dss/hdmi5.c index d28da9ac3e90..ae1a001d1b83 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c @@ -671,7 +671,7 @@ static int hdmi_audio_config(struct device *dev, struct omap_dss_audio *dss_audio) { struct omap_hdmi *hd = dev_get_drvdata(dev); - int ret; + int ret = 0; mutex_lock(&hd->lock); -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 14

[PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"
by Colin King 03 Apr '18

03 Apr '18

From: Colin Ian King <colin.king(a)canonical.com> Trivial fix to spelling mistake in DRM_ERROR error message text Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e42a28e3adc5..1df1c91b6ae5 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev) break; #endif default: - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type); + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type); goto fail; } @@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle) break; #endif default: - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type); + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type); return -EINVAL; } -- 2.15.1

6 6

[Bug 105530] Stuttering on Raven Ridge when TearFree is on
by bugzilla-daemon＠freedesktop.org 03 Apr '18

03 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #8 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to Mez from comment #7) > I've always had Tearfree option on though and it didn't occur before these last > few weeks. Can you help narrow down whether this was introduced by a change in the kernel or in xf86-video-amdgpu, and ideally bisect? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 95058] When monitors sleep, backlights stay on, screen is black, and can't be woke up
by bugzilla-daemon＠freedesktop.org 03 Apr '18

03 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=95058 Bug ID: 95058 Summary: When monitors sleep, backlights stay on, screen is black, and can't be woke up Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: Espionage724(a)gmail.com I use 3 monitors. I leave, come back, and my monitors are on, but all of them show a black background. Mouse cursor doesn't show, and trying to switch to TTY doesn't work. Keyboard caps lock light doesn't toggle. REISUB magic keys work to reboot the system. I'm using a R9 380 (MSI GAMING 4G) with AMDGPU, a GIGABYTE GA-990FX-Gaming motherboard, FX-8350, and a 750W Corsair PSU. I'm using Xubuntu 16.04 (4.4.0-21-generic; default kernel) and use padoka-PPA (DRI3, TearFree, sisched, forcedma). This has happened only after I got the R9 380 about a week or so ago. I've ran a Radeon HD 7850 prior to that on the same set-up (only with radeon instead of amdgpu) and haven't had this happen. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android
by John Stultz 03 Apr '18

03 Apr '18

In trying to integrate the new gralloc_handle.h with the drm_hwcomposer, I started seeing the following compilation errors: In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28: external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of type 'struct gralloc_handle_t *' return handle; ^~~~~~ 1 error generated. This seems to be due to the gralloc_handle_create() definition claiming to return a native_handle_t * type, rather then a gralloc_handle_t *, which is what the code actually returns. This function isn't actually used in the current drm_hwcomposer, so I'm not totally sure that this fix is correct (rather then returning the gralloc_handle_t's embadedded native_handle_t ptr). But it seems something like this is needed. Cc: Robert Foss <robert.foss(a)collabora.com> Cc: Rob Herring <robh(a)kernel.org> Cc: Sean Paul <seanpaul(a)google.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- android/gralloc_handle.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h index 9cb5a5d..6e925c9 100644 --- a/android/gralloc_handle.h +++ b/android/gralloc_handle.h @@ -84,7 +84,7 @@ static inline struct gralloc_handle_t *gralloc_handle(buffer_handle_t handle) /** * Create a buffer handle. */ -static inline native_handle_t *gralloc_handle_create(int32_t width, +static inline gralloc_handle_t *gralloc_handle_create(int32_t width, int32_t height, int32_t hal_format, int32_t usage) @@ -107,5 +107,4 @@ static inline native_handle_t *gralloc_handle_create(int32_t width, return handle; } - #endif -- 2.7.4

5 6

[PATCH v2] libdrm: gralloc_handle.h: Fix build issue with Android
by John Stultz 03 Apr '18

03 Apr '18

In trying to integrate the new gralloc_handle.h with the drm_hwcomposer, I started seeing the following compilation errors: In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28: external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of type 'struct gralloc_handle_t *' return handle; ^~~~~~ 1 error generated. This seems to be due to the gralloc_handle_create() definition needs to return a native_handle_t * type, rather then a gralloc_handle_t *, which is what the code actually returns. After talking w/ Rob Herring, having the code return the native handle should be the proper fix, so that is what this patch changes. Cc: Chih-Wei Huang <cwhuang(a)android-x86.org> Cc: Stefan Schake <stschake(a)gmail.com> Cc: Robert Foss <robert.foss(a)collabora.com> Cc: Sean Paul <seanpaul(a)google.com> Cc: Rob Herring <robh(a)kernel.org> Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- v2: Change fix to return nhandle instead of changing the function definition --- android/gralloc_handle.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h index 9cb5a5d..bcf753d 100644 --- a/android/gralloc_handle.h +++ b/android/gralloc_handle.h @@ -105,7 +105,7 @@ static inline native_handle_t *gralloc_handle_create(int32_t width, handle->usage = usage; handle->prime_fd = -1; - return handle; + return nhandle; } #endif -- 2.7.4

2 2

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
by bugzilla-daemon＠freedesktop.org 03 Apr '18

03 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=89685 Bug ID: 89685 Summary: Cripling Dota 2 freeze with Morphling at hero selection or loadout Product: Mesa Version: 10.5 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: wittyman37(a)yahoo.com QA Contact: dri-devel(a)lists.freedesktop.org So I am having a very bizare issue as recently. I noticed yesterday that I cannot play Morphling! If I select him during the hero selection or even try to view him in the loadout screen, my system completely freezes with no option but to do a hard reset. I cannot alt-tab, minimize to desktop, switch to any TTY and REISUB does not work. This ONLY happens with the hero morphling and seems to be an issue with graphics because it seems to happen when I am about to see his model loaded. I even deleted the one item I had for him. I verified the game files; no good. I deleted all local content and downloaded the game again...no good. This is either an issue with my graphics drivers and morphling or a Dota 2 and Linux issue. My wife is using Windows 8.1 and does not have this problem. I am running an AMD R9 270X with linux 3.19.2 and mesa 10.5.1 where everything else works wonderfully! -- You are receiving this mail because: You are the assignee for the bug.

1 28

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2018