[Bug 198123] Console is the wrong color at boot with radeon 6670

https://bugzilla.kernel.org/show_bug.cgi?id=198123 --- Comment #14 from Bill Fraser (bill.fra...@gmail.com) --- (In reply to Daniel Vetter from comment #13) > Created attachment 273575 [details] > test patch on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2, v2 That patch fixes it for me! --

[Bug 103917] [gfx9/Vega] Performance regression in master, 17.3 works fine

https://bugs.freedesktop.org/show_bug.cgi?id=103917 --- Comment #2 from Vedran Miletić --- Last week I rechecked, but all I got on master was non-working mouse clicks (weird, I know) under Wayland and crashes under Xorg. I'll recheck again. -- You are receiving this mail

[Bug 104599] corrupted desktop graphics with latest git intel driver

https://bugs.freedesktop.org/show_bug.cgi?id=104599 --- Comment #3 from Mario Kleiner --- This is running the new GNOME based Ubuntu GUI with Gnome-Shell Wayland, right? With "Windows control did not work" you mean it doesn't respond to mouse-clicks? In that

[PATCH v2 5/8] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort

This driver creates DRM encoder and connector for ZynqMP DisplayPort. Signed-off-by: Hyun Kwon --- v2 - Change the SPDX identifier format - Split drm properties into a separate patch --- --- drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 ++

[PATCH v2 6/8] drm: xlnx: ZynqMP DP subsystem DRM KMS driver

This is a wrapper around the ZynqMP Display and DisplayPort drivers. Signed-off-by: Hyun Kwon --- - Change the SPDX identifier format --- --- drivers/gpu/drm/xlnx/Kconfig| 11 +++ drivers/gpu/drm/xlnx/Makefile | 3 + drivers/gpu/drm/xlnx/zynqmp_dpsub.c |

[PATCH v2 4/8] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display

Xilinx ZynqMP has a hardened display pipeline. The pipeline can be logically partitioned into 2 parts: display controller and DisplayPort encoder / transmitter. This driver handles the display controller part of the pipeline that handles buffer management and blending. Signed-off-by: Hyun Kwon

[PATCH v2 8/8] drm: xlnx: zynqmp_dp: Add drm properties

Add drm properties for DisplayPort synchronous mode and bpc configurations. Signed-off-by: Hyun Kwon --- v2 - Split from the original patch --- --- drivers/gpu/drm/xlnx/zynqmp_dp.c | 116 ++- 1 file changed, 114 insertions(+), 2

[PATCH v2 1/8] dt-bindings: display: xlnx: Add bindings for Xilinx display pipeline

The dt binding for Xilinx display pipeline. The pipeline can be composed with multiple and different types of sub-devices. This node is to represent the entire pipeline as a single entity. Signed-off-by: Hyun Kwon --- v2 - Remove linux specific terms - Elaborate details, ex

[PATCH v2 7/8] drm: xlnx: zynqmp_disp: Add drm properties

Add drm properties for global alpha, output color, background color, and test pattern generation. Signed-off-by: Hyun Kwon --- v2 - Split from the original patch - Some props are important feature to be included --- --- drivers/gpu/drm/xlnx/zynqmp_disp.c | 193

[PATCH v2 3/8] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

This add a dt binding for ZynqMP DP subsystem. Signed-off-by: Hyun Kwon --- v2 - Group multiple ports under 'ports' - Replace linux specific terms with generic hardware descriptions --- --- .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 98 ++ 1

[PATCH v2 2/8] drm: xlnx: Xilinx DRM KMS driver

Xilinx has various platforms for display, where users can create using multiple IPs in the programmable FPGA fabric, or where some hardened piepline is available on the chip. Furthermore, hardened pipeline can also interact with soft logics in FPGA. The Xilinx DRM KMS is to integrate multiple

[PATCH 2/6] drm/exynos: Let core take care of normalizing the zpos

Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_device->normalize_zpos. Signed-off-by: Peter Ujfalusi CC: Inki Dae CC: Joonyoung Shim CC:

