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
ihad...@research.bell-labs.com wrote:
Hi Dave,
Below is a patch against
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
On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> The duplicated code in each function is begging to get pulled out into
> a separate function...
>
How about this then ?
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9
Hi Alex,
Below is a patch against the master branch of xf86-video-ati that adds
support for waits on vblank events on CRTCs that are greater than 1 (and
thus cannot be represented using current primary/secondary flags
interface). The patch makes use of GET_CAP ioctl to check whether
vblanks
Hi Alex,
Below is a patch against the master branch of libdrm that adds support
for waits for vblank events on CRTCs that are greater than 1 (and thus
cannot be represented using current primary/secondary flags interface).
The patch adds a new DRM_CAP so that the application can check whether
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
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
Hi Alex,
Below is a patch against the master branch of libdrm that adds support
for waits for vblank events on CRTCs that are greater than 1 (and thus
cannot be represented using current primary/secondary flags interface).
The patch adds a new DRM_CAP so that the application can check
Hi Alex,
Below is a patch against the master branch of xf86-video-ati that adds
support for waits on vblank events on CRTCs that are greater than 1 (and
thus cannot be represented using current primary/secondary flags
interface). The patch makes use of GET_CAP ioctl to check whether
vblanks
On Fri, 18 Mar 2011, Jesse Barnes wrote:
The duplicated code in each function is begging to get pulled out into
a separate function...
How about this then ?
diff --git a/src/radeon.h b/src/radeon.h
index a6d20d7..1a746c7 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -931,6 +931,9 @@
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 Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
> No, userspace shouldn't call the ioctl for a disabled CRTC during normal
> operation, that would be a bug of its own.
Well, that's exactly what DDX is doing today. Try this experiment: open a
terminal window and run glxgears in it and
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>
> I'm afraid I don't really like this. Apart from the ugly bogus error
> message, the probes could fail for other reasons, e.g. at some point we
> might want to return an error when the ioctl is called for a CRTC which
> is currently
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
I'm afraid I don't really like this. Apart from the ugly bogus error
message, the probes could fail for other reasons, e.g. at some point we
might want to return an error when the ioctl is called for a CRTC which
is currently disabled,
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
No, userspace shouldn't call the ioctl for a disabled CRTC during normal
operation, that would be a bug of its own.
Well, that's exactly what DDX is doing today. Try this experiment: open a
terminal window and run glxgears in it and
oops, just realized that I didn't include one final change to the patch I
have just sent, so here is the real one; disregard the previous one (sorry
wasting bandwidth).
xf86-video-ati.patch --
diff --git a/src/radeon.h b/src/radeon.h
index
Below is an updated patch for ATI DDX (xf86-video-ati library) that
reflects the discussion of this thread. The patch is *cumulative*
(i.e., it includes the changes from a few days ago, so it should
be applied to plain-vanilla DDX, not the one you may have patched
with my patch from last week). I
Below is an updated patch for ATI DDX (xf86-video-ati library) that
reflects the discussion of this thread. The patch is *cumulative*
(i.e., it includes the changes from a few days ago, so it should
be applied to plain-vanilla DDX, not the one you may have patched
with my patch from last week).
oops, just realized that I didn't include one final change to the patch I
have just sent, so here is the real one; disregard the previous one (sorry
wasting bandwidth).
xf86-video-ati.patch --
diff --git a/src/radeon.h b/src/radeon.h
index
(this is a cumulative response to all comments that came in on this
thread).
My opinion is that extending the existing ioctl is better than introducing
the new one given that they will be doing the same thing. Also there are
fewer kernel changes so it's safer (it opens fewer opportunities to
(this is a cumulative response to all comments that came in on this
thread).
My opinion is that extending the existing ioctl is better than introducing
the new one given that they will be doing the same thing. Also there are
fewer kernel changes so it's safer (it opens fewer opportunities
I would like to propose an extension of the interface between the
libdrm and drm kernel module for VBLANK wait to address a problem that
I am seeing on screens with more than two displays. Below, I describe the
problem, propose a (backwards compatible) solution and provide a set
of patches that
I would like to propose an extension of the interface between the
libdrm and drm kernel module for VBLANK wait to address a problem that
I am seeing on screens with more than two displays. Below, I describe the
problem, propose a (backwards compatible) solution and provide a set
of patches
401 - 423 of 423 matches
Mail list logo
