Thread: [Linux-fbdev-devel] Vertical retrace interrupts?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Are there any plans on merging DirectFB features? Stuff like vertical
retrace interrupts etc.?

	Fredrik

> Are there any plans on merging DirectFB features? Stuff like vertical
> retrace interrupts etc.?

Thats already supported. Just add a poll function to fb_ops. To date no 
one has used this feature.

On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> 
> > Are there any plans on merging DirectFB features? Stuff like vertical
> > retrace interrupts etc.?
> 

I wholeheartedly agree with this.  There are a lot of applications out
there (especially video players) where vtrace signal delivery is
critical for optimum operation.  Polling for VGA registers is not
totally correct for newer cards and is too inefficient, so this has to
be done at a per driver level.

> Thats already supported. Just add a poll function to fb_ops. To date no 
> one has used this feature.
> 

It's because there is no .poll entry in the struct file_operations in
fbmem.c  Something like this:

static struct file_operations fb_fops = {
	.owner =	THIS_MODULE,
	.read =		fb_read,
	.write =	fb_write,
	.ioctl =	fb_ioctl,
	.mmap =		fb_mmap,
	.open =		fb_open,
	.release =	fb_release,
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
	.get_unmapped_area = get_fb_unmapped_area,
#endif
	.poll =         fb_poll,
};

static unsigned int fb_poll(struct file *file, poll_table *wait)
{
	if (info->fbops->fb_poll)
		return (info->fbops->fb_poll(file, wait));
	return -EINVAL;
}

Also, poll is blocking.  You might want to include an .fasync entry too
for asynchronous I/O.

Finally, is the poll function too generic? I'm not sure about this but
basically we can only wait for events like 'there is data to read, it's
now okay to write', etc.  Is this too ambiguous?   Is it okay to define
a private event flag?  Or do we just agree that fb_poll means wait for
vretrace?

I know that there's already an overuse of ioctls, but for something
specific and important as this, we might not have a choice.

Tony

BTW:  It's not too difficult to add generic vsync interrupt handlers for
most VGA cards via register CR11. 

On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > 
> > > Are there any plans on merging DirectFB features? Stuff like vertical
> > > retrace interrupts etc.?
> 
> I wholeheartedly agree with this.  There are a lot of applications out
> there (especially video players) where vtrace signal delivery is
> critical for optimum operation.  Polling for VGA registers is not
> totally correct for newer cards and is too inefficient, so this has to
> be done at a per driver level.

Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
generic ioctl which can block or send a signal on vertical blank
interrupts.

-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

On Thu, 2003-01-30 at 19:45, Michel D=E4nzer wrote:
> On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> > On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > >=20
> > > > Are there any plans on merging DirectFB features? Stuff like vertic=
al
> > > > retrace interrupts etc.?
> >=20
> > I wholeheartedly agree with this.  There are a lot of applications out
> > there (especially video players) where vtrace signal delivery is
> > critical for optimum operation.  Polling for VGA registers is not
> > totally correct for newer cards and is too inefficient, so this has to
> > be done at a per driver level.
>=20
> Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> generic ioctl which can block or send a signal on vertical blank
> interrupts.
>=20
>=20

