[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 09:01:01AM +0200, Daniel Vetter wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
> >> 1. The API is geared toward updating one object at a time. Android's
> >> graphics stack needs the entire screen updated atomically to avoid
> >> tearing, and on some SoCs to avoid wedging the display hardware. Rob
> >> Clark's atomic modeset patchset worked, but copy/update/commit design
> >> meant the driver had to keep a lot more internal state.
> >>
> >
> > I'm not entirely sure how to avoid that, because at least some hw we
> > need to have the entire new-state in order to validate if it is
> > possible. I'm open to suggestions, of course, but the approach I was
> > going for was to at least do most of the boring work for this in
> > drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
>
> Yeah, I think Rob's design that trickle-feeds the entire state to the
> driver is ok (preferrably using a driver-allocated state tracking
> object or so). And then we'll let some helper code make this sane for
> most drivers.
>
> I guess especially for pageflips a mode where we just pass in new
> buffers (and leave all the blending as-is) would be useful, maybe we
> could add a flag that says "keep all other properties as-is".
That's the normal mode of operation as far as I'm concerned. If the user
doesn't specify a prop, it retains its current value.
Also I don't generally want magic properties that flip their state in
response to a change in other seemingly unrelated property. Either the
user specifies a coherent state, or we return an error.
> A second
> flag for "reset properties to defaults" would also be good, where
> default = the primary plane can display unobstructed. So mostly just
> for boot splash screens, fbcon, ...
That could be useful, or we could maintain per-master state/context.
But I don't consider the planes themselves the major issue here. It's
very easy for the client to disable all unneeded planes explicitly.
It's all the other stuff like various methods of gamma adjustments,
various other color adjustemnt thingys, possibly some blending modes,
the output quantization range stuff, etc.
> >> 2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
> >> model. At the time I was dealing with hardware where the blending engines
> >> didn't have their own framebuffer (they could only scan out constant
> >> colors or mix the output of other blocks), and you needed to gang several
> >> mixers together to drive high-res displays.
> >>
> >
> > currently you can connect a crtc to multiple encoders (at least for
> > some hw).. I suppose w/ the small addition of having a way to specify
> > an encoder's x/y offset, we could cover this sort of case?
>
> Hm, I've thought that if we convert the primary plane to a real plane
> we'd already have that. Then you can just place planes at x/y offset
> to construct the entire scanout area. Planes also have a crtc mask, as
> do connectors (through the encoders) so the n-to-m mapping is also
> possible on the output side afaics.
The all planes approach only works here if your drm_crtc is an abstract
thing composed of multiple hardware mixers/blenders/whatever you call them.
>
> >> 3. KMS doesn't support custom pixel formats, which a lot of newer SoCs
> >> use internally to cut down on bandwidth between hardware blocks.
> >
> > for custom formats, use a custom fourcc value, this should work.
> >
> > err, hmm, looks like some of the error checking that was added is a
> > bit too aggressive. What I'd propose is:
> >
> > #define DRM_FORMAT_CUSTOM 0x8000
> >
> > and then 'if (format & DRM_FORMAT_CUSTOM) ... pass through to driver ..'
>
> Imo we should just convert primary planes to real planes so that we
> can do the same table-based checking for them as we do for secondary
> planes right now.
My plan for i915 is to convert them to drm_planes but first keep them
hidden via Rob's private plane mechanism.
After that we need to figure out how we can expose them to userspace w/o
risking breaking stuff too much. Maybe a new ioctl to enumerate private
planes only? And the maybe only accept direct use of private planes via
the atomic API, not through the old setplane API. Or if people want to
use setplane we could add a flag there indicating that the user is aware
of private planes and wants to use them.
> And then we can just ditch format_check
I'd like to keep the check because it provides a small barrier against
people just adding formats in driver code w/o even updating drm_fourcc.h.
If we need the extra flexibility, let's add the custom bit, and then
user space will know all bets are off when dealing with such formats.
> and allow
> drivers to use whatever pleases them. Of course reserving a driver
> specific range would be good, otoh we could just add more stuff to the
> drm_fourcc.h header.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365
[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 10:58:51AM +0300, Ville Syrj?l? wrote: > After that we need to figure out how we can expose them to userspace w/o > risking breaking stuff too much. Maybe a new ioctl to enumerate private > planes only? And the maybe only accept direct use of private planes via > the atomic API, not through the old setplane API. Or if people want to > use setplane we could add a flag there indicating that the user is aware > of private planes and wants to use them. FWIW, in my yet to be published new stereo 3D series, I added a DRM_SET_CAP ioctl for userspace to tell DRM to expose some stereo bits in the mode structure. Making it possible for the primary plane to be exposed as a drm_plane could be the second user of this ioctl (well, assuming people are fine with this new ioctl, a whole different story, but now that'd be 2 users of it). -- Damien
[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>> 1. The API is geared toward updating one object at a time. Android's
>> graphics stack needs the entire screen updated atomically to avoid tearing,
>> and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
>> modeset patchset worked, but copy/update/commit design meant the driver had
>> to keep a lot more internal state.
>>
>
> I'm not entirely sure how to avoid that, because at least some hw we
> need to have the entire new-state in order to validate if it is
> possible. I'm open to suggestions, of course, but the approach I was
> going for was to at least do most of the boring work for this in
> drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
Yeah, I think Rob's design that trickle-feeds the entire state to the
driver is ok (preferrably using a driver-allocated state tracking
object or so). And then we'll let some helper code make this sane for
most drivers.
I guess especially for pageflips a mode where we just pass in new
buffers (and leave all the blending as-is) would be useful, maybe we
could add a flag that says "keep all other properties as-is". A second
flag for "reset properties to defaults" would also be good, where
default = the primary plane can display unobstructed. So mostly just
for boot splash screens, fbcon, ...
>> 2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
>> model. At the time I was dealing with hardware where the blending engines
>> didn't have their own framebuffer (they could only scan out constant colors
>> or mix the output of other blocks), and you needed to gang several mixers
>> together to drive high-res displays.
>>
>
> currently you can connect a crtc to multiple encoders (at least for
> some hw).. I suppose w/ the small addition of having a way to specify
> an encoder's x/y offset, we could cover this sort of case?
Hm, I've thought that if we convert the primary plane to a real plane
we'd already have that. Then you can just place planes at x/y offset
to construct the entire scanout area. Planes also have a crtc mask, as
do connectors (through the encoders) so the n-to-m mapping is also
possible on the output side afaics.
>> 3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
>> internally to cut down on bandwidth between hardware blocks.
>
> for custom formats, use a custom fourcc value, this should work.
>
> err, hmm, looks like some of the error checking that was added is a
> bit too aggressive. What I'd propose is:
>
> #define DRM_FORMAT_CUSTOM 0x8000
>
> and then 'if (format & DRM_FORMAT_CUSTOM) ... pass through to driver ..'
Imo we should just convert primary planes to real planes so that we
can do the same table-based checking for them as we do for secondary
planes right now. And then we can just ditch format_check and allow
drivers to use whatever pleases them. Of course reserving a driver
specific range would be good, otoh we could just add more stuff to the
drm_fourcc.h header.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 3:58 AM, Ville Syrj?l? wrote: >> Imo we should just convert primary planes to real planes so that we >> can do the same table-based checking for them as we do for secondary >> planes right now. > > My plan for i915 is to convert them to drm_planes but first keep them > hidden via Rob's private plane mechanism. > > After that we need to figure out how we can expose them to userspace w/o > risking breaking stuff too much. Maybe a new ioctl to enumerate private > planes only? And the maybe only accept direct use of private planes via > the atomic API, not through the old setplane API. Or if people want to > use setplane we could add a flag there indicating that the user is aware > of private planes and wants to use them. just fwiw, my thinking for private/primary[1] planes was to add a new array at the end of getplaneresources. This is really all we need. Old userspace doesn't see the new field, and continues on happily. New userspace sees the primary planes (and their possible_crtcs), and realizes that if it is not using a crtc, it can possibly grab that plane for other use. BR, -R [1] I think "primary" is actually a better name, despite the fact that I initially called 'em "private"
[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter
wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>>> 1. The API is geared toward updating one object at a time. Android's
>>> graphics stack needs the entire screen updated atomically to avoid tearing,
>>> and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
>>> modeset patchset worked, but copy/update/commit design meant the driver had
>>> to keep a lot more internal state.
>>>
>>
>> I'm not entirely sure how to avoid that, because at least some hw we
>> need to have the entire new-state in order to validate if it is
>> possible. I'm open to suggestions, of course, but the approach I was
>> going for was to at least do most of the boring work for this in
>> drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
>
> Yeah, I think Rob's design that trickle-feeds the entire state to the
> driver is ok (preferrably using a driver-allocated state tracking
> object or so). And then we'll let some helper code make this sane for
> most drivers.
>
> I guess especially for pageflips a mode where we just pass in new
> buffers (and leave all the blending as-is) would be useful, maybe we
> could add a flag that says "keep all other properties as-is". A second
> flag for "reset properties to defaults" would also be good, where
> default = the primary plane can display unobstructed. So mostly just
> for boot splash screens, fbcon, ...
>
>>> 2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
>>> model. At the time I was dealing with hardware where the blending engines
>>> didn't have their own framebuffer (they could only scan out constant colors
>>> or mix the output of other blocks), and you needed to gang several mixers
>>> together to drive high-res displays.
>>>
>>
>> currently you can connect a crtc to multiple encoders (at least for
>> some hw).. I suppose w/ the small addition of having a way to specify
>> an encoder's x/y offset, we could cover this sort of case?
>
> Hm, I've thought that if we convert the primary plane to a real plane
> we'd already have that. Then you can just place planes at x/y offset
> to construct the entire scanout area. Planes also have a crtc mask, as
> do connectors (through the encoders) so the n-to-m mapping is also
> possible on the output side afaics.
yeah, that is probably better
>>> 3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
>>> internally to cut down on bandwidth between hardware blocks.
>>
>> for custom formats, use a custom fourcc value, this should work.
>>
>> err, hmm, looks like some of the error checking that was added is a
>> bit too aggressive. What I'd propose is:
>>
>> #define DRM_FORMAT_CUSTOM 0x8000
>>
>> and then 'if (format & DRM_FORMAT_CUSTOM) ... pass through to driver ..'
>
> Imo we should just convert primary planes to real planes so that we
> can do the same table-based checking for them as we do for secondary
> planes right now. And then we can just ditch format_check and allow
> drivers to use whatever pleases them. Of course reserving a driver
> specific range would be good, otoh we could just add more stuff to the
> drm_fourcc.h header.
agreed. But we also have to fix the format_check() when you try to
create an fb ;-)
BR,
-R
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark robdcl...@gmail.com wrote:
1. The API is geared toward updating one object at a time. Android's
graphics stack needs the entire screen updated atomically to avoid tearing,
and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
modeset patchset worked, but copy/update/commit design meant the driver had
to keep a lot more internal state.
I'm not entirely sure how to avoid that, because at least some hw we
need to have the entire new-state in order to validate if it is
possible. I'm open to suggestions, of course, but the approach I was
going for was to at least do most of the boring work for this in
drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
Yeah, I think Rob's design that trickle-feeds the entire state to the
driver is ok (preferrably using a driver-allocated state tracking
object or so). And then we'll let some helper code make this sane for
most drivers.
I guess especially for pageflips a mode where we just pass in new
buffers (and leave all the blending as-is) would be useful, maybe we
could add a flag that says keep all other properties as-is. A second
flag for reset properties to defaults would also be good, where
default = the primary plane can display unobstructed. So mostly just
for boot splash screens, fbcon, ...
2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
model. At the time I was dealing with hardware where the blending engines
didn't have their own framebuffer (they could only scan out constant colors
or mix the output of other blocks), and you needed to gang several mixers
together to drive high-res displays.
currently you can connect a crtc to multiple encoders (at least for
some hw).. I suppose w/ the small addition of having a way to specify
an encoder's x/y offset, we could cover this sort of case?
Hm, I've thought that if we convert the primary plane to a real plane
we'd already have that. Then you can just place planes at x/y offset
to construct the entire scanout area. Planes also have a crtc mask, as
do connectors (through the encoders) so the n-to-m mapping is also
possible on the output side afaics.
3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
internally to cut down on bandwidth between hardware blocks.
for custom formats, use a custom fourcc value, this should work.
err, hmm, looks like some of the error checking that was added is a
bit too aggressive. What I'd propose is:
#define DRM_FORMAT_CUSTOM 0x8000
and then 'if (format DRM_FORMAT_CUSTOM) ... pass through to driver ..'
Imo we should just convert primary planes to real planes so that we
can do the same table-based checking for them as we do for secondary
planes right now. And then we can just ditch format_check and allow
drivers to use whatever pleases them. Of course reserving a driver
specific range would be good, otoh we could just add more stuff to the
drm_fourcc.h header.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 09:01:01AM +0200, Daniel Vetter wrote:
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark robdcl...@gmail.com wrote:
1. The API is geared toward updating one object at a time. Android's
graphics stack needs the entire screen updated atomically to avoid
tearing, and on some SoCs to avoid wedging the display hardware. Rob
Clark's atomic modeset patchset worked, but copy/update/commit design
meant the driver had to keep a lot more internal state.
I'm not entirely sure how to avoid that, because at least some hw we
need to have the entire new-state in order to validate if it is
possible. I'm open to suggestions, of course, but the approach I was
going for was to at least do most of the boring work for this in
drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
Yeah, I think Rob's design that trickle-feeds the entire state to the
driver is ok (preferrably using a driver-allocated state tracking
object or so). And then we'll let some helper code make this sane for
most drivers.
I guess especially for pageflips a mode where we just pass in new
buffers (and leave all the blending as-is) would be useful, maybe we
could add a flag that says keep all other properties as-is.
That's the normal mode of operation as far as I'm concerned. If the user
doesn't specify a prop, it retains its current value.
Also I don't generally want magic properties that flip their state in
response to a change in other seemingly unrelated property. Either the
user specifies a coherent state, or we return an error.
A second
flag for reset properties to defaults would also be good, where
default = the primary plane can display unobstructed. So mostly just
for boot splash screens, fbcon, ...
That could be useful, or we could maintain per-master state/context.
But I don't consider the planes themselves the major issue here. It's
very easy for the client to disable all unneeded planes explicitly.
It's all the other stuff like various methods of gamma adjustments,
various other color adjustemnt thingys, possibly some blending modes,
the output quantization range stuff, etc.
2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
model. At the time I was dealing with hardware where the blending engines
didn't have their own framebuffer (they could only scan out constant
colors or mix the output of other blocks), and you needed to gang several
mixers together to drive high-res displays.
currently you can connect a crtc to multiple encoders (at least for
some hw).. I suppose w/ the small addition of having a way to specify
an encoder's x/y offset, we could cover this sort of case?
Hm, I've thought that if we convert the primary plane to a real plane
we'd already have that. Then you can just place planes at x/y offset
to construct the entire scanout area. Planes also have a crtc mask, as
do connectors (through the encoders) so the n-to-m mapping is also
possible on the output side afaics.
The all planes approach only works here if your drm_crtc is an abstract
thing composed of multiple hardware mixers/blenders/whatever you call them.
3. KMS doesn't support custom pixel formats, which a lot of newer SoCs
use internally to cut down on bandwidth between hardware blocks.
for custom formats, use a custom fourcc value, this should work.
err, hmm, looks like some of the error checking that was added is a
bit too aggressive. What I'd propose is:
#define DRM_FORMAT_CUSTOM 0x8000
and then 'if (format DRM_FORMAT_CUSTOM) ... pass through to driver ..'
Imo we should just convert primary planes to real planes so that we
can do the same table-based checking for them as we do for secondary
planes right now.
My plan for i915 is to convert them to drm_planes but first keep them
hidden via Rob's private plane mechanism.
After that we need to figure out how we can expose them to userspace w/o
risking breaking stuff too much. Maybe a new ioctl to enumerate private
planes only? And the maybe only accept direct use of private planes via
the atomic API, not through the old setplane API. Or if people want to
use setplane we could add a flag there indicating that the user is aware
of private planes and wants to use them.
And then we can just ditch format_check
I'd like to keep the check because it provides a small barrier against
people just adding formats in driver code w/o even updating drm_fourcc.h.
If we need the extra flexibility, let's add the custom bit, and then
user space will know all bets are off when dealing with such formats.
and allow
drivers to use whatever pleases them. Of course reserving a driver
specific range would be good, otoh we could just add more stuff to the
drm_fourcc.h header.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
Re: [Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 10:58:51AM +0300, Ville Syrjälä wrote: After that we need to figure out how we can expose them to userspace w/o risking breaking stuff too much. Maybe a new ioctl to enumerate private planes only? And the maybe only accept direct use of private planes via the atomic API, not through the old setplane API. Or if people want to use setplane we could add a flag there indicating that the user is aware of private planes and wants to use them. FWIW, in my yet to be published new stereo 3D series, I added a DRM_SET_CAP ioctl for userspace to tell DRM to expose some stereo bits in the mode structure. Making it possible for the primary plane to be exposed as a drm_plane could be the second user of this ioctl (well, assuming people are fine with this new ioctl, a whole different story, but now that'd be 2 users of it). -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark robdcl...@gmail.com wrote:
1. The API is geared toward updating one object at a time. Android's
graphics stack needs the entire screen updated atomically to avoid tearing,
and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
modeset patchset worked, but copy/update/commit design meant the driver had
to keep a lot more internal state.
I'm not entirely sure how to avoid that, because at least some hw we
need to have the entire new-state in order to validate if it is
possible. I'm open to suggestions, of course, but the approach I was
going for was to at least do most of the boring work for this in
drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
Yeah, I think Rob's design that trickle-feeds the entire state to the
driver is ok (preferrably using a driver-allocated state tracking
object or so). And then we'll let some helper code make this sane for
most drivers.
I guess especially for pageflips a mode where we just pass in new
buffers (and leave all the blending as-is) would be useful, maybe we
could add a flag that says keep all other properties as-is. A second
flag for reset properties to defaults would also be good, where
default = the primary plane can display unobstructed. So mostly just
for boot splash screens, fbcon, ...
2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
model. At the time I was dealing with hardware where the blending engines
didn't have their own framebuffer (they could only scan out constant colors
or mix the output of other blocks), and you needed to gang several mixers
together to drive high-res displays.
currently you can connect a crtc to multiple encoders (at least for
some hw).. I suppose w/ the small addition of having a way to specify
an encoder's x/y offset, we could cover this sort of case?
Hm, I've thought that if we convert the primary plane to a real plane
we'd already have that. Then you can just place planes at x/y offset
to construct the entire scanout area. Planes also have a crtc mask, as
do connectors (through the encoders) so the n-to-m mapping is also
possible on the output side afaics.
yeah, that is probably better
3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
internally to cut down on bandwidth between hardware blocks.
for custom formats, use a custom fourcc value, this should work.
err, hmm, looks like some of the error checking that was added is a
bit too aggressive. What I'd propose is:
#define DRM_FORMAT_CUSTOM 0x8000
and then 'if (format DRM_FORMAT_CUSTOM) ... pass through to driver ..'
Imo we should just convert primary planes to real planes so that we
can do the same table-based checking for them as we do for secondary
planes right now. And then we can just ditch format_check and allow
drivers to use whatever pleases them. Of course reserving a driver
specific range would be good, otoh we could just add more stuff to the
drm_fourcc.h header.
agreed. But we also have to fix the format_check() when you try to
create an fb ;-)
BR,
-R
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 0/4] Atomic Display Framework
On Thu, Aug 29, 2013 at 3:58 AM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: Imo we should just convert primary planes to real planes so that we can do the same table-based checking for them as we do for secondary planes right now. My plan for i915 is to convert them to drm_planes but first keep them hidden via Rob's private plane mechanism. After that we need to figure out how we can expose them to userspace w/o risking breaking stuff too much. Maybe a new ioctl to enumerate private planes only? And the maybe only accept direct use of private planes via the atomic API, not through the old setplane API. Or if people want to use setplane we could add a flag there indicating that the user is aware of private planes and wants to use them. just fwiw, my thinking for private/primary[1] planes was to add a new array at the end of getplaneresources. This is really all we need. Old userspace doesn't see the new field, and continues on happily. New userspace sees the primary planes (and their possible_crtcs), and realizes that if it is not using a crtc, it can possibly grab that plane for other use. BR, -R [1] I think primary is actually a better name, despite the fact that I initially called 'em private ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
