On Mon, Jan 30, 2017 at 12:18:07PM +, Eric Engestrom wrote:
> On Monday, 2017-01-30 11:50:52 +, Daniel Stone wrote:
> > Hi,
> >
> > On 30 January 2017 at 11:46, Petri Latvala wrote:
> > > NAK.
> > >
> > > DRIVER_VGEM is omitted from DRIVER_ANY intentionally. Vgem is unable
> > > to modese
On Monday, 2017-01-30 11:50:52 +, Daniel Stone wrote:
> Hi,
>
> On 30 January 2017 at 11:46, Petri Latvala wrote:
> > NAK.
> >
> > DRIVER_VGEM is omitted from DRIVER_ANY intentionally. Vgem is unable
> > to modeset, unable to render, practically it only supports the
> > vgem-specific tests. S
Hi,
On 30 January 2017 at 11:46, Petri Latvala wrote:
> NAK.
>
> DRIVER_VGEM is omitted from DRIVER_ANY intentionally. Vgem is unable
> to modeset, unable to render, practically it only supports the
> vgem-specific tests. See also: lib/drmtest.c, __drm_open_driver().
Yeah, I agree with this. It'
NAK.
DRIVER_VGEM is omitted from DRIVER_ANY intentionally. Vgem is unable
to modeset, unable to render, practically it only supports the
vgem-specific tests. See also: lib/drmtest.c, __drm_open_driver().
--
Petri Latvala
___
Intel-gfx mailing list
Int
Thanks Eric,
This does looks like a reasonable change to me.
I don't think there are any legacy reasons for excluding VGEM from
testing in DRIVER_ANY compatible tests.
On 2017-01-24 10:27 AM, Eric Engestrom wrote:
Signed-off-by: Eric Engestrom
---
Not tested or anything, I just happened to n
Signed-off-by: Eric Engestrom
---
Not tested or anything, I just happened to notice this code and it
looked wrong, but maybe I misunderstood what it was meant to do.
An alternative would be to just set the bits the the drivers that are
defined already, but that would require an update everytime a