Yes, I've seen the dri list archives, and adding support for this in
fbdev will result in code dupliation :-(.

However, at least 3 people have mailed me that they are using their
somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
X.  The image instability is noticeable because they are driving
big-screen TV's, especially because DirecFB is double-buffered, with
triple-buffering in the TODO list.  It's because of this that I have to
hack in vretrace signal delivary to i810fb.  There's also a similar
patch for matroxfb.

Tony

On Fre, 2003-01-31 at 00:22, Antonino Daplas wrote:
> On Thu, 2003-01-30 at 19:45, Michel Dänzer wrote:
> > On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> > > On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > > > 
> > > > > Are there any plans on merging DirectFB features? Stuff like vertical
> > > > > retrace interrupts etc.?
> > > 
> > > I wholeheartedly agree with this.  There are a lot of applications out
> > > there (especially video players) where vtrace signal delivery is
> > > critical for optimum operation.  Polling for VGA registers is not
> > > totally correct for newer cards and is too inefficient, so this has to
> > > be done at a per driver level.
> > 
> > Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> > generic ioctl which can block or send a signal on vertical blank
> > interrupts.
> 
> Yes, I've seen the dri list archives, and adding support for this in
> fbdev will result in code dupliation :-(.
> 
> However, at least 3 people have mailed me that they are using their
> somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> X.

You don't need X to use the DRM, just some privileged client to
initialize it.

-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

On Fri, Jan 31, 2003 at 12:24:33PM +0100, Michel Dänzer wrote:
> > Yes, I've seen the dri list archives, and adding support for this in
> > fbdev will result in code dupliation :-(.
> > 
> > However, at least 3 people have mailed me that they are using their
> > somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> > X.
> 
> You don't need X to use the DRM, just some privileged client to
> initialize it.

It feels a bit silly to to use drm just for vsync interrupts. Besides
there are a lot of cards that don't have a drm driver but do have an fbdev
driver. IMHO fbdev is the logical place for this stuff.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
>=20
> You don't need X to use the DRM, just some privileged client to
> initialize it.
>=20

You're right.  I just realized that since DRM already has an interrupt
handler, it is unwise for fbdev to install its own interrupt handler
too, as this will fatally lock up the machine when DRM and fbdev are
loaded simultaneously.

So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
drivers with a DRM counterpart, fbdev will just call the DRM
wait_vblank() and send_vbl_signals() functions.   Do you think this is
doable, I haven't examined the code thoroughly? =20

The main goal is too avoid having 2 independent interrupt handlers for
one device.

Tony=20
=20

On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> On Fri, 2003-01-31 at 19:24, Michel Dänzer wrote:
> > 
> > You don't need X to use the DRM, just some privileged client to
> > initialize it.
> 
> You're right.  I just realized that since DRM already has an interrupt
> handler, it is unwise for fbdev to install its own interrupt handler
> too, as this will fatally lock up the machine when DRM and fbdev are
> loaded simultaneously.
> 
> So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
> drivers with a DRM counterpart, fbdev will just call the DRM
> wait_vblank() and send_vbl_signals() functions.   Do you think this is
> doable, I haven't examined the code thoroughly?  
> 
> The main goal is too avoid having 2 independent interrupt handlers for
> one device.

A noble goal, but the framebuffer device would still need its own code
when the DRM isn't active, so I'm afraid there's no way around code
duplication, unless we could somehow factor out the common code for the
two to share?

-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

> Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> generic ioctl which can block or send a signal on vertical blank
> interrupts.

Nice :-)

Hi Antonino,

fre 2003-01-31 klockan 00.22 skrev Antonino Daplas:
> However, at least 3 people have mailed me that they are using their
> somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> X.  The image instability is noticeable because they are driving
> big-screen TV's, especially because DirecFB is double-buffered, with
> triple-buffering in the TODO list.

I don't think vertical retrace synchronisation is strictly necessary 
for excellent video playback on low-grade systems. Reason is that I
believe most graphics cards delay the flip automatically in hardware
using shadow registers which load the real registers during retrace.

The software only needs to flip the buffers with approximately the same
frequency, and it'll work fine.

I've sent a few patches to the Xine (video player) developers to improve
the frame buffer driver and player. The new driver allocates as many
buffers as possible natively in video RAM. Thus, with a 16 MB TNT card
you'll get about 9 buffers at 768x576x32 (PAL DVD) resolution. That
should give the driver plenty of margins to deal with occasional
scheduling problems etc. because the only essential thing it needs to
do meanwhile is flipping buffers using the FBIOPAN_DISPLAY ioctl. This
can be done with the regular Linux kernel frame buffer drivers.

I think Xine being threaded (as compared with mplayer which is not) is
an advantage when implementing this. It's still work-in-progress but I
hope the theory will work out when I have the ability to do more
advanced tests than I've done so far. :)

	Fredrik

On Fri, 2003-01-31 at 08:16, Fredrik Noring wrote:
> Hi Antonino,
> 
> fre 2003-01-31 klockan 00.22 skrev Antonino Daplas:
> > However, at least 3 people have mailed me that they are using their
> > somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> > X.  The image instability is noticeable because they are driving
> > big-screen TV's, especially because DirecFB is double-buffered, with
> > triple-buffering in the TODO list.
> 
> I don't think vertical retrace synchronisation is strictly necessary 
> for excellent video playback on low-grade systems. Reason is that I
> believe most graphics cards delay the flip automatically in hardware
> using shadow registers which load the real registers during retrace.

This is true if you have triple, or more, buffers -- (buffer currently
being displayed, buffer waiting to be displayed, and buffer being
decoded to) and if the display refresh rate is faster than the video
frame frate.  In this case, you can just simply rely on the hardware
doing the actual buffer flip during vblank since you are guaranteed that
the next frame will not arrive until at least one vertical retrace
later.

With double buffers, you still need to synchronize with the retrace
signal, otherwise the video decoder will write to the buffer currently
being displayed (because the actual flip was delayed by the hardware). 
Polling for the VGA registers will be enough in most cases, but will not
work correctly with some hardware.

> 
> The software only needs to flip the buffers with approximately the same
> frequency, and it'll work fine.

Right, the software will flip the buffers at the correct frequency.
However, decoding will occur immediately after returning from the flip
command.

> 
> I've sent a few patches to the Xine (video player) developers to improve
> the frame buffer driver and player. The new driver allocates as many
> buffers as possible natively in video RAM. Thus, with a 16 MB TNT card
> you'll get about 9 buffers at 768x576x32 (PAL DVD) resolution. That
> should give the driver plenty of margins to deal with occasional
> scheduling problems etc. because the only essential thing it needs to
> do meanwhile is flipping buffers using the FBIOPAN_DISPLAY ioctl. This
> can be done with the regular Linux kernel frame buffer drivers.

Ahh, you have a lot of buffers here, so vretrace synchronization is not
a problem.  I was referring to DirectFB which is only double-buffered. 

Tony

On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel D=E4nzer wrote:
> On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
> > >=20
> > > You don't need X to use the DRM, just some privileged client to
> > > initialize it.
> >=20
> > You're right.  I just realized that since DRM already has an interrup=
t
> > handler, it is unwise for fbdev to install its own interrupt handler
> > too, as this will fatally lock up the machine when DRM and fbdev are
> > loaded simultaneously.
> >=20
> > So, how about this?  Let fbdev have its own vblank ioctl, but for fbd=
ev
> > drivers with a DRM counterpart, fbdev will just call the DRM
> > wait_vblank() and send_vbl_signals() functions.   Do you think this i=
s
> > doable, I haven't examined the code thoroughly? =20
> >=20
> > The main goal is too avoid having 2 independent interrupt handlers fo=
r
> > one device.
>=20
> A noble goal, but the framebuffer device would still need its own code
> when the DRM isn't active, so I'm afraid there's no way around code
> duplication, unless we could somehow factor out the common code for the
> two to share?

Could it not be that the fbdev sort of minimally intialize the DRM when
it is not already active ? After all, the fbdev knows as much, if not
more, than the X driver about the graphic chips state, especially if the
X driver is using the fbdev.

Friendly,

Sven Luther

On Sat, 2003-02-01 at 05:32, Sven Luther wrote:
> On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel D=E4nzer wrote:
> > On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > > On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
> > > >=20
> > > > You don't need X to use the DRM, just some privileged client to
> > > > initialize it.
> > >=20
> > > You're right.  I just realized that since DRM already has an interrup=
t
> > > handler, it is unwise for fbdev to install its own interrupt handler
> > > too, as this will fatally lock up the machine when DRM and fbdev are
> > > loaded simultaneously.
> > >=20
> > > So, how about this?  Let fbdev have its own vblank ioctl, but for fbd=
ev
> > > drivers with a DRM counterpart, fbdev will just call the DRM
> > > wait_vblank() and send_vbl_signals() functions.   Do you think this i=
s
> > > doable, I haven't examined the code thoroughly? =20
> > >=20
> > > The main goal is too avoid having 2 independent interrupt handlers fo=
r
> > > one device.
> >=20
> > A noble goal, but the framebuffer device would still need its own code
> > when the DRM isn't active, so I'm afraid there's no way around code
> > duplication, unless we could somehow factor out the common code for the
> > two to share?

The fbdev driver will automatically load the DRM module when it refers
to any exportable symbol of DRM.  We can also make the fbdev drivers
specifically depend on DRM in Kconfig so users don't accidentally
compile fbdev without its DRM counterpart.

The aim is not to avoid code duplication, although that is a plus, it's
two independent handlers clashing and locking up the machine.

>=20
> Could it not be that the fbdev sort of minimally intialize the DRM when
> it is not already active ? After all, the fbdev knows as much, if not
> more, than the X driver about the graphic chips state, especially if the
> X driver is using the fbdev.
>=20

I was wondering about this to.  How much initialization is required?  Is
it not enough to just load the DRM module?

Also, we have fbdev drivers that are incompatible with DRM, so having
fbdev load DRM is like telling it to commit suicide :-)

Tony

On Sam, 2003-02-01 at 00:34, Antonino Daplas wrote: 
> On Sat, 2003-02-01 at 05:32, Sven Luther wrote:
> > On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel Dänzer wrote:
> > > On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > > > On Fri, 2003-01-31 at 19:24, Michel Dänzer wrote:
> > > > > 
> > > > > You don't need X to use the DRM, just some privileged client to
> > > > > initialize it.
> > > > 
> > > > You're right.  I just realized that since DRM already has an interrupt
> > > > handler, it is unwise for fbdev to install its own interrupt handler
> > > > too, as this will fatally lock up the machine when DRM and fbdev are
> > > > loaded simultaneously.
> > > > 
> > > > So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
> > > > drivers with a DRM counterpart, fbdev will just call the DRM
> > > > wait_vblank() and send_vbl_signals() functions.   Do you think this is
> > > > doable, I haven't examined the code thoroughly?  
> > > > 
> > > > The main goal is too avoid having 2 independent interrupt handlers for
> > > > one device.
> > > 
> > > A noble goal, but the framebuffer device would still need its own code
> > > when the DRM isn't active, so I'm afraid there's no way around code
> > > duplication, unless we could somehow factor out the common code for the
> > > two to share?
> 
> The fbdev driver will automatically load the DRM module when it refers
> to any exportable symbol of DRM.  We can also make the fbdev drivers
> specifically depend on DRM in Kconfig so users don't accidentally
> compile fbdev without its DRM counterpart.

I wonder if people will like having to build the DRM for a framebuffer
device... a solution where one component uses the other if it's there,
but works without it otherwise, might be better.

> The aim is not to avoid code duplication, although that is a plus, it's
> two independent handlers clashing and locking up the machine.

I'm not sure it would be that bad, but certainly suboptimal. :)

> > Could it not be that the fbdev sort of minimally intialize the DRM when
> > it is not already active ? After all, the fbdev knows as much, if not
> > more, than the X driver about the graphic chips state, especially if the
> > X driver is using the fbdev.
> 
> I was wondering about this to.  How much initialization is required?  Is
> it not enough to just load the DRM module?

No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
and I suspect more needs to be done before that.

> Also, we have fbdev drivers that are incompatible with DRM, so having
> fbdev load DRM is like telling it to commit suicide :-)

