This publishes some new API for Intel to be able to cap the number of
VMA that libdrm_intel caches amongst its bo. This is intended to be used
by clients to prevent applications (such as the xserver) from exhausting
their per-process limits on inactive GTT mmaps whilst also mitigating
against the c
Hi,
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 nomodeset. But it's only VESA so there's no acceleration
and there's no native LCD 1366x768 resolution, only 10
Dear all,
please find below a patch that will allow overriding a monitor's EDID
with something provided by the user. This can be helpful in a number of
situations as a quick google for "edid override" or similar suggests; I
wrote it because my monitor is broken and doesn't provide any EDID at
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 nomodeset. But it's only VESA so there's no acceleration
and the
(I've been away for the past two weeks, so I'm only now catching up)
On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
> On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann wrote:
> > On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >> Thanks for the excellent discussion - it indeed is ver
Hi Greg,
Can you cherry-pick the following patches back to the stable branches:
b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
1d33e1fc8dcce667a70387b666a8b6f60153d90f
cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
They fix the internal panel setup on certain fusion laptops. I've
attached patches I cherry-pi
Evergreen and later Radeons let the driver choose a macro tile layout,
within certain constraints. If we don't set the appropriate fields
correctly, the card will use a layout that doesn't normally meet the
constraints on Evergreen tiling.
For now, select 8x8 aspect 1 macrotiles, as this makes it
On Monday 12 December 2011, Robert Morell wrote:
> >
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is
> > either
> > at the closed-source driver or at the open source one. At the time I was
On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote:
> Evergreen and later Radeons let the driver choose a macro tile layout,
> within certain constraints. If we don't set the appropriate fields
> correctly, the card will use a layout that doesn't normally meet the
> constraints on Eve
On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> Jerome pointed me to some accounting error in the DMA API debugging code and
> while I can't figure it out yet, I did notice some extreme slowness - which
> is due to the nouveau driver calling the unpopulate (now that unbind
On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:
> + if ((multi_val == STRUCTURE_PRESENT) ||
> + (multi_val == STRUCTURE_MASK_PRESENT) ) {
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x01) ==
> 0x01)
> +
On 12/13/2011 05:07 PM, Jerome Glisse wrote:
On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau d
On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> >>Jerome pointed me to some accounting error in the DMA API debugging code and
> >>while I can't figure it out
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villacís Lasso
wrote:
> By using a bootable USB stick, I could check the logs, which
> showed many segfaults at /lib64/ld-2.14.90.so .
Ouch!
Please let me know if you find anything further; I'd like to get a
revert sent upstream in the next day or so.
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villacís Lasso
> wrote:
>
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
>
> Ouch!
>
> Please let me know if you find
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote:
>
> > > >> Testing this on via would be awesome! Iirc I haven't changed anything
> > > >> in
> > > >> the via specific patches, but if it's more convenient you can also
> > > >> directly test my branch:
> > > >>
> > > >> http://cgit.f
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villacís Lasso
> wrote:
>
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
>
> Ouch!
>
> Please let me know if you find
On Sun, 13 Nov 2011 01:31:35 +0100
Christian Schmidt wrote:
> TFT/plasma televisions and projectors have become commonplace, and so
> has the use of PCs to drive them. Add the video modes specified by an
> EDID's CEA extension to the mode database for a connector.
Dave, Christian has a few patch
El 12/12/11 11:41, Keith Packard escribió:
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villacís
Lasso wrote:
Ran kernel with reverted patch for 6 hours without issues so far. Will
keep testing after work (issue happens with my home machine).
Thanks much. Let me know if it's still stable this e
(Send similar post to LKML / linux.kernel but no responses there yet)
Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
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_
> Hi!
>
> I'm not whether any drivers are still using the AGP backend?
Actually the openchrome projects KMS kernel uses a AGP backend.
> Calling unpopulate / (previous clear) each time unbind is done should be quite
> inefficient with that one, as AGP sets up its own data structures and copies
On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote:
> Hi Greg,
>
> Can you cherry-pick the following patches back to the stable branches:
> b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
> 1d33e1fc8dcce667a70387b666a8b6f60153d90f
> cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
> They fix the intern
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 Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter
wrote:
> 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:
Than
On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote:
>
> (Send similar post to LKML / linux.kernel but no responses there yet)
>
> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
>
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0
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:
>>
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+0x78/0x90 [drm]
>>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x48/0x90 [drm]
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+0x78/0x90 [drm]
Allocated in drm_vblank_init+0xbe/
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 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"
>
> This one I'm going to have to wait for the drm api merges to happ
From: Rob Clark
Since plane->fb and plane->crtc are set in drm_mode_setplane()
after update_plane(), They should be cleared after disable().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_cr
From: Rob Clark
In cases where the scanout hw is sufficiently similar between "overlay"
and traditional crtc layers, it might be convenient to allow the driver
to create internal drm_plane helper objects used by the drm_crtc
implementation, rather than duplicate code between the plane and crtc.
A
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..22ac620 100644
--- a/tests/modetest/
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
On Fri, Dec 9, 2011 at 18:44, Dave Airlie wrote:
> On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote:
>> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote:
+static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
+{
+ ? ? struct drm_device *dev = fb->dev;
+ ? ? stru
On 12/13/2011 07:48 AM, Rob Clark wrote:
> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
>> +static int
>> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
>> +struct drm_framebuffer *fb, int crtc_x, int crtc_y,
>> +unsigned int crtc_w,
On 12/13/2011 06:59 AM, Rob Clark wrote:
> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
>> From: Joonyoung Shim
>>
>> 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 creat
https://bugs.freedesktop.org/show_bug.cgi?id=43768
Bug #: 43768
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91
5_translate_token: Assertion `ifs->constant_flags[i]
== 0x0' failed.
Class
https://bugs.freedesktop.org/show_bug.cgi?id=43769
Bug #: 43769
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:658:i915
_translate_instruction: Assertion `0' failed.
Classification: Unclassified
Product:
https://bugs.freedesktop.org/show_bug.cgi?id=38661
--- Comment #3 from Vinson Lee 2011-12-12 16:50:10 PST ---
mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)
Assert still occurs.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=43770
Bug #: 43770
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit
_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.
Classification: Unclassified
Pr
https://bugs.freedesktop.org/show_bug.cgi?id=43771
Bug #: 43771
Summary: [i915g]
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:
lp_build_sample_mipmap: Assertion `img_filter == 1'
failed.
Classification
Hi, Rob.
below is my answer.
> -Original Message-
> From: Rob Clark [mailto:robdclark at gmail.com]
> Sent: Tuesday, December 13, 2011 9:48 AM
> To: Joonyoung Shim
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re:
On Fri, Dec 09, 2011 at 03:53:49PM -0800, Keith Packard wrote:
> RC6 should always work on IVB, and should work on SNB whenever IO
> remapping is disabled. RC6 never works on Ironlake. Make the default
> value for the parameter follow these guidelines. Setting the value
> to either 0 or 1 will forc
: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/6840bbf0/attachment.pgp>
Hi,
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 nomodeset. But it's only VESA so there's no acceleration
and there's no native LCD 1366x768 resolution, only 10
ame: linux-3.2-edid-override.patch
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/6f0a0de4/attachment-0001.asc>
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 nomodeset. But it's only VESA so there's no acceleration
>
(I've been away for the past two weeks, so I'm only now catching up)
On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
> On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann wrote:
> > On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >> Thanks for the excellent discussion - it indeed is ver
eedesktop.org/archives/dri-devel/attachments/20111213/5c16aa3d/attachment-0003.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-kms-rework-DP-bridge-checks.patch
Type: text/x-diff
Size: 9888 bytes
Desc: not available
URL:
<http://li
Evergreen and later Radeons let the driver choose a macro tile layout,
within certain constraints. If we don't set the appropriate fields
correctly, the card will use a layout that doesn't normally meet the
constraints on Evergreen tiling.
For now, select 8x8 aspect 1 macrotiles, as this makes it
On Monday 12 December 2011, Robert Morell wrote:
> >
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is
> > either
> > at the closed-source driver or at the open source one. At the time I was
On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote:
> Evergreen and later Radeons let the driver choose a macro tile layout,
> within certain constraints. If we don't set the appropriate fields
> correctly, the card will use a layout that doesn't normally meet the
> constraints on Eve
On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> Jerome pointed me to some accounting error in the DMA API debugging code and
> while I can't figure it out yet, I did notice some extreme slowness - which
> is due to the nouveau driver calling the unpopulate (now that unbind
= 0x8 /* 0x9 onwards is reserved for future */
> +};
If format is supposed to be an enum, why aren't you using these symbolic
values?
- 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/20111213/353b0808/attachment.pgp>
On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
>
>> Jerome pointed me to some accounting error in the DMA API debugging code and
>> while I can't figure it out yet, I did notice some extreme slowness - which
>> is due to the
On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> >>Jerome pointed me to some accounting error in the DMA API debugging code and
> >>while I can't figure it out
t day or so.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/00b01562/attachment.pgp>
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso palosanto.com> wrote:
>
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
>
> Ouch!
>
> Please let me know
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote:
>
> > > >> Testing this on via would be awesome! Iirc I haven't changed anything
> > > >> in
> > > >> the via specific patches, but if it's more convenient you can also
> > > >> directly test my branch:
> > > >>
> > > >> http://cgit.f
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso palosanto.com> wrote:
>
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
>
> Ouch!
>
> Please let me know
Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/07b5e7e5/attachment.pgp>
El 12/12/11 11:41, Keith Packard escribi?:
> On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villac??s Lasso palosanto.com> wrote:
>
>> Ran kernel with reverted patch for 6 hours without issues so far. Will
>> keep testing after work (issue happens with my home machine).
> Thanks much. Let me know if it'
(Send similar post to LKML / linux.kernel but no responses there yet)
Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
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_
> Hi!
>
> I'm not whether any drivers are still using the AGP backend?
Actually the openchrome projects KMS kernel uses a AGP backend.
> Calling unpopulate / (previous clear) each time unbind is done should be quite
> inefficient with that one, as AGP sets up its own data structures and copies
On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote:
> Hi Greg,
>
> Can you cherry-pick the following patches back to the stable branches:
> b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
> 1d33e1fc8dcce667a70387b666a8b6f60153d90f
> cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
> They fix the intern
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/268bf21b/attachment.pgp>
On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote:
>
> (Send similar post to LKML / linux.kernel but no responses there yet)
>
> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
>
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0
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+0x78/0x90 [drm]
>>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x48/0x90 [drm]
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+0x78/0x90 [drm]
Allocated in drm_vblank_init+0xbe/
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"
>
> This one I'm going to have to wait for the drm api merges to happ
From: Rob Clark
Since plane->fb and plane->crtc are set in drm_mode_setplane()
after update_plane(), They should be cleared after disable().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_cr
From: Rob Clark
In cases where the scanout hw is sufficiently similar between "overlay"
and traditional crtc layers, it might be convenient to allow the driver
to create internal drm_plane helper objects used by the drm_crtc
implementation, rather than duplicate code between the plane and crtc.
A
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..22ac620 100644
--- a/tests/modetest/
75 matches
Mail list logo
