On Tue, Jun 28, 2011 at 8:28 PM, Martin Kielhorn <[email protected]> wrote: > 2011/6/28 Martin Kielhorn <[email protected]>: >> 2011/6/28 Martin Kielhorn <[email protected]>: >>> Hi list, >>> is it possible to synchronise the drawing process to the vsync cycle of the >>> graphics >>> card from user level? >> >> I found a 2005 patch from Peter Chubb that would create >> /proc/irq/<nnn>/irq that would block until an irq is received. >> > > Peter Chubb also suggests the UIO framework: > [...] > There are basically two ways. You can use something like my patch, or > you can write a driver that tells userspace when the interrupt > happens. There is an in-kernel framework for user-level PCI device drivers: > take a look at drivers/uio in the kernel source. There appears to be > no documentation. > [...]
Yeah, perhaps the most general way to do it would be to give the driver and ioctl call or a read call that would block until the interrupt signal arrives. Or maybe we could have the kernel send requesting processes a signal (like SIGUSR or SIGALARM or whatever). In my experience, the blocking call works best, since we can make the user process wake IMMEDIATELY (as in real-time) when the interrupt arrives, rather than just adding the process back to the run queue. At least that's how we were able to do it with Solaris. > > Regards, Martin > -- > Martin Kielhorn > Randall Division of Cell & Molecular Biophysics > King's College London, New Hunt's House > Guy's Campus, London SE1 1UL, U.K. > tel: +44 (0) 207 848 6519, fax: +44 (0) 207 848 6435 > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