Out of curiosity, is that about i8xx?

-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

On Sat, 2003-02-01 at 23:45, Michel D=E4nzer wrote:
[snip]
> >=20
> > The fbdev driver will automatically load the DRM module when it refers
> > to any exportable symbol of DRM.  We can also make the fbdev drivers
> > specifically depend on DRM in Kconfig so users don't accidentally
> > compile fbdev without its DRM counterpart.
>=20
> I wonder if people will like having to build the DRM for a framebuffer
> device... a solution where one component uses the other if it's there,
> but works without it otherwise, might be better.
>=20
Yes, your suggestion is better.  I did browse the dri code, and my
feeling is drm is coded for userspace clients without any usable hooks
for clients residing in kernel space. I'm still wondering how to access
DRM services from kernel space. =20

> > The aim is not to avoid code duplication, although that is a plus, it's
> > two independent handlers clashing and locking up the machine.
>=20
> I'm not sure it would be that bad, but certainly suboptimal. :)
>=20

It will be bad.  The handler that gets loaded first will receive the
interrupt signal first.  It will, by necessity, clear the registers of
the event it's watching for to reenable the interrupt.  So when it's the
second handler's turn, and if it is also watching for the same event,
then it will falsely assume that the event never happened.  At worst,
the second handler will wait indefinitely for an event that will never
arrive, at best it will time out and send false information.

