On Tuesday 12 March 2013 04:08 PM, Tomi Valkeinen wrote:
On 2013-03-12 08:07, Archit Taneja wrote:
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
these changes:
-
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:34 Tomi Valkeinen wrote:
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them to abbreviations for the following reasons:
* The
On Tue, Mar 12, 2013 at 12:19:38PM +0200, Tomi Valkeinen wrote:
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them to abbreviations for the following reasons:
* The timing values often need to
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
On Tuesday 12 March 2013 07:36 PM, Tomi Valkeinen wrote:
On 2013-03-12 15:06, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there
On Tuesday 12 March 2013 07:59 PM, Tomi Valkeinen wrote:
On 2013-03-12 16:01, Archit Taneja wrote:
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
So, I don't disagree with you. But I don't quite understand why we could
not use the fixed channels for now? They should work in all the
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #7 from Eugene Shalygin eugene.shaly...@gmail.com ---
it is quite interesting to note that the crash happens only using 1920x1080 and
higher screen resolution. If the resolution is lower, kwin works fine.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=60439
--- Comment #17 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #16)
(In reply to comment #15)
Further, corruption of the compiz splash screen is not fixed with this patch
(as expected of course). It appears
https://bugs.freedesktop.org/show_bug.cgi?id=62239
Priority: medium
Bug ID: 62239
Assignee: dri-devel@lists.freedesktop.org
Summary: radeon drm oops with benchmark=1 on Radeon 7950
Severity: minor
Classification: Unclassified
Let's add some more people to CC.
On Tue, Mar 12, 2013 at 05:02:49PM +0100, felix-linuxker...@fefe.de wrote:
The radeon driver does not work on my laptop.
I sent a bug report here a week ago, but got no responses.
What is the right place to send bug reports for the radeon driver?
The bug is
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Priority: medium
Bug ID: 62244
Assignee: dri-devel@lists.freedesktop.org
Summary: SIGFPE with cogl GL client in wayland
Severity: normal
Classification: Unclassified
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Bastien Nocera bugzi...@hadess.net changed:
What|Removed |Added
Version|unspecified |9.0
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=62244
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
https://bugs.freedesktop.org/show_bug.cgi?id=62246
Priority: medium
Bug ID: 62246
Assignee: dri-devel@lists.freedesktop.org
Summary: LVDS screen mode switching fails
Severity: major
Classification: Unclassified
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Please make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=43a23aa450cc19fe8996caf09e7e21ae5f6e56e8
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Sounds like vgaswitcheroo is not switching the displays from the intel to the
radeon chip.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=62246
--- Comment #3 from Felix von Leitner felix-freedesk...@fefe.de ---
The patch is on both kernels I tried, 3.9.0-rc1 and the git kernel.
I agree it sounds like vgaswitcheroo does not actually switch.
Are there any knobs for vgaswitcheroo that I
On 2013-03-12 15:06, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel
driver
has these ops
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
for now. The current omapdss code doesn't really let you
Hi,
On 2013-03-12 15:37, Laurent Pinchart wrote:
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them
On 2013-03-12 16:01, Archit Taneja wrote:
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
So, I don't disagree with you. But I don't quite understand why we could
not use the fixed channels for now? They should work in all the boards
we have, right? Or is there something with DRM
Property blob objects need to be destroyed when cleaning up to avoid
memory leaks. Go through the list of all blobs in the
drm_mode_config_cleanup() function and destroy them.
The drm_mode_config_cleanup() function needs to be moved after the
drm_property_destroy_blob() declaration. Move
The page flip handler stores the page flip event pointer and then calls
drm_vblank_get() to enable the vblank interrupt. Due to the vblank off
delay, the vblank interrupt can be enabled in the hardware at that
point, even if the vblank reference count is equal to 0. If a vblank
interrupt is
Hello,
This two patches add support for GEM CMA objects import and export as dma-buf
file handles.
There's not much to be added about the patches themselves, they're pretty
self-explicit. The code is based on the Exynos DRM DMA-BUF implementation.
The exporter role has been successfully tested
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/drm_gem_cma_helper.c | 311 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 317 insertions(+), 3 deletions(-)
diff --git
On 2013-03-12 16:38, Archit Taneja wrote:
memcmp on two structs is often not a good idea. There could be padding
bytes there, with uninitialized data. I'm not sure if that's the case
here, though, but it could well change any time (perhaps even depending
on compiler version).
I saw usage
https://bugs.freedesktop.org/show_bug.cgi?id=62239
--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Created attachment 76410
-- https://bugs.freedesktop.org/attachment.cgi?id=76410action=edit
possible fix
This patch should fix the issue.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=62239
--- Comment #2 from Michal Babej frrnz+bugs@gmail.com ---
Built 3.8.2 with the patch, verified its working. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
If ddx does not support swap, don't advertise it. We might also be
able to get rid of the vmwgfx check (I'm not quite sure the purpose of
that check vs. just checking dri2Minor.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
src/glx/dri2_glx.c | 12
1 file changed, 8
101 - 132 of 132 matches
Mail list logo
