https://bugzilla.kernel.org/show_bug.cgi?id=29412
Jonathan Nieder changed:
What|Removed |Added
AssignedTo|drivers_video-dri at kernel-bu |jrnieder at gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #17 from Alex Deucher 2012-04-16
23:34:23 ---
This bug can be closed.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee
On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
> I've been looking about for tools to generate EDID data but didn't find
> anything useful. Does anyone know of any tool that's more convenient than
> manually filling a struct edid and writing that to a file?
Sorry, no.
__
On 04/16/2012 12:48 PM, Thierry Reding wrote:
> * Stephen Warren wrote:
...
>>> Has there been any discussion as to how EDID data would best be represented
>>> in DT? Should it just be a binary blob or rather some textual
>>> representation?
>>
>> I think a binary blob makes sense - that's the exa
On 04/15/2012 02:39 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/13/2012 03:14 AM, Thierry Reding wrote:
>>> display-controllers = <&disp1 &disp2>;
>>> outputs = <&lvds &hdmi &tvo &dsi>;
>>
>> I don't think you need both the child nodes and those two properti
https://bugs.freedesktop.org/show_bug.cgi?id=31533
--- Comment #4 from Jos van Wolput 2012-04-16
21:47:14 UTC ---
(In reply to comment #2)
> Is this still an issue with the latest code in xf86-video-ati git master?
It's no longer an issue since the 6 commits of 2012-04-16.
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=31533
--- Comment #4 from Jos van Wolput 2012-04-16
21:47:14 UTC ---
(In reply to comment #2)
> Is this still an issue with the latest code in xf86-video-ati git master?
It's no longer an issue since the 6 commits of 2012-04-16.
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #6 from Jos van Wolput 2012-04-16
21:36:20 PDT ---
(In reply to comment #3)
> Does this kernel patch help?
I am sorry I can't patch my kernel since I use a precompiled one.
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment
es anyone know of any tool that's more convenient than
manually filling a struct edid and writing that to a file?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120416/3dd5e0f8/attachment.pgp>
hat's the exact same format it'd
> have if read over the DDC I2C bus.
DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for
EDID blobs? I could add tegra-medcom.edid if that's okay.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120416/b72246b4/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #5 from Jos van Wolput 2012-04-16
19:41:32 PDT ---
(In reply to comment #4)
> Does it works with ati driver from git ? gallium st/xorg is not really
> supported
Yes, it works without problems with xf86-video-ati driver from git.
--
Hi
> > around this bugs with proper logging (absent in this patch) much better
> > than lockup.
>
> But your workaround isn't harmless. It adds new failure modes for other
> cases that currently work. That's worse, not better.
I think that from user scope nothing (including Xorg crash) is wort
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #65 from Daniel Vetter 2012-04-16 11:24:43 PDT
---
You need to check where the dvo chip actually is, i915 has about 6 different
i2c channels. The easiest way is to use one of the i2c-tools to detect chips on
all the i2c buses that dr
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:54 Tomasz Stanislawski wrote:
> The DMABUF documentation says that the map_dma_buf callback should return
> scatterlist that is mapped into a caller's address space. In practice,
> almost none of existing implementations of DMABUF exp
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #64 from Jim Bailey 2012-04-16 11:01:27
PDT ---
Thanks for working on this Gilles. I wish I could help.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:45 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>
> For this version, the support is
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:43 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> Adds DMABUF memory type to v4l framework. Also adds the related file
> descriptor in v4l2_plane and v4l2_buffer.
>
> Signed-off-by: Tomasz Stanislawski
>[original work in
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:46 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> Adding DMABUF memory type causes videobuf to complain about not using it
> in some switch cases. This patch removes these warnings.
>
> Signed-off-by: Sumit Semwal
Acked-by:
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:48 Tomasz Stanislawski wrote:
> vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
> allocation context. That structure only stores a pointer to the physical
> device. Remove it and use the device pointer directly as t
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:51 Tomasz Stanislawski wrote:
> From: Marek Szyprowski
>
> This patch adds support for prepare/finish callbacks in VB2 allocators.
> These callback are used for buffer flushing.
>
> Signed-off-by: Marek Szyprowski
Acked-by: Laure
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:53 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:50 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz
>
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
>
> Signed-off-by: Andrzej Pietrasiewicz
>
Hi Tomasz,
On Wednesday 11 April 2012 12:06:59 Tomasz Stanislawski wrote:
> On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> > On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
[snip]
> > Also, Documentation/CodingStyle favors one variable declaration per line,
> > without commas fo
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #3 from RunetMember 2012-04-17 00:03:57 ---
Created an attachment (id=72936)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72936)
lspci
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #2 from RunetMember 2012-04-17 00:03:38 ---
Created an attachment (id=72935)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72935)
cpuinfo
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #1 from RunetMember 2012-04-17 00:03:21 ---
Created an attachment (id=72934)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72934)
dmesg
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
https://bugzilla.kernel.org/show_bug.cgi?id=43114
Summary: Can't set high engine clock for RadeonHD 6620G
Product: Drivers
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Jonathan Nieder changed:
What|Removed |Added
AssignedTo|drivers_video-dri@kernel-bu |jrnie...@gmail.com
|
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #17 from Alex Deucher 2012-04-16 23:34:23
---
This bug can be closed.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
[snip]
> diff --git a/Documentat
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #6 from Alex Deucher 2012-04-16 09:11:15 PDT
---
(In reply to comment #5)
> fbdev is linear so that should be equivalent to running X with tiling
> disabled;
> so need to test with tiling disabled.
so NO need to test with tiling d
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #5 from Alex Deucher 2012-04-16 09:10:51 PDT
---
(In reply to comment #4)
>
> > > Is testing with tiling disabled relevant given the problem happens also
> > > without
> > > X running?
> >
> > That should be equivalent.
>
> Not s
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #9 from Alex Deucher 2012-04-16 09:07:59 PDT
---
(In reply to comment #8)
>
> Brief look doesn't show me any locks there, I'll dig in.
The locking (or lack there of) would be on the kernel side.
>
> If relevant, we have the same
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #8 from Tvrtko Ursulin 2012-04-16
08:54:47 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > How to investigate this potential conflict with userspace?
> >
> > Because, as I originally wrote, without X running monitor
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #4 from Tvrtko Ursulin 2012-04-16
08:49:59 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> > frequency between screen blackouts, but my sample
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #3 from Alex Deucher 2012-04-16 08:43:47 PDT
---
(In reply to comment #2)
> radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> frequency between screen blackouts, but my sample size is small and randomness
> o
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #2 from Tvrtko Ursulin 2012-04-16
08:30:32 PDT ---
radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
frequency between screen blackouts, but my sample size is small and randomness
of the timings makes me uneasy
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #7 from Alex Deucher 2012-04-16 08:25:12 PDT
---
(In reply to comment #6)
> How to investigate this potential conflict with userspace?
>
> Because, as I originally wrote, without X running monitor comes back fine.
It's probably mis
The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: Lars-Peter Clausen
Reviewed-b
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen
Reviewed-by: Jesse Barnes
--
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Bug #: 48772
Summary: Signal unstable over Display Port on 2560x1440 monitor
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #6 from Tvrtko Ursulin 2012-04-16
08:00:52 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > forcing DPMS off and on will restore display. (I have this shell script
> > bound
> > to F12 and taping that key will restor
On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
> I've been looking about for tools to generate EDID data but didn't find
> anything useful. Does anyone know of any tool that's more convenient than
> manually filling a struct edid and writing that to a file?
Sorry, no.
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #4 from Jerome Glisse 2012-04-16
07:27:12 PDT ---
Does it works with ati driver from git ? gallium st/xorg is not really
supported
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #16
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #3 from Alex Deucher 2012-04-16 07:11:04 PDT
---
Created attachment 60065
--> https://bugs.freedesktop.org/attachment.cgi?id=60065
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugs.freedesktop.org/user
On 04/16/2012 12:48 PM, Thierry Reding wrote:
> * Stephen Warren wrote:
...
>>> Has there been any discussion as to how EDID data would best be represented
>>> in DT? Should it just be a binary blob or rather some textual
>>> representation?
>>
>> I think a binary blob makes sense - that's the exa
Hi
> Obviously if we have a dead gpu, we need to break out of this loop. But
> detecting a dead gpu (and returning an appropriate error like EIO) is the
> kernel's job.
In my case gpu isn't really dead. It works after some ioctl skip. I
understend that it is a driver bug in any case, but i thing t
https://bugs.freedesktop.org/show_bug.cgi?id=36228
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hello
> > It seems, that limiting ioctl restarting by some resonable number of trys
> > is a dirty but working way to prevent Xorg lockups.
>
> And you have audited all callpaths to make sure that they can handle
> EINTR? Up until now it was part of the libdrm api that it did not return
> EINTR..
* Stephen Warren wrote:
> On 04/16/2012 12:48 PM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> ...
> >>> Has there been any discussion as to how EDID data would best be
> >>> represented
> >>> in DT? Should it just be a binary blob or rather some textual
> >>> representation?
> >>
> >> I t
* Stephen Warren wrote:
> On 04/15/2012 02:39 AM, Thierry Reding wrote:
> > I think I like the former better. The way I understand it the children of
> > the
> > graphics node will have to be registered explicitly by the DRM driver
> > because
> > of_platform_populate() doesn't work recursively.
> -Original Message-
> From: Prathyush [mailto:prathyush.k at samsung.com]
> Sent: Saturday, April 14, 2012 8:52 PM
> To: dri-devel at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org
> Cc: inki.dae at samsung.com; subash.rp at samsung.com; prashanth.g at
> samsung.com;
> sunilm a
Hello everybody,
I hope this is the right place for this kind of questions. Otherwise I
apologize for
bothering!
I've been searching a lot but I couldn't figure this out completely,
as I wasn't able to find
any documentation.
So this is my problem:
I want to read the framebuffer of the videocard
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #65 from Daniel Vetter 2012-04-16 11:24:43 PDT ---
You need to check where the dvo chip actually is, i915 has about 6 different
i2c channels. The easiest way is to use one of the i2c-tools to detect chips on
all the i2c buses that drm
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #145 from Chris Wilson 2012-04-16
04:27:15 PDT ---
I've put some recent patches into
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=845g which makes my 845g
much more stable, though I'm still getting spurious GPU hangs under
Hi,
This is also patch set based on old version and the feature below has
already been merged to mainline. Prathyush, please DO WORK patch set based
on latest drm-next for new feature and drm-fixes for bug fixes from next
time and also include me as Maintainer.
Thanks,
Inki Dae.
> -Original
Hi Prathyush.
First of all, thanks for your patch but your patch set isn't considered for
latest exynos dmabuf.
we already updated dmabuf support for exynos drm and this is also considered
for non-continuous memory region. you can refer to git repository below:
http://git.infradead.org/users/kmp
Dear Mr. Park,
I will prepare and post a patch to lib/scatterlist.c that adds
support for initialization of sg_table from page array.
Yours sincerely,
Tomasz Stanislawski
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #64 from Jim Bailey 2012-04-16 11:01:27
PDT ---
Thanks for working on this Gilles. I wish I could help.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.
Bugzilla: https://bugzilla.redhat.com/812890
Signed
Hi,
I saw your description but please generate the patches against the
latest codes at next time.
On 4/14/12, Prathyush wrote:
> With this change, the exynos drm dmabuf module can export and
> import dmabuf of gem objects with non-continuous memory.
>
> The exynos_map_dmabuf function can create
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> so could hack it like a. disable bar 0x10 and steal BAR address,
>>> then set 0x30 to that add
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120416/ff392496/attachment.obj>
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #2 from Jos van Wolput 2012-04-16
03:23:56 PDT ---
Created attachment 60053
--> https://bugs.freedesktop.org/attachment.cgi?id=60053
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
other
cases that currently work. That's worse, not better.
- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freed
itally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120416/294af9af/attachment.pgp>
On 04/15/2012 02:39 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/13/2012 03:14 AM, Thierry Reding wrote:
>>> display-controllers = <&disp1 &disp2>;
>>> outputs = <&lvds &hdmi &tvo &dsi>;
>>
>> I don't think you need both the child nodes and those two properti
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #4 from Christoph Haag
2012-04-16 02:50:15 PDT ---
(In reply to comment #3)
> Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
> strict aliasing clean. If that's not it, maybe you can isolate the specific
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #2 from Michel D?nzer 2012-04-16 02:16:17
PDT ---
(In reply to comment #2)
> Observation : 1) glean test bufferObject failed with Mesa (git-70d038e) and
> === pass with mesa (git-5beba3d)
Can you please also always m
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #6 from Alex Deucher 2012-04-16 09:11:15 PDT ---
(In reply to comment #5)
> fbdev is linear so that should be equivalent to running X with tiling
> disabled;
> so need to test with tiling disabled.
so NO need to test with tiling di
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #5 from Alex Deucher 2012-04-16 09:10:51 PDT ---
(In reply to comment #4)
>
> > > Is testing with tiling disabled relevant given the problem happens also
> > > without
> > > X running?
> >
> > That should be equivalent.
>
> Not su
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #9 from Alex Deucher 2012-04-16 09:07:59 PDT ---
(In reply to comment #8)
>
> Brief look doesn't show me any locks there, I'll dig in.
The locking (or lack there of) would be on the kernel side.
>
> If relevant, we have the same s
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #1 from samit vats 2012-04-16 02:00:12 PDT
---
Created attachment 60049
--> https://bugs.freedesktop.org/attachment.cgi?id=60049
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #8 from Tvrtko Ursulin 2012-04-16
08:54:47 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > How to investigate this potential conflict with userspace?
> >
> > Because, as I originally wrote, without X running monitor
https://bugs.freedesktop.org/show_bug.cgi?id=48759
Bug #: 48759
Summary: [Piglit] : Regression failure observed for Glean test
bufferObject
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #4 from Tvrtko Ursulin 2012-04-16
08:49:59 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> > frequency between screen blackouts, but my sample
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #3 from Alex Deucher 2012-04-16 08:43:47 PDT ---
(In reply to comment #2)
> radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> frequency between screen blackouts, but my sample size is small and randomness
> of
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #2 from Tvrtko Ursulin 2012-04-16
08:30:32 PDT ---
radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
frequency between screen blackouts, but my sample size is small and randomness
of the timings makes me uneasy
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #7 from Alex Deucher 2012-04-16 08:25:12 PDT ---
(In reply to comment #6)
> How to investigate this potential conflict with userspace?
>
> Because, as I originally wrote, without X running monitor comes back fine.
It's probably miss
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #1 from Alex Deucher 2012-04-16 08:13:28 UTC ---
Sounds like display bandwidth/watermark issues. Does booting with
radeon.disp_priority=2 on the kernel command line in grub help? Also does
disabling tiling help?
--
Configure bugma
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #1 from Alex Deucher 2012-04-16 08:13:28 UTC
---
Sounds like display bandwidth/watermark issues. Does booting with
radeon.disp_priority=2 on the kernel command line in grub help? Also does
disabling tiling help?
--
Configure bugm
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Bug #: 48772
Summary: Signal unstable over Display Port on 2560x1440 monitor
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Hi
> > around this bugs with proper logging (absent in this patch) much better
> > than lockup.
>
> But your workaround isn't harmless. It adds new failure modes for other
> cases that currently work. That's worse, not better.
I think that from user scope nothing (including Xorg crash) is wort
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #6 from Tvrtko Ursulin 2012-04-16
08:00:52 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > forcing DPMS off and on will restore display. (I have this shell script
> > bound
> > to F12 and taping that key will restor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/04/12 07:54, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu
> wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===>
>>> but that could fail. so could hack it like a. disable bar 0x10
>>> and steal BAR address
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.
Bugzilla: https://bugzilla.redhat.com/812890
Signed
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #4 from Jerome Glisse 2012-04-16 07:27:12
PDT ---
Does it works with ati driver from git ? gallium st/xorg is not really
supported
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
On Mon, 2012-04-16 at 12:54 +0400, Anton V. Boyarshinov wrote:
> Hi
>
> > Obviously if we have a dead gpu, we need to break out of this loop. But
> > detecting a dead gpu (and returning an appropriate error like EIO) is the
> > kernel's job.
> In my case gpu isn't really dead. It works after some
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #3 from Alex Deucher 2012-04-16 07:11:04 PDT ---
Created attachment 60065
--> https://bugs.freedesktop.org/attachment.cgi?id=60065
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugs.freedesktop.org/userp
On Mon, 2012-04-16 at 15:16 +0200, Lars-Peter Clausen wrote:
> The code should obviously check the EDID feature field for EDID feature flags
> and not the color_formats field of the drm_display_info struct. Also update
> the
> color_formats field with new modes instead of overwriting the current m
The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: Lars-Peter Clausen
Reviewed-b
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen
Reviewed-by: Jesse Barnes
--
https://bugs.freedesktop.org/show_bug.cgi?id=36228
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #13 from Jeff Cook 2012-04-15
21:38:56 PDT ---
So it turns out the monitor didn't have an HDMI input.
The only way I could get it working without an HDMI-DVI cable was to downgrade
to Xorg 1.11 and install Catalyst. I'm looking forw
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #145 from Chris Wilson 2012-04-16
04:27:15 PDT ---
I've put some recent patches into
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=845g which makes my 845g
much more stable, though I'm still getting spurious GPU hangs under
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #2 from Jos van Wolput 2012-04-16
03:23:56 PDT ---
Created attachment 60053
--> https://bugs.freedesktop.org/attachment.cgi?id=60053
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #4 from Christoph Haag 2012-04-16
02:50:15 PDT ---
(In reply to comment #3)
> Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
> strict aliasing clean. If that's not it, maybe you can isolate the specific
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #1 from Michel Dänzer 2012-04-16 02:40:57 UTC
---
Please attach the Xorg.0.log file.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assign
1 - 100 of 114 matches
Mail list logo
