On Die, 2011-03-22 at 08:43 -0500, Ilija Hadzic wrote:
>
> On Tue, 22 Mar 2011, Michel [ISO-8859-1] Dnzer wrote:
>
> >> If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
> >> (or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
> >> changes shouldn't be necessar
On Die, 2011-03-22 at 06:16 -0500, Ilija Hadzic wrote:
> Unless I oversaw something nothing was silently ignored. I believe I
> responded to each of your comments (and comments by others), those I
> agreed with I implemented, those I didn't agree with I didn't implement.
I haven't seen any resp
On Fre, 2011-03-18 at 16:58 -0500, Ilija Hadzic wrote:
>
> This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
> can be represented. It also adds a new capability to drm_getcap ioctl so
> that the user space can check whether the new interface to drm_wait_vblank
> is suppo
Sorry about overseeing additional comments. It definitely wasn't
intentional.
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>>
>> If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
>> (or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
>> changes shoul
On Die, 2011-03-22 at 08:43 -0500, Ilija Hadzic wrote:
>
> On Tue, 22 Mar 2011, Michel [ISO-8859-1] Dnzer wrote:
>
> >> If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
> >> (or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
> >> changes shouldn't be necessar
Sorry about overseeing additional comments. It definitely wasn't
intentional.
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
(or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
changes shouldn't be
Unless I oversaw something nothing was silently ignored. I believe I
responded to each of your comments (and comments by others), those I
agreed with I implemented, those I didn't agree with I didn't implement.
-- Ilija
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
> On Fre, 2011-03-
On Die, 2011-03-22 at 06:16 -0500, Ilija Hadzic wrote:
> Unless I oversaw something nothing was silently ignored. I believe I
> responded to each of your comments (and comments by others), those I
> agreed with I implemented, those I didn't agree with I didn't implement.
I haven't seen any resp
Unless I oversaw something nothing was silently ignored. I believe I
responded to each of your comments (and comments by others), those I
agreed with I implemented, those I didn't agree with I didn't implement.
-- Ilija
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
On Fre, 2011-03
On Fre, 2011-03-18 at 16:58 -0500, Ilija Hadzic wrote:
>
> This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
> can be represented. It also adds a new capability to drm_getcap ioctl so
> that the user space can check whether the new interface to drm_wait_vblank
> is suppo
Am Sonntag, den 20.03.2011, 18:47 -0500 schrieb Ilija Hadzic:
> sorry about that, I use pine and thought that's as plain as it gets. I
> guess next time I'll try just 'mail' from command line.
Or `git send-email`?.
Thanks,
Paul
? manual: `git help send-email`
-- next part ---
Am Sonntag, den 20.03.2011, 18:47 -0500 schrieb Ilija Hadzic:
> sorry about that, I use pine and thought that's as plain as it gets. I
> guess next time I'll try just 'mail' from command line.
Or `git send-email`¹.
Thanks,
Paul
¹ manual: `git help send-email`
signature.asc
Description: Thi
On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
sorry about that, I use pine and thought that's as plain as it gets. I
guess next time I'll try just 'mail' from command line.
On Mon, 21 Mar 2011, Dave Airlie wrote:
> On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
> wrote:
>>
>> Hi Dave,
>>
>> Below is a patch against drm-next branch of 2.6
sorry about that, I use pine and thought that's as plain as it gets. I
guess next time I'll try just 'mail' from command line.
On Mon, 21 Mar 2011, Dave Airlie wrote:
On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
wrote:
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ k
On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
On Sat, 19 Mar 2011, Alex Deucher wrote:
> On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
> wrote:
>>
>> Hi Dave,
>>
>> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
>> capability to wait on vblank events for CRTCs that are greater than 1 and
>> thus cannot be repr
On Sat, 19 Mar 2011, Alex Deucher wrote:
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
capability to wait on vblank events for CRTCs that are greater than 1 and
thus cannot be represented with prim
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>>
>> I like the new param check, but I'd still prefer a new ioctl to
>> abusing
>> the old one.
>>
>
> It's not "abusing" it but extending the interface in a
> backwards-compatible manner. Introducing a new one would result in two
> ioctls that essent
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
On Sat, Mar 19, 2011 at 1:30 PM, Mario Kleiner
wrote:
>>
>> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>>>
>>> I like the new param check, but I'd still prefer a new ioctl to abusing
>>> the old one.
>>>
>>
>> It's not "abusing" it but extending the interface in a
>> backwards-compatible manner. Int
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> i
On Sat, Mar 19, 2011 at 1:30 PM, Mario Kleiner
wrote:
>>
>> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>>>
>>> I like the new param check, but I'd still prefer a new ioctl to abusing
>>> the old one.
>>>
>>
>> It's not "abusing" it but extending the interface in a
>> backwards-compatible manner. Int
On Fri, 18 Mar 2011, Jesse Barnes wrote:
I like the new param check, but I'd still prefer a new ioctl to
abusing
the old one.
It's not "abusing" it but extending the interface in a
backwards-compatible manner. Introducing a new one would result in two
ioctls that essentially do the same t
On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> I like the new param check, but I'd still prefer a new ioctl to abusing
> the old one.
>
It's not "abusing" it but extending the interface in a
backwards-compatible manner. Introducing a new one would result in two
ioctls that essentially do the sa
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two t
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "abusing" it but extending the interface in a
> backwards-compatible
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "abusing" it but extending the interface in a
> backwards-compatible
On Fri, 18 Mar 2011, Jesse Barnes wrote:
I like the new param check, but I'd still prefer a new ioctl to abusing
the old one.
It's not "abusing" it but extending the interface in a
backwards-compatible manner. Introducing a new one would result in two
ioctls that essentially do the same
On Fri, 18 Mar 2011 16:58:04 -0500 (CDT)
Ilija Hadzic wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
> the capability to wait on vblank events for CRTCs that are greater than 1
> and thus cannot be represented with primary/secondary flags in t
On Fri, 18 Mar 2011 16:58:04 -0500 (CDT)
Ilija Hadzic wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
> the capability to wait on vblank events for CRTCs that are greater than 1
> and thus cannot be represented with primary/secondary flags in t
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two
34 matches
Mail list logo
