From: Stefan Christ
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double
On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/2/2017 3:21 PM, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/1/2017 10:02 PM, Ville Syrjälä
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #8 from fin4...@hotmail.com ---
Alex, thanks for the new firmware. Still Bios recognition errors at boot, but
otherwise ok.
[3.461112] [drm] BIOS signature incorrect 20 7
[3.461117] amdgpu :01:00.0: Invalid PCI ROM header
On 02/01/2017 01:17 PM, Andrzej Hajda wrote:
Hi Archit,
Sorry for spamming, forgot to add the list.
This quite big patchset adds support for 4K Ultra HD modes in SiI8620 MHL
bridge.
To support it full MHL3 protocol and its sub-protocols should be implemented.
Patchset contains also various
Regards
Shashank
On 2/2/2017 3:21 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> >> Geminilake platform has a native HDMI 2.0 controller, and is
> >> capable of
Hi Dave,
this is the Etnaviv feature pull request for 4.11.
It includes code cleanups from Bhumika and Liviu, a significant shader
performance fix and additions to the cmdstream validator from Wladimir
and the addition of a cmdbuf suballocator by myself.
The suballocator improves performance on
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> >> than
The module is currently names "meson.ko" which can lead to some
confusion, this patches renames it "meson-drm.ko"
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
The platform driver name is currently "meson" which can lead to some
confusion, this patch renames it to "meson-drm" and removes the owner
attribute.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 3 +--
1 file changed, 1 insertion(+), 2
This patchset is a simple fixup to rename the confusion possible
module and driver name "meson" to a more explicit "meson-drm" name.
Neil Armstrong (2):
drm: meson: rename module name to meson-drm
drm: meson: rename driver name to meson-drm
drivers/gpu/drm/meson/Makefile| 6 +++---
On Thu, Feb 02, 2017 at 09:36:32AM +, Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> module reference and may live
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #15 from Samuel Pitoiset ---
(In reply to Józef Kucia from comment #13)
> (In reply to Samuel Pitoiset from comment #12)
> > Well yeah, it's definitely unrelated to Mesa/RadeonSI. The app should check
> >
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing
Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
[SNIP]
OTOH the people running the kernel aren't always the same people
building it, so the downside is that this would potentially delay
getting X86_PAT enabled.
And exactly for this reason I would rather like to keep the warning.
Regards,
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #10 from Samuel Pitoiset ---
Which version of Total War: Warhammer?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=99637
--- Comment #4 from Nayan Deshmukh ---
(In reply to Michel Dänzer from comment #3)
> This report should remain open until the fix lands on the 17.0 branch.
I will nominate the patch for the 17.0 branch.
--
You are
On Wed, Feb 01, 2017 at 12:50:48PM -0800, Eric Anholt wrote:
> Gabriel Krisman Bertazi writes:
>
> > Instead of receiving the num_crts as a parameter, we can read it
> > directly from the mode_config structure. I audited the drivers that
> > invoke this helper and I
https://bugs.freedesktop.org/show_bug.cgi?id=99549
--- Comment #1 from Marek Olšák ---
Try to disable post processing in drirc.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Michel Dänzer changed:
What|Removed |Added
Resolution|FIXED |---
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Matt Whitlock changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> Jani Nikula writes:
>
> > On Tue, 31 Jan 2017, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a
On Thu, 02 Feb 2017, Shuah Khan wrote:
> Change drm_helper_probe_single_connector_modes() to print an error to
> report connector disconnected status instead of a debug message.
>
> When this condition occurs, application doesn't know the real error and
> reports it as
101 - 123 of 123 matches
Mail list logo