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

[Antonino D. <ad...@po...>]

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.