Re: Status of WAITFORVSYNC (waitretrace)

[jfj <jfj@freemail.gr>]

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