> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Saturday, August 10, 2019 3:19 AM
> To: Auld, Matthew ; intel-
> g...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #102 from Maxim Ivanov ---
I have also compiled a kernel for myself with this patch and I can confirm it
is working correctly under amdgpu with my monitor (1920x1080 @ 75Hz) !
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #69 from ReddestDream ---
>The inconsistent nature of this bug and the fact that it sometimes doesn't
>appear suggests a race condition. I'd assume something else on the system
>happens before or after amdgpu is expecting.
>Is
This panel is used on the OpenMoko Neo FreeRunner and Neo 1973.
The code is based on the omapdrm-specific panel-tpo-td028ttec1 driver.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed td028ttec1_device to td028ttec1_panel
- Comments
This panel is used on the OMAP3 Pandora.
The code is based on the omapdrm-specific panel-tpo-td043mtea1 driver.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed td043mtea1_device to td043mtea1_panel
- Fixed typo in Toppoly name
-
This panel is used on the Gumstix Overo Palo35.
The code is based on the omapdrm-specific panel-lgphilips-lb035q02
driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
---
Changes since v1:
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use
The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB
parallel data interface and an SPI control interface.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Convert to YAML
---
.../display/panel/nec,nl8048hl11.yaml | 49 +++
1 file changed, 49
LG Display is an LCD display manufacturer. Originally formed as a joint
venture by LG Electronics and Philips Electronics, it was formerly known
as LG.Philips LCD, hence the DT vendor prefix lgphilips (which is
already in active use in the kernel).
More information is available at
This panel is used on the Nokia N900.
The code is based on the omapdrm-specific panel-sony-acx565akm driver.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed acx565akm_device to acx565akm_panel
- Comments updates
- Store width_mm and
The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor
prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and
document it as legacy.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mark the prefix as deprecated
---
This panel is used on the Zoom2/3/3630 SDP boards.
The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed nl8048_device to nl8048_panel
- Comments updates
- Store width_mm
Hello everybody,
These 9 patches have initially been posted as part of the larger "[PATCH
00/60] drm/omap: Replace custom display drivers with drm_bridge and
drm_panel" series, hence the v2 in the subject prefix.
I'm posting this second version separately per Sam's request as the rest
of the
This panel is used on the TI SDP3430 board.
The code is based on the omapdrm-specific panel-sharp-ls037v7dw01
driver.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed ls037v7dw01_device to ls037v7dw01_panel
- Renamed vcc to vdd
-
Hi Andrzej,
On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> On 08.08.2019 21:32, Laurent Pinchart wrote:
> > On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #68 from Tom B ---
Apologies for the multiple replies/emails. I think I must just have got lucky.
It worked several boots (in a row) and now only works very occasionally. I
think it was just coincidence that it worked a few times
https://bugzilla.kernel.org/show_bug.cgi?id=201285
--- Comment #9 from oyvi...@everdot.org ---
Linux yoona.everdot.org 5.2.5-Jinsol:
[0.776221] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel
[0.776416] [drm] amdgpu kernel modesetting enabled.
[0.776592] Parsing CRAT table with 1 nodes
[
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #13 from Brian Schott ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #12)
> Does using "AMD_DEBUG=nodcc" Mesa environment variable help?
It does. Exporting that in my ~/.profile makes the desktop usable.
> Could you
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #67 from Tom B ---
I had a look around at similar bugs and came across this:
https://bugs.freedesktop.org/show_bug.cgi?id=110822
It's for a 580, not a VII but the problems started at 5.1 and gives a similar
powerplay related
https://bugs.freedesktop.org/show_bug.cgi?id=111370
Bas Nieuwenhuizen changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #15 from BabylonAS ---
Thanks! I’ll wait until it gets committed to Debian repositories.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Fri, 9 Aug 2019 at 23:55, Mikhail Gavrilov
wrote:
> Finally initial problem "gnome-shell: page allocation failure:
> order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> nodemask=(null),cpuset=/,mems_allowed=0" did not happens anymore with
> latest version of the patch (I tested more than 23 hours)
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/dma-buf/Makefile
Allow for some users to surreptitiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence.
(The cost of interrupts is too darn high, to revive an old meme.)
This means that we may have a cb_list even if the signaling bit is not
enabled, so
Same as for the individual fences, we want to report the actual status
of the fence when queried.
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Petri Latvala
---
drivers/dma-buf/sync_file.c | 2 +-
1 file changed, 1 insertion(+), 1
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/dma-fence-array.c |
On 09/08/2019 04:01, Rob Herring wrote:
[...]
> I was worried too. It seems to be working pretty well though, but more
> testing would be good. I don't think there are a lot of usecases that
> use more AS than the h/w has (8 on T860), but I'm not sure.
Yeah, 8 is overkill. Some GPUs only have 4
This should be 'dce_audio_mask', not 'dce_aduio_mask'.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 2 +-
drivers/gpu/drm/amd/display/dc/dce/dce_audio.h | 6 +++---
drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 2 +-
On 08/08/2019 23:21, Rob Herring wrote:
> The midgard/bifrost GPUs need to allocate GPU heap memory which is
> allocated on GPU page faults and not pinned in memory. The vendor driver
> calls this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
>
On 08/08/2019 23:29, Rob Herring wrote:
> Up until now, a single shared GPU address space was used. This is not
> ideal as there's no protection between processes and doesn't work for
> supporting the same GPU/CPU VA feature. Most importantly, this will
> hopefully mitigate Alyssa's fear of WebGL,
While newer kbase include only the numbers of errata, older kbase
releases included one-line descriptions for each errata, which is useful
for those working on the driver. Import these descriptions. Most are
from kbase verbatim; a few I edited for clarity.
v2: Wrote a description for the
This should be 'amdgpu_dm', not 'amdpgu_dm'
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On 08/08/2019 23:21, Rob Herring wrote:
> Runtime PM resume and job timeouts both call the same sequence of
> functions, so consolidate them to a common function. This will make
> changing the reset related code easier. The MMU also needs some
> re-initialization on reset, so rework its call. In
On 08/08/2019 23:21, Rob Herring wrote:
> Setting the GPU VA when creating the GEM object doesn't allow for any
> conditional adjustments to the mapping. In preparation to support
> adjusting the mapping and per FD address spaces, restructure the GEM
> object creation to map and unmap the GEM
R-b, good stuff.
On Thu, Aug 08, 2019 at 04:21:57PM -0600, Rob Herring wrote:
> Runtime PM resume and job timeouts both call the same sequence of
> functions, so consolidate them to a common function. This will make
> changing the reset related code easier. The MMU also needs some
>
Still A-b :)
On Thu, Aug 08, 2019 at 04:21:54PM -0600, Rob Herring wrote:
> Setting the GPU VA when creating the GEM object doesn't allow for any
> conditional adjustments to the mapping. In preparation to support
> adjusting the mapping and per FD address spaces, restructure the GEM
> object
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #66 from Tom B ---
One thing I haven't mentioned is I don't have a GPU fan installed as my VII is
water cooled, it's unlikely but perhaps this explains the different behaviour
of my card to others.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=111231
--- Comment #17 from deltasquared ---
Apologies for being late to reply.
Having run mesa built from the MR branch, I have since been unable to get the
same crash when running minetest.
Certainly the apitrace capture can no longer bring my
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #65 from Tom B ---
Created attachment 145018
--> https://bugs.freedesktop.org/attachment.cgi?id=145018=edit
5.2.7 full dmesg
Full dmesg from 5.2.7, 2xdisplayport monitors the error that keeps repeating
is:
*ERROR* Failed to
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #64 from Tom B ---
Scratch that, I just rebooted with HDMI+DP and it froze as soon as SDDM
started. I was eventually able to switch TTY and the voltages looked correct
(it was boosted down) but I was never able to log in to KDE as
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #63 from Tom B ---
I've just done some testing with 5.2.7
- I still get the 135w/1.1v constant power state and crashing with DP+DP.
- HDMI+DP works, but this was my original setup when I got the VII.
Unfortunately I get random
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #62 from Peter Hercek ---
OK, I started to use 5.2.5 kernel after the my last hang up with 4.20.11. It
worked fine for 1 week. I'm trying 5.2.7 now.
It is possible something was fixed in 5.2.5 because there was one commit which
Quoting Matthew Auld (2019-08-09 23:26:42)
> From: Abdiel Janulgue
>
> Returns the available memory region areas supported by the HW.
And how does one use this information?
How does this relate to the information presented by Vulkan or OpenCL
Testcase: igt/...?
New uAPI should always come
Quoting Matthew Auld (2019-08-09 23:26:41)
> From: Abdiel Janulgue
>
> This call will specify which memory region an object should be placed.
>
> Note that changing the object's backing storage should be immediately
> done after an object is created or if it's not yet in use, otherwise
> this
Quoting Matthew Auld (2019-08-09 23:26:40)
> We are going want to able to move objects between different regions
> like system memory and local memory. In the future everything should
> be just another region.
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: CQ
Quoting Matthew Auld (2019-08-09 23:26:39)
> From: Abdiel Janulgue
>
> If there is no aperture we can't use map_gtt to map dumb buffers, so we
> need a cpu-map based path to do it. We prefer map_gtt on platforms that
> do have aperture.
>
> Signed-off-by: Abdiel Janulgue
> Cc: Daniele Ceraolo
Quoting Matthew Auld (2019-08-09 23:26:38)
> -void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> +static vm_fault_t i915_gem_fault_cpu(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *area = vmf->vma;
> + struct i915_mmap_offset *priv = area->vm_private_data;
>
Quoting Matthew Auld (2019-08-09 23:26:36)
> From: Abdiel Janulgue
>
> Add a new CPU mmap implementation that allows multiple fault handlers
> that depends on the object's backing pages.
>
> Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
> and use the zero extending
Quoting Matthew Auld (2019-08-09 23:26:35)
> From: Abdiel Janulgue
>
> This enables us to store extra data within vma->vm_private_data and assign
> the pagefault ops for each mmap instance.
>
> We replace the core drm_gem_mmap implementation to overcome the limitation
> in having only a single
Quoting Matthew Auld (2019-08-09 23:26:34)
> From: CQ Tang
>
> Signed-off-by: CQ Tang
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index
Quoting Matthew Auld (2019-08-09 23:26:33)
> From: Michal Wajdeczko
>
> HWS placement restrictions can't just rely on HAS_LLC flag.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Quoting Matthew Auld (2019-08-09 23:26:32)
> From: Daniele Ceraolo Spurio
>
> If the aperture is not available in HW we can't use a ggtt slot and wc
> copy, so fall back to regular kmap.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Abdiel Janulgue
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=201285
Sam (sammyr...@gmail.com) changed:
What|Removed |Added
CC||sammyr...@gmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=111368
Andre Klapper changed:
What|Removed |Added
Resolution|--- |INVALID
Component|General
Quoting Matthew Auld (2019-08-09 23:26:29)
> From: Daniele Ceraolo Spurio
>
> Skip both setup and cleanup of the aperture mapping if the HW doesn't
> have an aperture bar.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 36
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #29 from tempel.jul...@gmail.com ---
The patches by Nicholas are now merged in drm-next-5.4 branch (tested with
recent commit that bases the branch on 5.3-rc3), but the mouse input issue in
certain games is still unaffected.
I was
Quoting Matthew Auld (2019-08-09 23:26:25)
> From: Abdiel Janulgue
>
> Nothing to enumerate yet...
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_gem_gtt.c
Am 07.08.19 um 16:17 schrieb Chris Wilson:
Quoting Christian König (2019-08-07 14:53:12)
The only remaining use for this is to protect against setting a new exclusive
fence while we grab both exclusive and shared. That can also be archived by
looking if the exclusive fence has changed or not
Quoting Matthew Auld (2019-08-09 23:26:22)
> @@ -1017,10 +1020,14 @@ static void reloc_cache_reset(struct reloc_cache
> *cache)
> } else {
> struct i915_ggtt *ggtt = cache_to_ggtt(cache);
>
> - intel_gt_flush_ggtt_writes(ggtt->vm.gt);
> + if
Quoting Matthew Auld (2019-08-09 23:26:18)
> +struct i915_vma *intel_emit_vma_copy_blt(struct intel_engine_pool_node **p,
> +struct intel_context *ce,
> +struct i915_vma *src,
> +
Quoting Matthew Auld (2019-08-09 23:26:19)
> Using the gpu to write to some dword over a number of pages is rather
> useful, and we already have two copies of such a thing, and we don't
> want a third so move it to utils. There is probably some other stuff
> also...
>
> Signed-off-by: Matthew
Quoting Matthew Auld (2019-08-09 23:26:13)
> @@ -1369,6 +1371,8 @@ struct drm_i915_private {
> */
> resource_size_t stolen_usable_size; /* Total size minus reserved
> ranges */
>
> + struct intel_memory_region *regions[INTEL_MEMORY_UKNOWN];
If there was ever an
Quoting Matthew Auld (2019-08-09 23:26:12)
> From: Abdiel Janulgue
>
> Exposes available regions for the platform. Shared memory will
> always be available.
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
>
Quoting Matthew Auld (2019-08-09 23:26:11)
> Volatile objects are marked as DONTNEED while pinned, therefore once
> unpinned the backing store can be discarded.
Do we also have the concept of non-volatile backing store, e.g. shmemfs
(non-volatile) vs stolen (volatile)?
-Chris
Quoting Matthew Auld (2019-08-09 23:26:11)
> Volatile objects are marked as DONTNEED while pinned, therefore once
> unpinned the backing store can be discarded.
> Signed-off-by: Matthew Auld
> Signed-off-by: CQ Tang
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
I think that's quite a nice
Quoting Matthew Auld (2019-08-09 23:26:10)
> Some objects may need to be allocated as a continuous block, thinking
> ahead the various kernel io_mapping interfaces seem to expect it.
But we could always use scattergather over top...
> @@ -98,10 +101,12 @@ i915_gem_object_get_pages_buddy(struct
Quoting Matthew Auld (2019-08-09 23:26:09)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6ff01a404346..8735dea74809 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1105,6 +1105,23 @@
Quoting Matthew Auld (2019-08-09 23:26:08)
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> b/drivers/gpu/drm/i915/intel_memory_region.c
> new file mode 100644
> index ..ef12e462acb8
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -0,0 +1,175 @@
>
On Thu, Aug 08, 2019 at 05:34:45PM +0200, Gerd Hoffmann wrote:
> We must make sure our scatterlist segments are not too big, otherwise
> we might see swiotlb failures (happens with sev, also reproducable with
> swiotlb=force).
Btw, any chance I could also draft you to replace the remaining
abuses
https://bugs.freedesktop.org/show_bug.cgi?id=111366
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111365
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111347
Chris Wilson changed:
What|Removed |Added
Group||spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111368
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=111357
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111361
Chris Wilson changed:
What|Removed |Added
Component|General |Two
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=111351
Chris Wilson changed:
What|Removed |Added
Version|XOrg git|unspecified
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=111367
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111345
Chris Wilson changed:
What|Removed |Added
Version|XOrg git|unspecified
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111360
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111368
saurabhdubey0...@gmail.com changed:
What|Removed |Added
URL||https://www.cs.nmsu.edu/~jo
https://bugs.freedesktop.org/show_bug.cgi?id=111342
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111354
Chris Wilson changed:
What|Removed |Added
Group||spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111364
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111368
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=111348
Chris Wilson changed:
What|Removed |Added
Component|General |Two
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=111358
Chris Wilson changed:
What|Removed |Added
Group||spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111353
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Component|General
https://bugs.freedesktop.org/show_bug.cgi?id=111344
Chris Wilson changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=111368
Bug ID: 111368
Summary: the bug is visible at the site
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: minor
https://bugs.freedesktop.org/show_bug.cgi?id=111366
Bug ID: 111366
Summary: Operations are appearing when not needed
Product: DRI
Version: XOrg git
Hardware: Other
URL: https://www.cs.nmsu.edu/~joshagam/archive/cs574/3-dri.
https://bugs.freedesktop.org/show_bug.cgi?id=111367
Bug ID: 111367
Summary: Operator is not needed
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority:
https://bugs.freedesktop.org/show_bug.cgi?id=111365
Bug ID: 111365
Summary: operators are appearing in the content when they are
not expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=111364
Bug ID: 111364
Summary: Bugs found.
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=111362
Bug ID: 111362
Summary: pls handover your website to my company.
Product: DRI
Version: XOrg git
Hardware: Other
URL: https://www.cs.nmsu.edu/~joshagam/archive/cs574/3-dri.
https://bugs.freedesktop.org/show_bug.cgi?id=111361
Bug ID: 111361
Summary: operator inclueing content
Product: DRI
Version: XOrg git
Hardware: Other
URL: https://www.cs.nmsu.edu/~joshagam/archive/cs574/3-dri.
https://bugs.freedesktop.org/show_bug.cgi?id=111360
Bug ID: 111360
Summary: Bugs are appeared in some contents
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=111357
Bug ID: 111357
Summary: operators appearing in the content when not expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=111354
Bug ID: 111354
Summary: operators are appearing in the content when not
expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=111353
Bug ID: 111353
Summary: operators are appearing in the content when they are
not expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=111351
Bug ID: 111351
Summary: operators are appearing in the content when not
expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=111348
Bug ID: 111348
Summary: operators are appearing in the content when not
expected
Product: DRI
Version: XOrg git
Hardware: Other
URL:
1 - 100 of 104 matches
Mail list logo
