On Tue, Aug 09, 2016 at 08:07:24AM +0200, Daniel Vetter wrote:
> On Mon, Aug 08, 2016 at 05:04:03PM +0100, Brian Starkey wrote:
> > Hi,
> >
> > On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
> > > > Hi Russell,
>
ge to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/740246d5/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=151831
--- Comment #5 from Andre ---
eh, do what? ..may if you give complete howto for my sabayon/gentoo system?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Aug 9, 2016 at 9:53 PM, Chris Wilson
wrote:
> On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote:
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
>> requires 37 bits to represent, but âintâ only has 32 bits
>> [-Wsh
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/61421dc5/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=151831
--- Comment #4 from Alex Deucher ---
(In reply to Andre from comment #3)
> I'm using mesa 12.0.1
> The only thing that works is downgrading kernel to 4.5
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=151831
--- Comment #3 from Andre ---
I'm using mesa 12.0.1
The only thing that works is downgrading kernel to 4.5
had the Problem with kernel 4.6.2 too
I'm on Sabayon
--
You are receiving this mail because:
You are watching the assignee of the bug.
Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 71 --
1 file changed, 67 insertions(+), 4 d
Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.
With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI code
Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/i2c/tda998x_drv.c | 84 +
Changes since first version [1] of this series:
- "drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata"
- Change audio in tda998x pdata to audio_params to match the naming in
private data struct
- Skip IEC958_AES2 byte when writing status bytes to registers
- Turn AFM
On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle wrote:
> On Tue, 9 Aug 2016, Daniel Vetter wrote:
>> So if you want the kernel to VT-switch, then imo just enable CONFIG_VT. It
>> gets the job done, no need for a new uapi (and all the resulting churn in
>> userspace). Of course the other bits in your pl
On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote:
> Recent versions of gcc say this:
>
> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
> requires 37 bits to represent, but âintâ only has 32 bits
> [-Wshift-overflow=]
>
> Reported-by: David Binderman
> Signed-o
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #12 from Stas Sergeev ---
Created attachment 228121
--> https://bugzilla.kernel.org/attachment.cgi?id=228121&action=edit
Xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #11 from Stas Sergeev ---
Created attachment 228111
--> https://bugzilla.kernel.org/attachment.cgi?id=228111&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #10 from Alex Deucher ---
Please attach your dmesg output and xorg log (if running X).
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Aug 08, 2016 at 05:48:20PM -0600, Shuah Khan wrote:
> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++--
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
V2: Rebase
Signed-off-by: Shashank Sharma
Rev
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
V2: rebase
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/video/hdmi.c | 4 ++
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma
V2: Ad
This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
supported for HDMI 2.0 4k modes.
Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #9 from Stas Sergeev ---
(In reply to Alex Deucher from comment #8)
> By default the hw controls the fan based on temperature, etc.
For me not.
> Not all cards have a fan control. If you do, then the following standard
> HWMON
> pwm
https://bugzilla.kernel.org/show_bug.cgi?id=119211
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #8 f
This enables panic message output support in simpledrm.
simpledrm has a fixed buffer that is set up to be scanned out
and the virtual address is already available.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 24
1 file changed, 24 inser
This adds support for outputting kernel messages on panic().
The drivers that supports it, provides a framebuffer that the
messages can be rendered on.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_internal
This adds a way for in-kernel users to iterate over the available
DRM minors. The implementation is oops safe so the panic code
can safely use it.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_drv.c | 30 ++
include/drm/drmP.h| 13 +
2 fil
This patchset proposes a way to get output of kernel messages on the
display during panic(). The responsibility of the driver is to provide
a framebuffer with a virtual mapping that the messages can be rendered
on. Only linear RGB is supported in this version.
David Herrmann, who has worked on thi
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #7 from Jimi ---
I do not have fancontrol set up or running (it's inactive on my system). I
don't know anything about fancontrol at all. I'm running Arch Linux, so I
pretty much only am running services that I know about.
I tried wri
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/eeeb8c67/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #6 from Stas Sergeev ---
> Is this bug still happening?
For me it is happening as a hell.
And because fancontrol service also doesn't
work on my PC (I've filled another reports
about it), the problems are very real.
> I managed to c
https://bugzilla.kernel.org/show_bug.cgi?id=151831
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 f
https://bugzilla.kernel.org/show_bug.cgi?id=151831
--- Comment #1 from Andre ---
Created attachment 228061
--> https://bugzilla.kernel.org/attachment.cgi?id=228061&action=edit
glxinfo
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=151831
Bug ID: 151831
Summary: Video freezes mouse moveable, video graphical errors
like black strips an screen goes black sometimes,
system almost unresponsive.
Product: Drivers
On Fri, Aug 05, 2016 at 11:47:54AM +0200, Fabien Lahoudere wrote:
> Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
>
> Signed-off-by: Fabien Lahoudere
> ---
> .../devicetree/bindings/display/panel/nvd,9128.txt | 7 ++
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> d
On Thu, Aug 04, 2016 at 03:01:02PM -0700, Sergei Shtylyov wrote:
> Add support for the R8A7792 DU; it has 2 DPAD (RGB) outputs.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> This patch is against the 'drm/next/du' branch of Laurent Pinchart's
> 'media.git'
> repo...
>
> Documentation/devicetre
Configures the GE B850v3 LVDS/DP++ bridge on the dts file.
Cc: Martyn Welch
Cc: Martin Donnelly
Cc: Javier Martinez Canillas
Cc: Enric Balletbo i Serra
Cc: Philipp Zabel
Cc: Rob Herring
Cc: Fabio Estevam
Signed-off-by: Peter Senna Tschudin
---
Unchanged from V4
Changes from V3:
- 4/4 ins
Add a driver that create a drm_bridge and a drm_connector for the LVDS
to DP++ display bridge of the GE B850v3.
There are two physical bridges on the video signal pipeline: a
STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
firmware made it complicated for this binding to compris
Devicetree bindings documentation for the GE B850v3 LVDS/DP++
display bridge.
Cc: Martyn Welch
Cc: Martin Donnelly
Cc: Javier Martinez Canillas
Cc: Enric Balletbo i Serra
Cc: Philipp Zabel
Cc: Rob Herring
Cc: Fabio Estevam
Acked-by: Rob Herring
Signed-off-by: Peter Senna Tschudin
---
Unch
Add support to attach a drm_bridge to imx-ldb in addition to
existing support to attach a LVDS panel.
This patch does a simple code refactoring by moving code
from for_each_child_of_node iterator to a new function named
imx_ldb_panel_ddc(). This was necessary to allow the panel ddc
code to run onl
The series adds a driver that creates a drm_bridge and a drm_connector for the
LVDS to DP++ display bridge of the GE B850v3.
There are two physical bridges on the video signal pipeline: a STDP4028(LVDS to
DP) and a STDP2690(DP to DP++). The hardware and firmware made it complicated
for this bindi
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/93330e1e/attachment.html>
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
requires 37 bits to represent, but âintâ only has 32 bits
[-Wshift-overflow=]
Reported-by: David Binderman
Signed-off-by: Dave Gordon
Cc: Dave Airlie
---
include/drm/i915_drm.h | 2 +-
1 fi
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/fdc545c7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #5 from Jimi ---
I managed to check the fans while pwm1 was giving values like 68, 61, and 56,
and they were not turned on. I don't know if that means anything, because the
card was still <40 degrees and definitely not too hot to touc
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #4 from Jimi ---
Is this bug still happening? With my R9 Fury on amdgpu, cat
/sys/class/hwmon/hwmon0/pwm1 (well, in my case, it's hwmon2 because I have
another card), returns 35 on idle, not 0, but the fans are not running. Even
when
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/bcef64aa/attachment.html>
On 09/08/16 03:59, Dave Airlie wrote:
> On 8 August 2016 at 19:40, Daniel Vetter wrote:
>> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>>> Hello there,
>>>
>>> Recent versions of gcc say this:
>>>
>>> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
>>> requi
https://bugzilla.kernel.org/show_bug.cgi?id=150731
--- Comment #3 from Jimi ---
I've now confirmed this issue on Fiji (R9 Fury) as well.
--
You are receiving this mail because:
You are watching the assignee of the bug.
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/bfc330d8/attachment.html>
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v10:
- add pclk_vio_grf clock
Changes in v9:
- modify the reference phy = <&tcphy0 0>, <&tcphy1 0>;
Changes in v8: None
Changes in v7: None
Changes in v6
Hi all
This series patch is for rockchip Type-C phy and DisplayPort controller
driver.
The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and H
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/9f5e8637/attachment.html>
On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
wrote:
> Hmm.
>
> I don't have a strong opinion on this, but IMO the original idea of
> allowing a user-space driver to optimize away the dirty calls isn't a
> bad one.
> Since the xf86-video-vmware always assumed that all drms it has to deal
> wit
Hmm.
I don't have a strong opinion on this, but IMO the original idea of
allowing a user-space driver to optimize away the dirty calls isn't a
bad one.
Since the xf86-video-vmware always assumed that all drms it has to deal
with has this property set it's not using it.
The modesetting driver could
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason wh
On Tue, Aug 9, 2016 at 3:12 PM, Jose Abreu wrote:
> Will you send a new version of these patches? I have a patch
> ready that adds the new HDMI 2.0 modes to the CEA modes list in
> DRM but these modes require the addition of the new picture
> aspect ratio flags (64:27, 256:135). I can either wait
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason wh
We seem to have a bit a mess in how to describe the bus formats, with
a multitude of competing ways. Might be best to consolidate it all and
use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
modes.
Also move all the display_info related functions into drm_connector.c
(there's only
No one looks at it, only i915/gma500 lvds even bother to fill it
out. I guess a very old plan was to use this for filtering modes,
but that's already done within the edid parser.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 5 -
drivers/gpu/drm/gma500/psb_int
- Shuffle docs from drm-kms.rst into the structure docs where it makes
sense.
- Put the remaining bits into a new overview section.
One thing I've changed is around probing: Old docs says that you
_must_ use the probe helpers, which isn't correct. Helpers are always
optional.
Signed-off-by: Dan
They're only used internally within the dp helpers. Also nuke the
kerneldoc (we only document the driver interface in the drm shared
functions). And move the header file from the public include/
directory to the source files into drm_crtc_helper_internal.h, similar
to how we already have drm_crtc_i
There's not much point in kerneldoc if it's not included:
- It won't show up in the pretty html pages.
- The comments itself won't get parsed, which means 0day won't pick up
changes, resulting in stale docs fast.
Also, uapi really should be core, not helpers, so move drm_blend.c to
that. That al
Pulls in quite a lot of connector related structures (cmdline mode,
force/status enums, display info), but I think that all makes perfect
sense.
Also had to move a few more core kms object stuff into drm_modeset.h.
And as a first cleanup remove the kerneldoc for the 2 connector IOCTL
- DRM core d
It's really part of the core blob interface, and the drm_connector.c
extraction needs it too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 13 +++--
include/drm/drm_crtc.h | 6 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/dr
- Move the intro section into a DOC comment, and update it slightly.
- kernel-doc for struct drm_framebuffer!
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 26 +--
drivers/gpu/drm/drm_framebuffer.c | 35 +++
include/drm/drm_framebuffer.h | 94 ++
Also start with drm_modeset.h with the core bits, since we need
to untangle this mess somehow. That allows us to move the drm_modes.h
include to the right spot, except for the temporary connector status
enum. That will get fixed as soon as drm_connector.h exists.
Signed-off-by: Daniel Vetter
---
Accidentally the wrong file. Oops.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index c92afa82b130..3ae4c12aca08 100644
--- a/Documentation/gpu/drm-
It was added way back together with the dirty_fb ioctl, but neither
generic xfree86-modesetting nor the vmware driver use it. Everyone is
supposed to just unconditionally call the dirtyfb when they do
frontbuffer rendering.
And since unused uabi is bad uabi (there's reasons we require open
source
Since the drm_event cleanup work (as prep for fence support) drivers
don't need to bother themselves any more with this, the drm event core
takes care of that.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_c
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus poi
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 --
1
- Again adjust headings a bit, and don't mix up the initialization
sections with other stuff.
- Remove the doc for output polling, that vfunc is now properly
documented in the vfunc reference sections.
- Move the grab-bag with all the core stuff (i.e. drm_crtc.[hc]) to
the front for a more pr
- Readjust headings - we lost one level through the extraction into a
separate .rst file.
- Merge helper reference sections with the helper documentation - that
split was just an artifact of the docbook toolchain sucking at too
deep nesting levels. No such problems with sphinx.
- Move the cma
While reviewing docs I spotted that we have a few functions that
really just don't fit into their containing helper library section.
Extract them and shovel them all into a new library for random one-off
aux stuff.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 9 ++
- Move the common vtable stuff to the top
- Move "Tile Group" to a more appropriate heading level
- Throw away the old intro for the crtc helpers (it's entirely stale,
e.g. helpers have become modular years ago), and replace it with a
general intro about the motivation behind helpers.
- Reorder
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-doc at vger.kernel.org
Signed-off-by: Daniel Vetter
---
First part is just a bit of rst fallout to make drm doc builds warning free. But
then I started to split out parts of drm_crtc into their own files. framebuffers
and connectors are done, next up on my plans are encoders, and then the base
stuff around drm_mode_object, properties and blobs. I think
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/50165dea/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/69fd5f50/attachment-0001.html>
On Tue, 9 Aug 2016, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle wrote:
> > On Tue, 9 Aug 2016, Daniel Vetter wrote:
> >> So if you want the kernel to VT-switch, then imo just enable CONFIG_VT. It
> >> gets the job done, no need for a new uapi (and all the resulting churn in
>
Hi Dave,
Just one patch for -rc that fixes a printk format error.
Thanks,
Oded
The following changes since commit 36e9d08b58f44c3a02974c405ccaaa6ecfaf05b8:
drm/cirrus: Fix NULL pointer dereference when registering the fbdev
(2016-08-09 13:01:47 +1000)
are available in the git repository
-ccflags-y += -I$(FULL_AMD_DAL_PATH)/dc/inc/
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/66c6ac24/attachment.html>
Hey,
Op 08-08-16 om 23:03 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however,
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/69d43492/attachment.html>
On Tue, 9 Aug 2016, Daniel Vetter wrote:
> On Mon, Aug 08, 2016 at 01:32:51PM -0500, Scot Doyle wrote:
> > On Mon, 8 Aug 2016, Daniel Vetter wrote:
> > > On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote:
> > > > Hi all,
> > > >
> > > > I'm interested in discussing ways compositors could
Hi Sharma,
On 05-08-2016 04:37, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 8/4/2016 9:39 PM, Daniel Vetter wrote:
>> On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
>>> On 4 August 2016 at 14:15, Sharma, Shashank
>>> wrote:
On 8/4/2016 5:04 PM, Emil Velikov wrote:
- and the compile was failing.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/a6b39035/attachment.html>
|return fail instead of pass |return fail instead of pass
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/54069
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/a964b63a/attachment.html>
Thanks Daniel.
Hi Joes,
As Daniel mentioned, I have already written a patch which adds all HDMI 2.0
modes in CEA DB, and it also completes all the VICs in the DB from 1-107 (we
have 1-64 now).
I was myself waiting for aspect ratio patches to get accepted, as I needed them
for the modes.
Will
org/archives/dri-devel/attachments/20160809/8f29aa92/attachment.html>
Em Ter, 2016-08-09 Ã s 14:44 +0200, Maarten Lankhorst escreveu:
> Hey,
>
> Op 08-08-16 om 23:03 schreef Lyude:
> >
> > Since the watermark calculations for Skylake are still broken,
> > we're apt
> > to hitting underruns very easily under multi-monitor
> > configurations.
> > While it would be lo
desktop.org/archives/dri-devel/attachments/20160809/996ef7c5/attachment.html>
Subtest pread-oom: FAIL (186.552s)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/ba03995b/attachment-0001.html>
The core will do this for us now.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 006260de9dbd22..566b5634644f82 100644
--- a/drivers/gpu/drm
The core will do this for us now.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/radeon/radeon_i2c.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 9590bcd321c09a..021aa005623f80 100644
The core will do this for us now.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
b/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
index de9007e72f4e85..73e20219d431a7 100644
---
The core will do this for us now.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 33c9e1bdb114b8..ca4caf924deb81
1 - 100 of 140 matches
Mail list logo