[PATCH 3/6] drm/tegra: Let core take care of normalizing the zpos

Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_device->normalize_zpos. Signed-off-by: Peter Ujfalusi CC: Thierry Reding --- drivers/gpu/drm/tegra/drm.c | 27

[PATCH 6/6] drm/omap: Use normalized zpos for plane placement

Planes with identical zpos value will result undefined behavior: disappearing planes, screen flickering and it is not supported by the hardware. Use normalized zpos to make sure that we don't encounter invalid configuration. Signed-off-by: Peter Ujfalusi CC: Tomi

[PATCH 1/6] drm: Add drm_device->normalize_zpos boolean

Instead of drivers duplicating the drm_atomic_helper_check() code to be able to normalize the zpos they can use the normalize_zpos flag to let the drm core to do it. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/drm_atomic_helper.c | 6 ++ include/drm/drm_device.h

[PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

The internal LVDS encoders now have their own DT bindings. Before switching the driver infrastructure to those new bindings, implement backward-compatibility through live DT patching. Patching is disabled and will be enabled along with support for the new DT bindings in the DU driver.

[PATCH v2 01/12] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add corresponding device tree bindings. Signed-off-by: Laurent Pinchart --- Changes since v1: - Move the SoC name before the IP name in compatible strings - Rename parallel input to

[PATCH v2 07/12] ARM: dts: r8a7791: Convert to new LVDS DT bindings

The internal LVDS encoder now has DT bindings separate from the DU. Port the device tree over to the new model. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the DU reg-names property --- arch/arm/boot/dts/r8a7791-koelsch.dts | 10

[PATCH v2 02/12] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

The internal LVDS encoders now have their own DT bindings, representing them as part of the DU is deprecated. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the LVDS reg range from the example - Remove the reg-names property ---

[PATCH v2 05/12] ARM: dts: porter: Fix HDMI output routing

The HDMI encoder is connected to the RGB output of the DU, which is port@0, not port@1. Fix the incorrect DT description. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7791-porter.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2 12/12] arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

The internal LVDS encoder now has DT bindings separate from the DU. Port the device tree over to the new model. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the DU reg-names property --- arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts

[PATCH v2 06/12] ARM: dts: r8a7790: Convert to new LVDS DT bindings

The internal LVDS encoder now has DT bindings separate from the DU. Port the device tree over to the new model. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the DU reg-names property --- arch/arm/boot/dts/r8a7790-lager.dts | 22

[PATCH v2 00/12] R-Car DU: Convert LVDS code to bridge driver

Hello, This patch series addresses a design mistake that dates back from the initial DU support. Support for the LVDS encoders, which are IP cores separate from the DU, was bundled in the DU driver. Worse, both the DU and LVDS were described through a single DT node. To fix the, patches 01/12

[PATCH v2 04/12] drm: rcar-du: Convert LVDS encoder code to bridge driver

The LVDS encoders used to be described in DT as part of the DU. They now have their own DT node, linked to the DU using the OF graph bindings. This allows moving internal LVDS encoder support to a separate driver modelled as a DRM bridge. Backward compatibility is retained as legacy DT is patched

[PATCH v2 10/12] ARM: dts: r8a7794: Convert to new DU DT bindings

The DU DT bindings have been updated to drop the reg-names property. Update the r8a7792 device tree accordingly. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7794.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH v2 09/12] ARM: dts: r8a7793: Convert to new LVDS DT bindings

The internal LVDS encoder now has DT bindings separate from the DU. Port the device tree over to the new model. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the DU reg-names property --- arch/arm/boot/dts/r8a7793-gose.dts | 10

[PATCH v2 08/12] ARM: dts: r8a7792: Convert to new DU DT bindings

The DU DT bindings have been updated to drop the reg-names property. Update the r8a7792 device tree accordingly. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7792.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH v2 11/12] arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings

The internal LVDS encoder now has DT bindings separate from the DU. Port the device tree over to the new model. Signed-off-by: Laurent Pinchart --- Changes since v1: - Remove the DU reg-names property ---

[PATCH v2 2/2] drm: rcar-du: lvds: Fix LVDS startup on R-Car gen2

From: Sergei Shtylyov According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS must be enabled and the bias crcuit enabled after the LVDS I/O pins are enabled, not before. Fix the gen2 LVDS startup sequence accordingly. While at it, also fix

Re: [PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

Hi Jernej, Thank you for th epatch. On Wednesday, 10 January 2018 21:25:04 EET Jernej Skrabec wrote: > Parts of PHY code could be useful also for custom PHYs. For example, > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY > with few additional memory mapped registers, so most

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #17 from Bong Cosca --- Disabling hardware acceleration isn't exactly the workaround I was looking for. I use modesetting with "AccelMethod" "none" just to make this work and I am forced to use Win10 to do 3D

[Bug 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

https://bugs.freedesktop.org/show_bug.cgi?id=104611 Alex Deucher changed: What|Removed |Added Component|DRM/Radeon |DRM/AMDgpu --

Error handling when vmalloc is too small

Hi there, Error handling seems to be broken when allocating a framebuffer fails (see below). Observed on a Apalis TK1 (Tegra K1 with 2GB RAM, seems to allocate 240 MB for vmalloc) using Linux 4.15.0-rc7 connected to a 4K TV: [5.632659] [drm:drm_setup_crtcs] [5.636227]

Re: [PATCH 2/4 v7] drm/bridge: Provide a way to embed timing info in bridges

Hi Linus, Thank you for the patch. On Friday, 12 January 2018 09:48:52 EET Linus Walleij wrote: > After some discussion and failed patch sets trying to convey > the right timing information between the display engine and > a bridge using the connector, I try instead to use an optional > timing

[Bug 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

https://bugs.freedesktop.org/show_bug.cgi?id=104611 Bug ID: 104611 Summary: [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1 Product: DRI Version: unspecified Hardware:

[PATCH 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

This to allow drivers to choose to avoid OOM invocation and handle page allocation failures instead. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_bo.c | 3 +++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 ++

[PATCH 2/2] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

This to have a load time option to avoid OOM on RAM allocations. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 3 files

Re: [PATCH 2/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen2

Hi Sergei, Thank you for the patch. On Friday, 12 January 2018 22:12:05 EET Sergei Shtylyov wrote: > According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS > must be enabled and the bias crcuit enabled after the LVDS I/O pins are > enabled, not before -- fix the gen2 LVDS

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

Hi Sergei, On Friday, 12 January 2018 23:51:35 EET Laurent Pinchart wrote: > On Friday, 12 January 2018 22:12:04 EET Sergei Shtylyov wrote: > > According to the latest revisions of the R-Car gen3 manual, the LVDS mode > > must be set before the LVDS I/O pins are enabled, not after -- fix the >

[Bug 103976] Regression: Videogame (Wakfu) no longer works with Mesa 17.2 (17.1 works)

https://bugs.freedesktop.org/show_bug.cgi?id=103976 Timo Aaltonen changed: What|Removed |Added Resolution|--- |DUPLICATE

[PATCH 5/6] drm: rcar-du: Let core take care of normalizing the zpos

Set the drm_device->normalize_zpos and call drm_atomic_helper_check() from rcar_du_atomic_check() instead of re implementing the function locally. Signed-off-by: Peter Ujfalusi CC: Laurent Pinchart ---

[PATCH 0/6] drm: zpos normalization cleanup and omapdrm to use it

Hi, The first patch is adding a flag to drm_device that drivers can set if they want the zpos to be normalized. Then convert exynos, tegra, sti and rcar-du to use this flag instead of re-implementing the drm_atomic_helper_check() locally just to add the call to drm_atomic_normalize_zpos(). The

[PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

drm_vblank_count() has a u32 type returning what is a 64-bit vblank count. The effect of this is when drm_wait_vblank_ioctl() tries to widen the user space requested vblank sequence using this clipped 32-bit count(when the value is >= 2^32) as reference, the requested sequence remains a 32-bit

[PATCH 3/5] drm/vblank: Do not update vblank count if interrupts are already disabled.

Updating vblank counts requires register reads and these reads may not return meaningful values if the device was in a low power state after vblank interrupts were last disabled. So, update the count only if vblank interrupts are enabled. Secondly, this means the registers should be read before

[PATCH 5/5] drm/i915: Estimate and update missed vblanks.

The frame counter may have got reset between disabling and enabling vblank interrupts due to DMC putting the hardware to DC5/6 state if PSR was active. The frame counter also could have stalled if PSR is active in cases where there is no DMC. The frame counter resetting as a user visible impact of

[PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.

The HW frame counter can get reset if device enters a low power state after vblank interrupts were disabled. This messes up any following vblank count update as a negative diff (huge unsigned diff) is calculated from the HW frame counter change. We cannot ignore negative diffs altogther as there

[PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

Now that drm_vblank_count() returns all bits of the vblank count, update drm_crtc_arm_vblank_event() so that it queues the correct sequence. Otherwise, this leads to prolonged waits for a vblank sequence when the current count is >=2^32. Cc: Keith Packard Cc: Michel Dänzer

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 --- Comment #7 from Christoph Haag --- Created attachment 136701 --> https://bugs.freedesktop.org/attachment.cgi?id=136701=edit glxinfo -- You are receiving this mail because: You are the assignee for the

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 --- Comment #6 from Christoph Haag --- Created attachment 136700 --> https://bugs.freedesktop.org/attachment.cgi?id=136700=edit xdpyinfo No need to add to drirc, you can also set drirc options with an environment

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

Hi Sergei, Thank you for the patch. On Friday, 12 January 2018 22:12:04 EET Sergei Shtylyov wrote: > According to the latest revisions of the R-Car gen3 manual, the LVDS mode > must be set before the LVDS I/O pins are enabled, not after -- fix the > gen3 LVDS startup sequence accordingly... >

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 --- Comment #5 from Mario Kleiner --- Can you try what happens if you add the following snippet inside the section of your /etc/drirc and restart compton? The output of xdpyinfo and glxinfo could also

[PATCH] drm: rcar-du: lvds: Fix LVDS clock frequency range

According to the latest versions of both the Gen2 and Gen3 datasheets, the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all SoCs. Update the driver accordingly. Signed-off-by: Laurent Pinchart ---

[PATCH] drm/amdgpu: Use seq_putc() in two functions

From: Markus Elfring Date: Fri, 12 Jan 2018 22:08:50 +0100 A few single characters should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[Bug 198123] Console is the wrong color at boot with radeon 6670

https://bugzilla.kernel.org/show_bug.cgi?id=198123 Daniel Vetter (dan...@ffwll.ch) changed: What|Removed |Added Attachment #273531|0 |1 is obsolete|

Re: [PATCH] drm/fb-helper: Fix of-by-one in setcmap_pseudo_palette

On Fri, Jan 12, 2018 at 3:08 PM, Sean Paul wrote: > On Fri, Jan 12, 2018 at 4:48 AM, Daniel Vetter wrote: >> [Fair warning: This is pure conjecture right now.] >> >> In >> >> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 >> Author: Peter Rosin

[PATCH 3/3] drm/msm/dsi: check msm_dsi and dsi pointers before use

Move null checks of pointer arguments to the beginning of the modeset init function since they are referenced immediately instead of after they have already been used. Signed-off-by: Lloyd Atkinson --- drivers/gpu/drm/msm/dsi/dsi.c | 22 ++ 1 file

[PATCH 2/3] drm/msm/dsi: correct DSI id bounds check during registration

Check DSI instance id argument against the proper boundary size to protect against invalid configuration of the DSI id. Signed-off-by: Lloyd Atkinson --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/3] drm/msm/dsi: check src_pll for null in dsi manager

Add checks for failure after retrieving the src_pll, since it may fail. This prevents an invalid pointer dereference later in msm_dsi_pll_get_clk_provider. Signed-off-by: Lloyd Atkinson --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 1 file changed, 4 insertions(+)

[PATCH 0/3] drm/msm/dsi: improve pointer validation checks

This series improves a few pointer validation checks around the drm/msm/dsi driver. Lloyd Atkinson (3): drm/msm/dsi: check src_pll for null in dsi manager drm/msm/dsi: correct DSI id bounds check during registration drm/msm/dsi: check msm_dsi and dsi pointers before use

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

Hi Sergei, On Friday, 12 January 2018 17:13:06 EET Sergei Shtylyov wrote: > On 01/12/2018 03:58 AM, Laurent Pinchart wrote: > > The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add > > corresponding device tree bindings. > > > > Signed-off-by: Laurent Pinchart > >

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

On 01/12/2018 11:12 PM, Sergei Shtylyov wrote: According to the latest revisions of the R-Car gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the gen3 LVDS startup sequence accordingly... While at it, also fix the comment preceding the first

[PATCH 2/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen2

According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS must be enabled and the bias crcuit enabled after the LVDS I/O pins are enabled, not before -- fix the gen2 LVDS startup sequence accordingly. Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")

[PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

According to the latest revisions of the R-Car gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the gen3 LVDS startup sequence accordingly... While at it, also fix the comment preceding the first LVDCR0 write in the R-Car gen2 startup code that

[PATCH 0/2] Fix LVDS startup sequences in the R-Car DU driver...

Hello! Here's the set of 2 patches against the 'drmf-ixes' branch of David Airlie's 'linux.git' repo plus the patch fixing LVDCR1 for R-Car gen3 posted recently. Documentation check against the recent manuals revealed that the LVDS startup sequences don't match those. I was able to test the gen3

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 network...@rkmail.ru changed: What|Removed |Added CC||network...@rkmail.ru --- Comment

[Bug 104540] Corrupted colors in OBS-Studio window capture

https://bugs.freedesktop.org/show_bug.cgi?id=104540 network...@rkmail.ru changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 --- Comment #3 from network...@rkmail.ru --- bug 104540 is probably the very same issue, since OBS uses Xcomposite to capture a window. -- You are receiving this mail because: You are the assignee for the

[Bug 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

https://bugs.freedesktop.org/show_bug.cgi?id=104607 --- Comment #2 from network...@rkmail.ru --- (In reply to Bas Nieuwenhuizen from comment #1) > This patch is on the list and probably fixes it: > > https://patchwork.freedesktop.org/patch/197359/ Thank you, it worked for me. -- You are

Re: [PATCH 4/4 v7] drm/pl111: Support handling bridge timings

On Fri, Jan 12, 2018 at 10:25 AM, Archit Taneja wrote: > On 01/12/2018 01:18 PM, Linus Walleij wrote: >> >> If the bridge has a too strict setup time for the incoming >> signals, we may not be fast enough and then we need to >> compensate by outputting the signal on the

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 01/12/2018 07:12 PM, Hans Verkuil wrote: > On 01/12/2018 06:52 PM, Ville Syrjälä wrote: >> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: >>> On 01/12/2018 05:30 PM, Ville Syrjälä wrote: On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > Hi Ville, >

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

https://bugs.freedesktop.org/show_bug.cgi?id=104608 --- Comment #1 from Vedran Miletić --- Created attachment 136692 --> https://bugs.freedesktop.org/attachment.cgi?id=136692=edit dmesg -- You are receiving this mail because: You are the assignee for the

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

https://bugs.freedesktop.org/show_bug.cgi?id=104608 Bug ID: 104608 Summary: [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0258 Product: DRI

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #25 from Direx --- The printks indeed only show up when the computer boots or when the display comes back from DPMS. I don't get any printks when playing audio streams. (In reply to Alex Deucher from

[Bug 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

https://bugs.freedesktop.org/show_bug.cgi?id=104607 --- Comment #1 from Bas Nieuwenhuizen --- This patch is on the list and probably fixes it: https://patchwork.freedesktop.org/patch/197359/ -- You are receiving this mail because: You are the assignee for the

[Bug 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

https://bugs.freedesktop.org/show_bug.cgi?id=104607 Bug ID: 104607 Summary: Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763 Product: Mesa Version: git Hardware: Other OS: All

[Bug 104507] Unable to set "Content Type" bit for HDMI and DisplayPort

https://bugs.freedesktop.org/show_bug.cgi?id=104507 --- Comment #2 from N. W. --- Any update? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org

[Bug 104508] Unable to set "Content Type" bit for HDMI and DisplayPort

https://bugs.freedesktop.org/show_bug.cgi?id=104508 --- Comment #2 from N. W. --- Any update? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 01/12/2018 06:52 PM, Ville Syrjälä wrote: > On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: >> On 01/12/2018 05:30 PM, Ville Syrjälä wrote: >>> On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: Hi Ville, For some strange reason your email disappeared

Re: [Intel-gfx] [PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

On 12/01/18 17:48, Tvrtko Ursulin wrote: > > Hi, > > On 12/01/2018 17:36, Colin King wrote: >> From: Colin Ian King >> >> I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately >> the current code works because sizeof(struct attribute **) is the same

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #24 from Alex Deucher --- Can you see what channels is set to in dce110_se_audio_setup() in dce_stream_encoder.c? Does forcing it to 0xff help? -- You are receiving this mail because: You are the assignee

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #23 from Alex Deucher --- (In reply to lethalwp from comment #22) > Thank you for the printks. > > If the code is only ran at initialization of gpu: > > could this explain the lpcm noise issue?: The reserved

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: > On 01/12/2018 05:30 PM, Ville Syrjälä wrote: > > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > >> Hi Ville, > >> > >> For some strange reason your email disappeared from the Cc list. Perhaps > >> it's the > >> ä

Re: [Intel-gfx] [PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

Hi, On 12/01/2018 17:36, Colin King wrote: From: Colin Ian King I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately the current code works because sizeof(struct attribute **) is the same as sizeof(struct attribute *) for x86. Thanks, kbuild

[radeon-alex:drm-next-4.16-wip 77/81] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple definition of `amdgpu_dm_crtc_handle_crc_irq'

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.16-wip head: d9c47236f500494614a0d3a8e24d70e3c4da9efd commit: df6b3c876d2467ea000ab97d986fac1b45436fb2 [77/81] drm/amd/display: Implement interface for CRC on CRTC config: x86_64-randconfig-r0-01122329 (attached as .config)

Re: [RFC][PATCH 5/5] drm_hwcomposer: HACK: Fix tearing on hikey/hikey960

On Thu, Jan 11, 2018 at 11:20 PM, John Stultz wrote: > On Tue, Jan 9, 2018 at 10:05 PM, John Stultz wrote: >> When using drm_hwcomposer with the hikey/hikey960 boards, the >> resulting display shows lots of tearing. >> >> I'm not much of an expert

[PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

From: Colin Ian King I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately the current code works because sizeof(struct attribute **) is the same as sizeof(struct attribute *) for x86. Detected by CoverityScan, CID#1463854 ("Sizeof not portable")

Re: [PATCH 3/3] README: Add note about meson

On Friday, 2018-01-05 12:01:00 -0800, Dylan Baker wrote: > Signed-off-by: Dylan Baker Reviewed-by: Eric Engestrom > --- > README | 24 +--- > 1 file changed, 21 insertions(+), 3 deletions(-) > > diff --git a/README

Re: [Mesa-dev] [PATCH 2/3] autotools: Include meson.build files in tarball

On Friday, 2018-01-05 12:00:59 -0800, Dylan Baker wrote: > Signed-off-by: Dylan Baker > --- > Makefile.am | 30 +- > 1 file changed, 29 insertions(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index 7b86214..66f70ca 100644 >

Re: [PATCH 1/3] Add meson build system

On Friday, 2018-01-05 12:00:58 -0800, Dylan Baker wrote: > This patch adds a complete meson build system, including tests and > install. It has the necessary hooks to allow it be used as a subproject > for other meson based builds such as mesa. > > Signed-off-by: Dylan Baker

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 01/12/2018 05:30 PM, Ville Syrjälä wrote: > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: >> Hi Ville, >> >> For some strange reason your email disappeared from the Cc list. Perhaps >> it's the >> ä that confuses something somewhere. >> >> So I'll just forward this directly to

Re: [Mesa-dev] [PATCH 0/3] Meson build system

On Monday, 2018-01-08 16:14:43 -0800, Dylan Baker wrote: > I forgot to CC you on this like you asked, Thanks for the ping :) I noticed a couple issues on patches 1 & 2, but those are easy to fix, and with that the series is r-b me. Thanks for the effort of writing the whole thing! I'll be glad

[PATCH libdrm 0/2] drm/tegra: Sanitize format modifiers

From: Thierry Reding These UABI changes have now been merged into drm-next, so synchronize the libdrm headers and fixup the format modifiers in modetest. Thierry Thierry Reding (2): drm/fourcc: Fix fourcc_mod_code() definition drm/tegra: Sanitize format modifiers

[PATCH libdrm 2/2] drm/tegra: Sanitize format modifiers

From: Thierry Reding The existing format modifier definitions were merged prematurely, and recent work has unveiled that the definitions are suboptimal in several ways: - The format specifiers, except for one, are not Tegra specific, but the names don't reflect that.

[PATCH libdrm 1/2] drm/fourcc: Fix fourcc_mod_code() definition

From: Thierry Reding Avoid compiler warnings when the val parameter is an expression. Signed-off-by: Thierry Reding --- include/drm/drm_fourcc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_fourcc.h

Re: [PATCH 02/10] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

Hi Sergei, On Friday, 12 January 2018 17:14:33 EET Sergei Shtylyov wrote: > On 01/12/2018 03:58 AM, Laurent Pinchart wrote: > > The internal LVDS encoders now have their own DT bindings, representing > > them as part of the DU is deprecated. > > > > Signed-off-by: Laurent Pinchart > >

[PATCH] drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha

Mali dp needs to disable pixel alpha blending (use layer alpha blending) to display color formats that do not contain alpha bits per pixel Signed-off-by: Ayan Kumar Halder --- drivers/gpu/drm/arm/malidp_planes.c | 27 ++- 1 file changed, 22

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > Hi Ville, > > For some strange reason your email disappeared from the Cc list. Perhaps it's > the > ä that confuses something somewhere. > > So I'll just forward this directly to you. > > Can you please take a look? This patch

[PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock

The pixel clock is optional. When available, it offers a better preciseness for timing computations and allows to reduce the extra dsi bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent). Signed-off-by: Philippe Cornu --- Changes in v2: Improve px_clk

Re: [PATCH] drm: add drm_format_alpha_bits

On Fri, Jan 12, 2018 at 04:11:38PM +, Ayan Halder wrote: > On Fri, Jan 12, 2018 at 05:53:33PM +0200, Ville Syrj?l? wrote: > > On Fri, Jan 12, 2018 at 03:43:49PM +, Ayan Halder wrote: > > > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote: > > > > On Fri, Jan 12, 2018 at

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 Christoph Haag changed: What|Removed |Added Summary|Compton weird colors|[bisected]

  1   2   3   >