Status of WAITFORVSYNC (waitretrace)

DISCUSSION jfj 2 participants 3 messages Sep 24, 2006 – Sep 25, 2006 Framebuffer layer

lore

Share & tools

lore

jfj

author

2006-09-24 10:52 UTC #0 lore raw

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

Torgeir Veimo

2006-09-24 11:57 UTC #1 lore raw

Quoted 3 lines · jfj

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.

Signature · 11 lines

Torgeir Veimo
[email protected]




-------------------------------------------------------------------------
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

jfj

author

2006-09-25 13:22 UTC #2 lore raw

Quoted 10 lines · Torgeir Veimo

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()).