Status of WAITFORVSYNC (waitretrace)

Status of WAITFORVSYNC (waitretrace)

[jfj]

Hi.

I have kernel 2.6.17
It seems that the matrox card implements FBIO_WAITFORVSYNC ioctl.

Also, in the archives of the list I saw that there have been
patches that implement WAITFORVSYNC for radeonfb, intelfb and
omapfb.  And for the SiS card there is a static inline
waitforretrace() function that uses the polling+watchdog
method, as well as a sisfb_accelsync() [but I don't know if
.fb_sync is the same as WAITFORVSYNC].

So, um, what's the status of the ioctl()?
Are they in 2.6.18?

It would be really useful to have this for DirectFB (which
currently tries to get iolp() and do the polling method)
*and* SDL (which calls the ioctl if FBIOWAITRETRACE is
defined, based on a patch Sam sent implementing FBIOWAITRETRACE).
Then DirectFB and SDL would be able to run on framebuffer
consoles nicely, without root privs (actually hyperuser privs
which is root+DMA)

Thanks,

jerald


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Status of WAITFORVSYNC (waitretrace)

[Torgeir Veimo]

On 24 Sep 2006, at 10:53, jfj wrote:

>
> I have kernel 2.6.17
> It seems that the matrox card implements FBIO_WAITFORVSYNC ioctl.

My patch for radeonfb was turned down since using that ioctl might  
freeze kernel if the drm kernel module is active and is using the  
same interrupt. I think an alternative option would be to disable it  
by default unless a kernel module param is set when loading radeonfb,  
since it's currently a bit difficult to get inter module  
communication between the drm and radeonfb modules. I never got  
around to resubmit a modified patch though.


-- 
Torgeir Veimo
torgeir@pobox.com




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Status of WAITFORVSYNC (waitretrace)

[jfj]

Torgeir Veimo wrote:

>My patch for radeonfb was turned down since using that ioctl might  
>freeze kernel if the drm kernel module is active and is using the  
>same interrupt. I think an alternative option would be to disable it  
>by default unless a kernel module param is set when loading radeonfb,  
>since it's currently a bit difficult to get inter module  
>communication between the drm and radeonfb modules. I never got  
>around to resubmit a modified patch though.
>
>  
>

Wow. What a mess.  If two different subsystems (fb and drm) implement
access to the same hardware, serious problems like this can happen
(at least if one is using X and fb programs at the same time), as
well as duplicate work, increasing size of the kernel, maintenance
troubles, etc.

The right way to solve this, would be a common sub-subsystem which
should be shared between drm and fb, but that's very hairy and
nobody is going to do it.

It's a pity though because WAITFORVSYNC is an important function
to do nice stuff with the framebuffer, there is interest from people
to implement this for the various cards, there is interest from the
userspace to use it, it adds very little code to the kernel and it
improves the overall functionallity of the framebuffer system :(

(and even the polling & watchdog method would be acceptable, because
that's what people do in the end from userland, with iopl() and inb()).

jf


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV