dri-devel October 2015

dri-devel@lists.freedesktop.org

201 participants
1170 discussions

[RFC 0/2] Add renderonly gpu support
by Christian Gmeiner 11 Oct '15

11 Oct '15

This patch set introduces a more generic renderonly driver library based on "[RFC] tegra: Initial support" [0] from Thierry Reding. I am re-using almost all of the existing code and extended it with a struct renderonly_ops, which defines the wanted behavior for the target hardware. There are two different usage patterns, which are supported. 1) Set a required tiling on the scanout buffer (tegra) 2) Use an intermediate buffer and blit to dumb buffer (imx) The setup of struct renderonly_ops happens in winsys. So it is possible to support different configurations for different versions of an IP core, which are using the same KMS driver. I really hope to get some feedback as the bare metal EGL use case is important as not everyone runs a compositor, which understands rendernodes. This patch set was successfully tested on tegra and imx-drm (etnaviv based) and runs kmscube. The patch set is available directly via git: https://github.com/austriancoder/mesa.git branch renderonly-rfc-1 [0] http://lists.freedesktop.org/archives/mesa-dev/2014-November/071521.html Christian Gmeiner (2): gallium: add renderonly driver gallium: add tegra support configure.ac | 20 +- src/gallium/Makefile.am | 6 + .../auxiliary/target-helpers/inline_drm_helper.h | 29 + src/gallium/drivers/renderonly/Makefile.am | 11 + src/gallium/drivers/renderonly/Makefile.sources | 4 + .../drivers/renderonly/renderonly_context.c | 721 +++++++++++++++++++++ .../drivers/renderonly/renderonly_context.h | 80 +++ .../drivers/renderonly/renderonly_resource.c | 296 +++++++++ .../drivers/renderonly/renderonly_resource.h | 101 +++ src/gallium/drivers/renderonly/renderonly_screen.c | 178 +++++ src/gallium/drivers/renderonly/renderonly_screen.h | 55 ++ src/gallium/drivers/tegra/Automake.inc | 10 + src/gallium/drivers/tegra/Makefile.am | 9 + src/gallium/targets/dri/Makefile.am | 2 + src/gallium/winsys/tegra/drm/Android.mk | 34 + src/gallium/winsys/tegra/drm/Makefile.am | 33 + src/gallium/winsys/tegra/drm/Makefile.sources | 3 + src/gallium/winsys/tegra/drm/tegra_drm_public.h | 31 + src/gallium/winsys/tegra/drm/tegra_drm_winsys.c | 51 ++ 19 files changed, 1673 insertions(+), 1 deletion(-) create mode 100644 src/gallium/drivers/renderonly/Makefile.am create mode 100644 src/gallium/drivers/renderonly/Makefile.sources create mode 100644 src/gallium/drivers/renderonly/renderonly_context.c create mode 100644 src/gallium/drivers/renderonly/renderonly_context.h create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.c create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.h create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.c create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.h create mode 100644 src/gallium/drivers/tegra/Automake.inc create mode 100644 src/gallium/drivers/tegra/Makefile.am create mode 100644 src/gallium/winsys/tegra/drm/Android.mk create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c -- 2.4.3

1 3

[PATCH] nouveau: fix OpenFirmware support
by Laurent Vivier 11 Oct '15

11 Oct '15

On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() returns NULL. But in fact the OpenFirmware has given us the size we can store in image->size. This size is stored in bios->size by of_init() as there is no way to retrieve it otherwise. And as we know the size, copy all data to bios->data. Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). Before: nouveau 0000:0a:00.0: NVIDIA NV43 (043200a4) u3msi: allocated virq 0x19 (hw 0x8) addr 0xf8004080 nouveau 0000:0a:00.0: Invalid ROM contents nouveau 0000:0a:00.0: bios: unable to locate usable image nouveau 0000:0a:00.0: bios ctor failed, -22 nouveau: probe of 0000:0a:00.0 failed with error -22 After: nouveau 0000:0a:00.0: NVIDIA NV43 (043200a4) u3msi: allocated virq 0x19 (hw 0x8) addr 0xf8004080 nouveau 0000:0a:00.0: bios: version 05.43.02.75.00 nouveau 0000:0a:00.0: fb: 128 MiB DDR1 nouveau 0000:0a:00.0: Using 32-bit DMA via iommu [TTM] Zone kernel: Available graphics memory: 5610528 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator nouveau 0000:0a:00.0: DRM: VRAM: 124 MiB nouveau 0000:0a:00.0: DRM: GART: 512 MiB nouveau 0000:0a:00.0: DRM: TMDS table version 1.1 nouveau 0000:0a:00.0: DRM: DCB version 3.0 nouveau 0000:0a:00.0: DRM: DCB outp 00: 01000100 00000028 nouveau 0000:0a:00.0: DRM: DCB outp 01: 03000102 00000000 nouveau 0000:0a:00.0: DRM: DCB outp 02: 04011210 00000028 nouveau 0000:0a:00.0: DRM: DCB outp 03: 02111212 02000100 nouveau 0000:0a:00.0: DRM: DCB outp 04: 02011211 0020c070 nouveau 0000:0a:00.0: DRM: DCB conn 00: 1030 nouveau 0000:0a:00.0: DRM: DCB conn 01: 2130 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. nouveau 0000:0a:00.0: DRM: 0x14C5: Parsing digital output script table nouveau 0000:0a:00.0: DRM: MM: using M2MF for buffer copies nouveau 0000:0a:00.0: DRM: Setting dpms mode 3 on TV encoder (output 4) nouveau 0000:0a:00.0: DRM: allocated 1680x1050 fb: 0x30000, bo c00000000399d800 nouveau 0000:0a:00.0: DRM: 0x14C5: Parsing digital output script table Console: switching to colour frame buffer device 210x65 nouveau 0000:0a:00.0: fb0: nouveaufb frame buffer device [drm] Initialized nouveau 1.3.0 20120801 for 0000:0a:00.0 on minor 0 Signed-off-by: Laurent Vivier <laurent(a)vivier.eu> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.c | 10 ++++++++-- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c | 8 ++++++-- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.c index 74b14cf..17ba0c726 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.c @@ -47,8 +47,14 @@ nvbios_imagen(struct nvkm_bios *bios, struct nvbios_image *image) return false; } - if (!(data = nvbios_pcirTp(bios, image->base, &ver, &hdr, &pcir))) - return false; + data = nvbios_pcirTp(bios, image->base, &ver, &hdr, &pcir); + if (!data) { + image->size = bios->size; + image->type = 0x00; + image->last = true; + + return true; + } image->size = pcir.image_size; image->type = pcir.image_type; image->last = pcir.last; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c index bd60d7d..d4c8801 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c @@ -34,7 +34,6 @@ of_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) { struct priv *priv = data; if (offset + length <= priv->size) { - memcpy_fromio(bios->data + offset, priv->data + offset, length); return length; } return 0; @@ -50,8 +49,13 @@ of_init(struct nvkm_bios *bios, const char *name) return ERR_PTR(-ENODEV); if (!(priv = kzalloc(sizeof(*priv), GFP_KERNEL))) return ERR_PTR(-ENOMEM); - if ((priv->data = of_get_property(dn, "NVDA,BMP", &priv->size))) + priv->data = of_get_property(dn, "NVDA,BMP", &priv->size); + if (priv->data) { + bios->size = (priv->size + 3) & ~3; + bios->data = kmalloc(bios->size, GFP_KERNEL); + memcpy(bios->data, priv->data, priv->size); return priv; + } kfree(priv); return ERR_PTR(-EINVAL); } -- 2.4.3

2 6

[Bug 91516] Hang on Dota 2 Reborn with Unsafe Math
by bugzilla-daemon＠freedesktop.org 11 Oct '15

11 Oct '15

https://bugs.freedesktop.org/show_bug.cgi?id=91516 Bug ID: 91516 Summary: Hang on Dota 2 Reborn with Unsafe Math Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: commendsarnex(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Hi guys, I get a hang with commit "gallium/radeon: re-enable unsafe math for graphics shaders." I've attached R600_DEBUG=ps,vs with and without this commit. I'm using llvm git and kernel 4.1.3 Thanks for your help, sarnex -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 91733] [SKL/HSW] Ogles1conform pntszary.c fails
by bugzilla-daemon＠freedesktop.org 10 Oct '15

10 Oct '15

https://bugs.freedesktop.org/show_bug.cgi?id=91733 --- Comment #5 from cprigent <christophe.prigent(a)intel.com> --- Reproduced on SKL-Y with Mesa 11.0.2: Hardware: Platform: SKY LAKE Y A0 CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78 stepping: 3) MCP : SKL-Y D1 2+2 (ou ULX-D1) QDF : QJK9 CPU : SKL D0 Chipset PCH: Sunrise Point LP C1 CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2 Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06 Software Linux : Ubuntu 14.04 LTS 64 bits BIOS : SKLSE2R1.R00.X097.B02.1509020030 ME FW : 11.0.0.1173 Ksc (EC FW): 1.19 kernel 4.3.0-rc3-drm-intel-nightly+ (eb69e51) from git://anongit.freedesktop.org/drm-intel Mesa - 11.0.2 from http://cgit.freedesktop.org/mesa/mesa/ xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/ Libva - 1.6.1 from http://cgit.freedesktop.org/libva/ vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v2 0/2] drm/nouveau: add support for 2560x1440@56 over HDMI
by Hauke Mehrtens 10 Oct '15

10 Oct '15

These patches are adding support for outputting 2560x1440@56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440@56 and one DVI monitor running with 1920x1200@60. This still needs testing on other graphics cards and with dual link DVI. There is no Maintainers entry for nouveau. This is based on top of Linux 4.3-rc4. I am not used to the process uses by nouveau developers and I hope this is the correct way to get this patch into upstream Linux. changes since v1: * rebase on 4.3-rc4 * update commit message Hauke Mehrtens (2): drm/nouveau: activate dual link TMDS links only when possible drm/nouveau: increase max pixel clock to 225 MHZ for HDMI drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++++-- drivers/gpu/drm/nouveau/nv50_display.c | 8 ++++---- drivers/gpu/drm/nouveau/nvkm/engine/disp/gf119.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c | 2 +- 4 files changed, 10 insertions(+), 8 deletions(-) -- 2.1.4

1 2

[PATCH 01/20] drm: Constify drm_encoder_slave_funcs
by ville.syrjala＠linux.intel.com 09 Oct '15

09 Oct '15

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/drm_encoder_slave.c | 2 +- drivers/gpu/drm/nouveau/nouveau_encoder.h | 2 +- drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 6 +++--- drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 8 ++++---- include/drm/drm_encoder_slave.h | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_encoder_slave.c b/drivers/gpu/drm/drm_encoder_slave.c index d18b88b..e862907 100644 --- a/drivers/gpu/drm/drm_encoder_slave.c +++ b/drivers/gpu/drm/drm_encoder_slave.c @@ -124,7 +124,7 @@ EXPORT_SYMBOL(drm_i2c_encoder_destroy); * Wrapper fxns which can be plugged in to drm_encoder_helper_funcs: */ -static inline struct drm_encoder_slave_funcs * +static inline const struct drm_encoder_slave_funcs * get_slave_funcs(struct drm_encoder *enc) { return to_encoder_slave(enc)->slave_funcs; diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h index b37da95..07527db 100644 --- a/drivers/gpu/drm/nouveau/nouveau_encoder.h +++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h @@ -80,7 +80,7 @@ static inline struct drm_encoder *to_drm_encoder(struct nouveau_encoder *enc) return &enc->base.base; } -static inline struct drm_encoder_slave_funcs * +static inline const struct drm_encoder_slave_funcs * get_slave_funcs(struct drm_encoder *enc) { return to_encoder_slave(enc)->slave_funcs; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c index 96f2eb4..a37b6e2 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c @@ -28,7 +28,7 @@ static int rcar_du_hdmi_connector_get_modes(struct drm_connector *connector) { struct rcar_du_connector *con = to_rcar_connector(connector); struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (sfuncs->get_modes == NULL) return 0; @@ -41,7 +41,7 @@ static int rcar_du_hdmi_connector_mode_valid(struct drm_connector *connector, { struct rcar_du_connector *con = to_rcar_connector(connector); struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (sfuncs->mode_valid == NULL) return MODE_OK; @@ -66,7 +66,7 @@ rcar_du_hdmi_connector_detect(struct drm_connector *connector, bool force) { struct rcar_du_connector *con = to_rcar_connector(connector); struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (sfuncs->detect == NULL) return connector_status_unknown; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c index 81da841..e41bbb6 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c @@ -35,7 +35,7 @@ struct rcar_du_hdmienc { static void rcar_du_hdmienc_disable(struct drm_encoder *encoder) { struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (sfuncs->dpms) sfuncs->dpms(encoder, DRM_MODE_DPMS_OFF); @@ -50,7 +50,7 @@ static void rcar_du_hdmienc_disable(struct drm_encoder *encoder) static void rcar_du_hdmienc_enable(struct drm_encoder *encoder) { struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (hdmienc->renc->lvds) rcar_du_lvdsenc_enable(hdmienc->renc->lvds, encoder->crtc, @@ -67,7 +67,7 @@ static int rcar_du_hdmienc_atomic_check(struct drm_encoder *encoder, struct drm_connector_state *conn_state) { struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode; const struct drm_display_mode *mode = &crtc_state->mode; @@ -89,7 +89,7 @@ static void rcar_du_hdmienc_mode_set(struct drm_encoder *encoder, struct drm_display_mode *adjusted_mode) { struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder); - struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); + const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder); if (sfuncs->mode_set) sfuncs->mode_set(encoder, mode, adjusted_mode); diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h index 8b9cc36..82cdf61 100644 --- a/include/drm/drm_encoder_slave.h +++ b/include/drm/drm_encoder_slave.h @@ -95,7 +95,7 @@ struct drm_encoder_slave_funcs { struct drm_encoder_slave { struct drm_encoder base; - struct drm_encoder_slave_funcs *slave_funcs; + const struct drm_encoder_slave_funcs *slave_funcs; void *slave_priv; void *bus_priv; }; -- 2.4.6

3 21

[PATCH] drm: atmel-hlcdc: add support for sama5d2 SoCs
by Nicolas Ferre 09 Oct '15

09 Oct '15

As the hardware description for this chip is the same as the sama5d4, we use this SoC structures for layers and DC descriptions. Thus only 2 lines are added to the atmel_hlcdc_of_match table. The compatible string is already documented in the parent MFD driver's binding. Signed-off-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index 8bc62ec407f9..498add1e5e58 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -333,6 +333,10 @@ static const struct of_device_id atmel_hlcdc_of_match[] = { .data = &atmel_hlcdc_dc_at91sam9x5, }, { + .compatible = "atmel,sama5d2-hlcdc", + .data = &atmel_hlcdc_dc_sama5d4, + }, + { .compatible = "atmel,sama5d3-hlcdc", .data = &atmel_hlcdc_dc_sama5d3, }, -- 2.1.3

2 1

RFC: DRM trivial tree
by Thierry Reding 09 Oct '15

09 Oct '15

Hi everyone, Lately I've noticed that a bunch of trivial patches have been posted across all drivers. We've also encountered situations in the past where (relatively trivial) subsystem-wide changes have been made but it ended up being very difficult to get patches merged (often because they had inter-dependencies and nobody felt responsible for merging them). Often Dave has been the last resort for this kind of patches. A side-effect has been that it often takes a lot of time for such patches to get merged (if at all) and they usually don't end up in linux-next and therefore see little testing before they are applied. To remedy that situation I'd like to propose the addition of a tree to keep track of these kinds of patches. Note that the target here are trivial patches, such as coding style fixes, fixes for build warnings or errors, subsystem-wide API changes, etc. It also targets mostly the drivers that don't have a branch that feeds into linux-next. Patches against drivers that already feed into linux-next should go through the corresponding trees. One reasonable exception for this, in my opinion, are subsystem-wide changes, because applying them via different trees usually ends up being messy. I pushed a branch[0] with a set of patches that I've picked up from patchwork and which seemed to match the above criteria. I've also Cc'ed a bunch of people (mostly a subset of what get_maintainer.pl reported for the patches in the branch). Before going any further with this I'd like to get some feedback on the idea. Dave, do you think this is a good idea and would you be willing to give this a try? Again, I'm not volunteering to be a maintainer for all of the smaller drivers. The goal here is to make it easier to get cleanup patches into linux-next, or provide a place where subsystem-wide changes can be coordinated. Driver maintainers should still review the patches and in many cases I'd want to wait for Acked-by or Reviewed-by tags before taking any patches into the trivial tree. Also, while I'll try to monitor the list as best I can, it will inevitably happen that I'll miss patches. When that happens, feel free to Cc me if you think the patches match the above criteria. For a while now it's also been difficult to find maintainers for drivers so I'd like to see more entries being added to MAINTAINERS to help identify the people that need to be involved and hopefully make this process easier. Thierry [0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next

5 6

KMS, radeon hdmi audio troubles
by Sergei Sinyak 09 Oct '15

09 Oct '15

Hello! Want to provide more debug, but need help. All investigations of problem provided in comment on kernel bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=85241#c3 After that report I had conversation on irc.freenode.net#radeon. I asked about correct initialization speakers on radeon hdmi audio card while kms. The question is about initialization without starting Xorg server. From my point of view KMS should provide correct audio catd to produce music with starting any DM based on Xorg. But result is not positive. Currently I am using weston. And have to start and kill Xorg server before using TV speakers. TV connectd via hdmi. Should create yet one bug report to be garbaged on kernel.bugzilla? Should I wait till kms will be improved? Should I toss out my laptop? Are there any chances to fix it myself? I'd like the last one option, but have experience problems. Can't even provide helpful debug info for Alex Deucher. Thanks for attention, Sergei Sinyak

1 0

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP
by bugzilla-daemon＠freedesktop.org 09 Oct '15

09 Oct '15

https://bugs.freedesktop.org/show_bug.cgi?id=91896 --- Comment #12 from Alex Deucher <alexdeucher(a)gmail.com> --- (In reply to Ernst Sjöstrand from comment #10) > No monitor section. > During this time i've actually bought a second 4k monitor of a different > brand. > Attaching the xrandr with fglrx. Does it work properly with amdgpu? -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2015