On Don, 2011-03-10 at 07:32 -0600, Ilija Hadzic wrote:
>
> On Thu, 10 Mar 2011, Michel [ISO-8859-1] Dnzer 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 erro
On Mit, 2011-03-09 at 11:33 -0600, Ilija Hadzic wrote:
>
> So what I did is to actually probe the kernel at screen init time.
> When the screen is initialized, the DDX checks if the GPU has more than
> two CRTCs and tries a dummy vblank wait on all crtcs > 1. If any
> of them fails, it falls bac
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 ob
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 obs
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 disab
On Don, 2011-03-10 at 07:32 -0600, Ilija Hadzic wrote:
>
> On Thu, 10 Mar 2011, Michel [ISO-8859-1] Dnzer 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 erro
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, to
On Mit, 2011-03-09 at 11:33 -0600, Ilija Hadzic wrote:
>
> So what I did is to actually probe the kernel at screen init time.
> When the screen is initialized, the DDX checks if the GPU has more than
> two CRTCs and tries a dummy vblank wait on all crtcs > 1. If any
> of them fails, it falls bac
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 4c43
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
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 4c
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
On Fre, 2011-03-04 at 19:27 -0600, Ilija Hadzic wrote:
>
> That will take care of ATI DDX and general support in DRM; I presume
> that someone will follow up on other DDXs (I only deal with Radeon
> GPUs at the moment, so I am not familiar with other DDXs).
Are there any other GPUs with more tha
On Fre, 2011-03-04 at 19:27 -0600, Ilija Hadzic wrote:
>
> That will take care of ATI DDX and general support in DRM; I presume
> that someone will follow up on other DDXs (I only deal with Radeon
> GPUs at the moment, so I am not familiar with other DDXs).
Are there any other GPUs with more tha
(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 s
(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
On Don, 2011-03-03 at 17:34 -0600, Ilija Hadzic wrote:
>
> Now the problem is that DRM_IOCTL_WAIT_VBLANK only understands primary
> and secondary crtc and everything that is not crtc-0 is considered
> secondary. Then in the kernel, drm module maps the secondary flag to
> crtc 1, but that is a di
On Don, 2011-03-03 at 17:34 -0600, Ilija Hadzic wrote:
>
> Now the problem is that DRM_IOCTL_WAIT_VBLANK only understands primary
> and secondary crtc and everything that is not crtc-0 is considered
> secondary. Then in the kernel, drm module maps the secondary flag to
> crtc 1, but that is a di
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
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
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
22 matches
Mail list logo
