Hi Daniel,
On Friday 13 May 2011 18:16:30 Daniel Vetter wrote:
> Hi Jesse,
>
> Discussion here in Budapest with v4l and embedded graphics folks was
> extremely fruitful. A few quick things to take away - I'll try to dig
> through all
> the stuff I've learned more in-depth later (probably in a blo
Hi Daniel,
On Friday 13 May 2011 18:16:30 Daniel Vetter wrote:
> Hi Jesse,
>
> Discussion here in Budapest with v4l and embedded graphics folks was
> extremely fruitful. A few quick things to take away - I'll try to dig
> through all
> the stuff I've learned more in-depth later (probably in a blo
On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes wrote:
> On Fri, 13 May 2011 18:16:30 +0200
> Daniel Vetter wrote:
>
>> Hi Jesse,
>>
>> Discussion here in Budapest with v4l and embedded graphics folks was
>> extremely fruitful. A few quick things to take away - I'll try to dig
>> through all
>> the
On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes
wrote:
> On Fri, 13 May 2011 18:16:30 +0200
> Daniel Vetter wrote:
>
>> Hi Jesse,
>>
>> Discussion here in Budapest with v4l and embedded graphics folks was
>> extremely fruitful. A few quick things to take away - I'll try to dig
>> through all
>> th
Hi Jesse,
Discussion here in Budapest with v4l and embedded graphics folks was
extremely fruitful. A few quick things to take away - I'll try to dig
through all
the stuff I've learned more in-depth later (probably in a blog post or two):
- embedded graphics is insane. The output routing/blending/
On Fri, 13 May 2011 18:16:30 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> Discussion here in Budapest with v4l and embedded graphics folks was
> extremely fruitful. A few quick things to take away - I'll try to dig
> through all
> the stuff I've learned more in-depth later (probably in a blog post
On Fri, 13 May 2011 18:16:30 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> Discussion here in Budapest with v4l and embedded graphics folks was
> extremely fruitful. A few quick things to take away - I'll try to dig
> through all
> the stuff I've learned more in-depth later (probably in a blog post
Hi Jesse,
Discussion here in Budapest with v4l and embedded graphics folks was
extremely fruitful. A few quick things to take away - I'll try to dig
through all
the stuff I've learned more in-depth later (probably in a blog post or two):
- embedded graphics is insane. The output routing/blending/
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
> wrote:
> > Looking for comments on this. ?Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having a
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200
> Daniel Vetter wrote:
>
>> Hi Jesse,
>>
>> I like it. It's a bit of a chicken-egg api design problem, but if a
>> proof-of-concept
>> implementation exists for an embedded chip plus something to check whe
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
wrote:
> Looking for comments on this. ?Obviously if we're going to add a new type
> of KMS object, we'd better get the ioctl more or less right to begin with,
> which means having all the attributes we'd like to track, plus some
> padding, available
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox wrote:
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. ?The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stu
2011/4/25 St?phane Marchesin :
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes
> wrote:
>> On Mon, 25 Apr 2011 16:16:18 -0700
>> Keith Packard wrote:
>>
>>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes >> virtuousgeek.org> wrote:
>>>
>>> > Overlays are a bit like half-CRTCs. ?They have a locat
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
> wrote:
> > Looking for comments on this. Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having a
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200
> Daniel Vetter wrote:
>
>> Hi Jesse,
>>
>> I like it. It's a bit of a chicken-egg api design problem, but if a
>> proof-of-concept
>> implementation exists for an embedded chip plus something to check whet
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes wrote:
> Looking for comments on this. Obviously if we're going to add a new type
> of KMS object, we'd better get the ioctl more or less right to begin with,
> which means having all the attributes we'd like to track, plus some
> padding, available f
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox wrote:
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stu
2011/4/25 Stéphane Marchesin :
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
>> On Mon, 25 Apr 2011 16:16:18 -0700
>> Keith Packard wrote:
>>
>>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
>>> wrote:
>>>
>>> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>>
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter wrote:
>> Imo the real problem with formats is stride restrictions and other hw
>> restrictions (tiling, ...).
>> ARM/v4l people seem to want that to be in the kernel so that they can
>> e.g.
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter wrote:
>> Imo the real problem with formats is stride restrictions and other hw
>> restrictions (tiling, ...).
>> ARM/v4l people seem to want that to be in the kernel so that they can
>> e.g.
On Wed, Apr 27, 2011 at 03:34:42PM +0100, Chris Wilson wrote:
> On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> > On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse
> > wrote:
> > > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> > >> float scale_x, scale_y;
> > >
> > > No float
On Wed, Apr 27, 2011 at 4:34 PM, Chris Wilson
wrote:
> Or just specify the source size. You already know the output size...
Hm, I've thought that x, y are fb offsets, not width/height of the
target ... Maybe we need that,
too?
-Daniel
--
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
>> float scale_x, scale_y;
>
> No float in kernel. Would have to use fixed point.
Bleh, of course ;-) 32bit with a 16 bit shift should be good enough
for all scaling needs
-Daniel
--
Da
On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> >> float scale_x, scale_y;
> >
> > No float in kernel. Would have to use fixed point.
>
> Bleh, of course ;-) 32bit with a
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
kms driver, if that could do this), that should be
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel over
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel over
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel overlay
On Wed, Apr 27, 2011 at 03:34:42PM +0100, Chris Wilson wrote:
> On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> > On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> > >> float scale_x, scale_y;
> > >
> > > No float in ke
On Wed, Apr 27, 2011 at 4:34 PM, Chris Wilson wrote:
> Or just specify the source size. You already know the output size...
Hm, I've thought that x, y are fb offsets, not width/height of the
target ... Maybe we need that,
too?
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 4
On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> >> float scale_x, scale_y;
> >
> > No float in kernel. Would have to use fixed point.
>
> Bleh, of course ;-) 32bit with a
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
>> float scale_x, scale_y;
>
> No float in kernel. Would have to use fixed point.
Bleh, of course ;-) 32bit with a 16 bit shift should be good enough
for all scaling needs
-Daniel
--
Da
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel overlay
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
kms driver, if that could do this), that should be
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the core
> > K
> And what if you don't have a "default" plane as such. For example, OMAP3
> has one graphics plane and two video planes, and two output paths. Each
> of the planes can be assigned to zero or one outputs. To accomodate this,
> the design should allow for CRTCs without any scanout buffers.
Some TV
> I think 4cc it bit useless with RGB stuff (or maybe i just don't
> understand 4cc). For instance i think we want uniq different id for
> RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says
> rgb and than rely on additional informations for color order or
> components size.
Yes
> having a list per hardware. uint32_t would give enough room to add all
> formats even if one format is only supported by one hardware only (at
It would indeed. A point realised by the Amiga designers in 1985 and
turned into a standard of sorts with a registry and process and adopted
by folks lik
On Tue, Apr 26, 2011 at 10:16 AM, Alan Cox wrote:
>> having a list per hardware. uint32_t would give enough room to add all
>> formats even if one format is only supported by one hardware only (at
>
> It would indeed. A point realised by the Amiga designers in 1985 and
> turned into a standard of
> A lot of older hardware had one overlay that could be sourced to any
> crtc, just not simultaneously. The tricky part is the formats and
> capabilities: alpha blending, color/chromakey, gamma correction, etc.
> Even the current crtc gamma stuff is somewhat lacking in in terms of
> what hardware
> I was planning on adding a new fb ioctl to allow us to create fbs with
> specific surface format types. We could either enumerate all of the
> ones we support (a list which will grow as drivers and devices are
> added) or try to factor out commit bits into a separate surface struct:
>
> struct
On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes
wrote:
> On Mon, 25 Apr 2011 20:28:20 -0400
> Alex Deucher wrote:
>
>> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
>> wrote:
>> > On Mon, 25 Apr 2011 16:16:18 -0700
>> > Keith Packard wrote:
>> >
>> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse B
> And what if you don't have a "default" plane as such. For example, OMAP3
> has one graphics plane and two video planes, and two output paths. Each
> of the planes can be assigned to zero or one outputs. To accomodate this,
> the design should allow for CRTCs without any scanout buffers.
Some TV
On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrjälä wrote:
> On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> > wrote:
> >
> > > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > > don't drive outputs dir
On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrj?l? wrote:
> On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > > don't dr
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> wrote:
>
> > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the core
> > KMS code.
>
> A
> I think 4cc it bit useless with RGB stuff (or maybe i just don't
> understand 4cc). For instance i think we want uniq different id for
> RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says
> rgb and than rely on additional informations for color order or
> components size.
Yes
On Tue, 26 Apr 2011 11:01:30 +0100
Alan Cox wrote:
> > A lot of older hardware had one overlay that could be sourced to any
> > crtc, just not simultaneously. The tricky part is the formats and
> > capabilities: alpha blending, color/chromakey, gamma correction, etc.
> > Even the current crtc ga
On Tue, 26 Apr 2011 11:01:30 +0100
Alan Cox wrote:
> > A lot of older hardware had one overlay that could be sourced to any
> > crtc, just not simultaneously. The tricky part is the formats and
> > capabilities: alpha blending, color/chromakey, gamma correction, etc.
> > Even the current crtc ga
On Tue, Apr 26, 2011 at 10:16 AM, Alan Cox wrote:
>> having a list per hardware. uint32_t would give enough room to add all
>> formats even if one format is only supported by one hardware only (at
>
> It would indeed. A point realised by the Amiga designers in 1985 and
> turned into a standard of
> having a list per hardware. uint32_t would give enough room to add all
> formats even if one format is only supported by one hardware only (at
It would indeed. A point realised by the Amiga designers in 1985 and
turned into a standard of sorts with a registry and process and adopted
by folks lik
On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes wrote:
> On Mon, 25 Apr 2011 20:28:20 -0400
> Alex Deucher wrote:
>
>> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
>> wrote:
>> > On Mon, 25 Apr 2011 16:16:18 -0700
>> > Keith Packard wrote:
>> >
>> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Ba
> A lot of older hardware had one overlay that could be sourced to any
> crtc, just not simultaneously. The tricky part is the formats and
> capabilities: alpha blending, color/chromakey, gamma correction, etc.
> Even the current crtc gamma stuff is somewhat lacking in in terms of
> what hardware
> I was planning on adding a new fb ioctl to allow us to create fbs with
> specific surface format types. We could either enumerate all of the
> ones we support (a list which will grow as drivers and devices are
> added) or try to factor out commit bits into a separate surface struct:
>
> struct
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
wrote:
> On Mon, 25 Apr 2011 16:16:18 -0700
> Keith Packard wrote:
>
>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > virtuousgeek.org> wrote:
>>
>> > Overlays are a bit like half-CRTCs. ?They have a location and fb, but
>> > don't drive outputs
On Mon, 25 Apr 2011 16:52:58 -0700, Jesse Barnes
wrote:
> struct drm_mode_surface {
> enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
> int depth;
> enum packing; /* some list of packing types? */
> ...
> };
Might just make a uint32_t 'type', predefine some obvious
On Mon, 25 Apr 2011 16:52:58 -0700, Jesse Barnes
wrote:
> struct drm_mode_surface {
> enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
> int depth;
> enum packing; /* some list of packing types? */
> ...
> };
Might just make a uint32_t 'type', predefine some obvious
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher wrote:
> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> >> wrote:
> >>
> >> > Overlays are a bit like half-CRTCs
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher wrote:
> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes
> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes >> virtuousgeek.org> wrote:
> >>
> >> > Overlays are a bit
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes wrote:
> On Mon, 25 Apr 2011 16:16:18 -0700
> Keith Packard wrote:
>
>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
>> wrote:
>>
>> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>> > don't drive outputs directly. Add
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
> On Mon, 25 Apr 2011 16:16:18 -0700
> Keith Packard wrote:
>
>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
>> wrote:
>>
>> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>> > don't drive outputs directly. Add su
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes
> wrote:
>
> > Yes, that matches my understanding as well. I've deliberately made the
> > implementation flexible there though, under the assumption that some
> > hardware allows a plane
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > Yes, that matches my understanding as well. I've deliberately made the
> > implementation flexible there though, under the assumption that some
> > hardware
On Mon, 25 Apr 2011 16:35:20 -0700
Stéphane Marchesin wrote:
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> >> wrote:
> >>
> >> > Overlays are a bit like half-CRTC
On Mon, 25 Apr 2011 16:35:20 -0700
St?phane Marchesin wrote:
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes
> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes >> virtuousgeek.org> wrote:
> >>
> >> > Overlays are a
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes
wrote:
> Yes, that matches my understanding as well. I've deliberately made the
> implementation flexible there though, under the assumption that some
> hardware allows a plane to be directed at more than one CRTC (though
> probably not simultane
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes
wrote:
> Yes, that matches my understanding as well. I've deliberately made the
> implementation flexible there though, under the assumption that some
> hardware allows a plane to be directed at more than one CRTC (though
> probably not simultane
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
> On Mon, 25 Apr 2011 16:16:18 -0700
> Keith Packard wrote:
>
>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes > virtuousgeek.org> wrote:
>>
>> > Overlays are a bit like half-CRTCs. ?They have a location and fb, but
>> > don't drive outputs di
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
> wrote:
>
> > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the core
> > KMS code.
>
> Are ov
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard wrote:
> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > Overlays are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the core
> > KMS co
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
wrote:
> Overlays are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
Are overlays/underlays not associated with a specific CRTC? To my mind,
overlays
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
wrote:
> Overlays are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
Are overlays/underlays not associated with a specific CRTC? To my mind,
overlays
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
which means having all the attributes we'd like to track, plus some
padding, available from the outset.
So I'd like comments on this; the whole appro
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
which means having all the attributes we'd like to track, plus some
padding, available from the outset.
So I'd like comments on this; the whole appro
74 matches
Mail list logo