>=20
> > > Could it not be that the fbdev sort of minimally intialize the DRM wh=
en
> > > it is not already active ? After all, the fbdev knows as much, if not
> > > more, than the X driver about the graphic chips state, especially if =
the
> > > X driver is using the fbdev.
> >=20
> > I was wondering about this to.  How much initialization is required?  I=
s
> > it not enough to just load the DRM module?
>=20
> No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
> and I suspect more needs to be done before that.
>=20

Yes, I also realized that.  My feeling is if James or Geert do agree to
add support for this, fbdev will just have to duplicate the code, taking
care that another handler may exist, or DRM will be rewritten so the
interrupt handling can be shared or made available to other modules, as
you suggested.

> > Also, we have fbdev drivers that are incompatible with DRM, so having
> > fbdev load DRM is like telling it to commit suicide :-)
>=20
> Out of curiosity, is that about i8xx?
>=20

No, the i810fb driver is compatible with X and DRM. =20

Tony

> > I wonder if people will like having to build the DRM for a framebuffer
> > device... a solution where one component uses the other if it's there,
> > but works without it otherwise, might be better.
> > 
> Yes, your suggestion is better.  I did browse the dri code, and my
> feeling is drm is coded for userspace clients without any usable hooks
> for clients residing in kernel space. I'm still wondering how to access
> DRM services from kernel space.  

I have to agree. For most platforms fbdev is a needed. You could view DRM 
as a power extenstion to fbdev. Well that is how I view it. If we have DRM 
enabled we can enable more features in fbdev.

Thread: [Linux-fbdev-devel] Vertical retrace interrupts?

linux-fbdev-devel