The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-
2011-12-13 14:03 keltezéssel, Joshua Roys írta:
> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>> I get only black screen even during installation unless booted
>> with nomo
- Original Message -
> From: "Eugene Teo"
> To: "Xi Wang"
> Cc: "David Airlie" , dri-devel@lists.freedesktop.org,
> linux-ker...@vger.kernel.org,
> secur...@kernel.org, "Dave Airlie"
> Sent: Wednesday, 14 December, 2011 1:16:49 PM
> Subject: Re: [PATCH] drm: integer overflow in drm_mod
2011/12/14 Boszormenyi Zoltan :
> 2011-12-13 14:03 keltezéssel, Joshua Roys írta:
>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>>> I get only black screen even during i
On Wed, Dec 14, 2011 at 2:00 AM, batouzo wrote:
> On 12/14/2011 12:47 AM, Jerome Glisse wrote:
>> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote:
>>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>> Allocated in drm_vblank_init+0
On Wed, 2011-12-14 at 13:04 +, Kavuri, Sateesh wrote:
> + /* Data block offset in CEA extension block */
> + start_offset = 4;
> + end_offset = edid_ext[2];
> +
> + /* 3D vars */
> + int multi_present = 0;
Pretty sure kernel style frowns upon mixed decls and code.
> +
https://bugs.freedesktop.org/show_bug.cgi?id=43829
Bug #: 43829
Summary: Resuming my AMD A4-300 based laptop leaves the screen
black
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
O
2011-12-14 15:02 keltezéssel, Alex Deucher írta:
> 2011/12/14 Boszormenyi Zoltan :
>> 2011-12-13 14:03 keltezéssel, Joshua Roys írta:
>>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
I have a new ASUS K53TA notebook with AMD A4-3300 CPU
and an extra Radeon HD6550M. I installed Fedora
On Wed, Dec 14, 2011 at 08:00:04AM +0100, batouzo wrote:
> On 12/14/2011 12:47 AM, Jerome Glisse wrote:
> > On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote:
> >> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote:
> >>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
> >>>
> > Allocated in drm_
On 12/14/2011 03:10 PM, Alex Deucher wrote:
>> Though, the 60 second delay may influence the rarity of hitting BUG (it
>> was the case with netconsole's 60sec wait).
>> Should I just remove loading of this firmware?
>>
> Make sure the ucode is available in your initrd or kernel image or
> filesyst
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>
>>> Though, the 60 second delay may influence the rarity of hitting BUG (it
>>> was the case with netconsole's 60sec wait).
>>> Should I just remove loading of this firmware?
>>>
>> Make sure the ucode
https://bugs.freedesktop.org/show_bug.cgi?id=43835
Bug #: 43835
Summary: System crashes when radeon firmware blob (R520_cp.bin)
is installed
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
On 12/14/2011 05:40 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
>> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>>
Though, the 60 second delay may influence the rarity of hitting BUG (it
was the case with netconsole's 60sec wait).
Should I just remove l
On Wed, Dec 14, 2011 at 08:34:29AM -0500, David Airlie wrote:
>
> - Original Message -
> > From: "Eugene Teo"
> > To: "Xi Wang"
> > Cc: "David Airlie" , dri-devel@lists.freedesktop.org,
> > linux-ker...@vger.kernel.org,
> > secur...@kernel.org, "Dave Airlie"
> > Sent: Wednesday, 14 Dec
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #1 from Alex Deucher 2011-12-14 09:19:34 PST ---
In the future, please attach the dmesg and log files directly. It looks like
it's a problem with acceleration (which is available without the firmware). I
don't see any oops or backtr
On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
> On 12/14/2011 05:40 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
>>> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>>>
> Though, the 60 second delay may influence the rarity of hitting BUG (it
> was the case w
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #2 from Alex Deucher 2011-12-14 09:22:37 PST ---
which is NOT available without the firmware
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
On Wed, 14 Dec 2011 19:00:15 +0900
Joonyoung Shim wrote:
> The exynos fimd supports 5 window overlays. Only one window overlay of
> fimd is used by the crtc, so we need plane feature to use the rest
> window overlays.
>
> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
> i
Hi Linus,
simple one just one pci ids patch from Alex,
I know Keith has some patches outstanding in his queue and I know they are
probably more than you'll want to merge at this point, I'm off until next
week, so Keith if you do send a pull request you may as well send to
Linus, since I know
On 12/14/2011 06:21 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
>> On 12/14/2011 05:40 PM, Alex Deucher wrote:
>>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
>> Though, the 60 second delay may influence
(ignore original, this one comes with a believable changelog).
> Hi Linus,
>
> simple one just one pci ids patch from Alex,
>
> I know Keith has some patches outstanding in his queue and I know they are
> probably more than you'll want to merge at this point, I'm off until next
> week, so Kei
On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
> On 12/14/2011 06:21 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
>>> On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
> On 12/14/2011 03:10 PM, Alex Deucher wrot
On 12/14/2011 06:40 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
> AMD develops and releases the ucode images. No source is available.
>
>>
>> This means that entire firmeware of GFX card is flashed on bootup?
>> Btw this is a form of virus protection you could say
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #3 from Camaleón 2011-12-14 09:56:05 PST ---
(In reply to comment #1)
> In the future, please attach the dmesg and log files directly.
Will do, sorry.
> It looks like it's a problem with acceleration (which is available without
>
On Wed, Dec 14, 2011 at 12:49 PM, batouzo wrote:
> On 12/14/2011 06:40 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
>
>> AMD develops and releases the ucode images. No source is available.
>>
>>>
>>> This means that entire firmeware of GFX card is flashed on bootup
On Tue, Dec 13, 2011 at 08:18:03PM -0600, Rob Clark wrote:
> On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote:
> > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Update to reflect changes in:
> >> "drm: add an fb creation ioctl that takes a pixel format v5
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #7 from GhostlyDeath 2011-12-14 11:11:21
PST ---
This only affects textures, whether they were created with image loading or if
they were created with PBOs.
Anything that does not use textures, appear how they are supposed to appear
https://bugs.freedesktop.org/show_bug.cgi?id=43698
Alex Deucher changed:
What|Removed |Added
Attachment #54302|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #16 from Przemyslaw Kochanski 2011-12-14
17:38:59 PST ---
Created attachment 54445
--> https://bugs.freedesktop.org/attachment.cgi?id=54445
output of glxinfo
I'm experiencing the same issue on Ubuntu 11.10. I'm ready to provide al
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #17 from Przemyslaw Kochanski 2011-12-14
17:39:45 PST ---
Created attachment 54446
--> https://bugs.freedesktop.org/attachment.cgi?id=54446
gdb gnome-shell backtrace
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cg
On 12/15/2011 02:26 AM, Jesse Barnes wrote:
On Wed, 14 Dec 2011 19:00:15 +0900
Joonyoung Shim wrote:
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specifi
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-
On Tue, Dec 13, 2011 at 8:55 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> tests/modetest/modetest.c | 166
> ++---
> 1 files changed, 157 insertions(+), 9 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/mod
On Wed, Dec 14, 2011 at 1:15 AM, Joonyoung Shim wrote:
> The variables(bo_handles, pitches and offsets) are the array having 4
> elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) *
> 4.
>
> Signed-off-by: Joonyoung Shim
Tested-by: Rob Clark
> ---
> xf86drmMode.c | 6 ++
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/
From: Rob Clark
Signed-off-by: Rob Clark
---
This one is a bit f-ugly.. kms_bo_create() and dumb-scanout alloc only
really knows about allocating 4byte/pixel buffers, so we just allocate
oversized buffers and use the part we need. It is functional enough
to test the driver (or at least omapdrm)
From: Rob Clark
The first patch updates omapdrm for API changes introduced when addfb2
support (for multi-planar fb's) was added (in drm-next). The next patch
adds drm plane (overlay) support, with CRTCs using private plane objects
to avoid code duplication between the CRTC and plane. (This dep
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 53 +-
drivers/staging/omapdrm/omap_fb.c| 99 ++---
drivers/staging
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinn
Hi Keith,
I've noticed that you merged my patch "rm/i915: properly prefault for
pread/pwrite" into your -fixes branch (which I assume is headed for
3.2). Please remove that from your queue again for the following
reasons:
- The right thing to do is to fix up the prefault handlers in pagemap.h
- I
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
>> drm_vblank_cleanup+0x78/0x90 [drm]
>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>> drm_vblank_cleanup+0x48/0x90 [drm]
>>
>> It is Amd Bulldozer computer, with Radeon card:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #4 from Alexandre Demers
2011-12-13 17:48:47 PST ---
Strangely, when rebisecting, I found commit
a34815b96f9a21b3a2e2912dfd0d994acd2855e3 to be the bad one... It is really near
to the first one. So, I'm retesting both to be sure.
--
On 12/14/2011 12:47 AM, Jerome Glisse wrote:
> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote:
>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote:
>>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>>>
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x7
The variables(bo_handles, pitches and offsets) are the array having 4
elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) *
4.
Signed-off-by: Joonyoung Shim
---
xf86drmMode.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmM
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-
2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta:
> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>> I get only black screen even during installation unless booted
>> with nomo
- Original Message -
> From: "Eugene Teo"
> To: "Xi Wang"
> Cc: "David Airlie" , dri-devel at lists.freedesktop.org,
> linux-kernel at vger.kernel.org,
> security at kernel.org, "Dave Airlie"
> Sent: Wednesday, 14 December, 2011 1:16:49 PM
> Subject: Re: [PATCH] drm: integer overflow i
2011/12/14 Boszormenyi Zoltan :
> 2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta:
>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>>> I get only black screen even during i
On Wed, Dec 14, 2011 at 2:00 AM, batouzo wrote:
> On 12/14/2011 12:47 AM, Jerome Glisse wrote:
>> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote:
>>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>> Allocated in drm_vblank_init+0
SIDE_BY_SIDE_FULL = 0x3,
> +L_DEPTH = 0x4,
> +L_DEPTH_GFX_GFX_DEPTH = 0x5,
> +TOP_BOTTOM = 0x6, /* 0x7 is reserved for future */
> +SIDE_BY_SIDE_HALF = 0x8 /* 0x9 onwards is reserved for future
> */
> +};
These don't match the bit shifts you used earlier.
- 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.freedesktop.org/archives/dri-devel/attachments/20111214/cb789388/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=43829
Bug #: 43829
Summary: Resuming my AMD A4-300 based laptop leaves the screen
black
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
O
2011-12-14 15:02 keltez?ssel, Alex Deucher ?rta:
> 2011/12/14 Boszormenyi Zoltan :
>> 2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta:
>>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
I have a new ASUS K53TA notebook with AMD A4-3300 CPU
and an extra Radeon HD6550M. I installed Fedora
On Wed, Dec 14, 2011 at 08:00:04AM +0100, batouzo wrote:
> On 12/14/2011 12:47 AM, Jerome Glisse wrote:
> > On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse
> > wrote:
> >> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote:
> >>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
> >>>
> > Allocated in
On 12/14/2011 03:10 PM, Alex Deucher wrote:
>> Though, the 60 second delay may influence the rarity of hitting BUG (it
>> was the case with netconsole's 60sec wait).
>> Should I just remove loading of this firmware?
>>
> Make sure the ucode is available in your initrd or kernel image or
> filesyst
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>
>>> Though, the 60 second delay may influence the rarity of hitting BUG (it
>>> was the case with netconsole's 60sec wait).
>>> Should I just remove loading of this firmware?
>>>
>> Make sure the ucode
https://bugs.freedesktop.org/show_bug.cgi?id=43835
Bug #: 43835
Summary: System crashes when radeon firmware blob (R520_cp.bin)
is installed
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
On 12/14/2011 05:40 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
>> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>>
Though, the 60 second delay may influence the rarity of hitting BUG (it
was the case with netconsole's 60sec wait).
Should I just remove l
On Wed, Dec 14, 2011 at 08:34:29AM -0500, David Airlie wrote:
>
> - Original Message -
> > From: "Eugene Teo"
> > To: "Xi Wang"
> > Cc: "David Airlie" , dri-devel at
> > lists.freedesktop.org, linux-kernel at vger.kernel.org,
> > security at kernel.org, "Dave Airlie"
> > Sent: Wednesda
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #1 from Alex Deucher 2011-12-14 09:19:34 PST
---
In the future, please attach the dmesg and log files directly. It looks like
it's a problem with acceleration (which is available without the firmware). I
don't see any oops or backt
On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
> On 12/14/2011 05:40 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
>>> On 12/14/2011 03:10 PM, Alex Deucher wrote:
>>>
> Though, the 60 second delay may influence the rarity of hitting BUG (it
> was the case w
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #2 from Alex Deucher 2011-12-14 09:22:37 PST
---
which is NOT available without the firmware
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are th
On Wed, 14 Dec 2011 19:00:15 +0900
Joonyoung Shim wrote:
> The exynos fimd supports 5 window overlays. Only one window overlay of
> fimd is used by the crtc, so we need plane feature to use the rest
> window overlays.
>
> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
> i
Hi Linus,
simple one just one pci ids patch from Alex,
I know Keith has some patches outstanding in his queue and I know they are
probably more than you'll want to merge at this point, I'm off until next
week, so Keith if you do send a pull request you may as well send to
Linus, since I know
On 12/14/2011 06:21 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
>> On 12/14/2011 05:40 PM, Alex Deucher wrote:
>>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
>> Though, the 60 second delay may influence
(ignore original, this one comes with a believable changelog).
> Hi Linus,
>
> simple one just one pci ids patch from Alex,
>
> I know Keith has some patches outstanding in his queue and I know they are
> probably more than you'll want to merge at this point, I'm off until next
> week, so Kei
On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
> On 12/14/2011 06:21 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote:
>>> On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote:
> On 12/14/2011 03:10 PM, Alex Deucher wrot
On 12/14/2011 06:40 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
> AMD develops and releases the ucode images. No source is available.
>
>>
>> This means that entire firmeware of GFX card is flashed on bootup?
>> Btw this is a form of virus protection you could say
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #3 from Camale?n 2011-12-14 09:56:05 PST ---
(In reply to comment #1)
> In the future, please attach the dmesg and log files directly.
Will do, sorry.
> It looks like it's a problem with acceleration (which is available without
>
On Wed, Dec 14, 2011 at 12:49 PM, batouzo wrote:
> On 12/14/2011 06:40 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote:
>
>> AMD develops and releases the ucode images. ?No source is available.
>>
>>>
>>> This means that entire firmeware of GFX card is flashed on bootup
On Tue, Dec 13, 2011 at 08:18:03PM -0600, Rob Clark wrote:
> On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote:
> > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Update to reflect changes in:
> >> "drm: add an fb creation ioctl that takes a pixel format v5
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #7 from GhostlyDeath 2011-12-14
11:11:21 PST ---
This only affects textures, whether they were created with image loading or if
they were created with PBOs.
Anything that does not use textures, appear how they are supposed to appear
https://bugs.freedesktop.org/show_bug.cgi?id=43698
Alex Deucher changed:
What|Removed |Added
Attachment #54302|application/octet-stream|text/plain
mime type|
On Tue, Dec 13, 2011 at 8:55 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> ?tests/modetest/modetest.c | ?166
> ++---
> ?1 files changed, 157 insertions(+), 9 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/mod
On Wed, Dec 14, 2011 at 1:15 AM, Joonyoung Shim
wrote:
> The variables(bo_handles, pitches and offsets) are the array having 4
> elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) *
> 4.
>
> Signed-off-by: Joonyoung Shim
Tested-by: Rob Clark
> ---
> ?xf86drmMode.c | ? ?6 +
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/
From: Rob Clark
Signed-off-by: Rob Clark
---
This one is a bit f-ugly.. kms_bo_create() and dumb-scanout alloc only
really knows about allocating 4byte/pixel buffers, so we just allocate
oversized buffers and use the part we need. It is functional enough
to test the driver (or at least omapdrm)
Thanks for the comments. Fixed most of the issues with the earlier patch.
Sending out a
new one. Comments inline below.
> -Original Message-
> From: Adam Jackson [mailto:ajax at redhat.com]
> Sent: Tuesday, December 13, 2011 9:51 PM
> To: Kavuri, Sateesh
> Cc: dri-devel at lists.freedesk
Cc'ed Dave's work email.
On Wed, Nov 23, 2011 at 2:12 PM, Xi Wang wrote:
> There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
> if userspace passes in a large num_clips. ?The call to kmalloc would
> allocate a small buffer, and the call to fb->funcs->dirty may result
> in a memory
79 matches
Mail list logo
