On Wed, Nov 06, 2002 at 04:54:15PM +0100, Michel D?nzer wrote: > On Son, 2002-11-03 at 23:46, Elladan wrote: > > On Sun, Nov 03, 2002 at 03:00:53PM +0100, Michel D?nzer wrote: > > > On Son, 2002-11-03 at 06:17, Elladan wrote: > > > > > > > > It might be best to provide both interfaces. It's probably not > > > > significantly harder to provide both API's - they both trigger off the > > > > same hardware event. > > > > > > Yes, I'm looking into adding a flag to the ioctl so it sends a signal > > > instead of blocking. Shouln't be too hard, but I haven't found out yet > > > whether a signal can be delivered from an interrupt top half, if anyone > > > knows I'd appreciate letting me know before I find out the hard way. :) > > [...] > > > And no, I don't think a signal can possibly be delivered in the top > > half, by the way. It's going to get delayed by the userspace transition > > just as much as a blocking system call would (probably more), so mostly > > I think it's just a tool for single-threaded apps to handle vblanks. I > > Yeah, I didn't mean that but simply whether a top half can call something > like deliver_signal() and then the signal gets delivered the next time the > process is scheduled. But maybe it's better to use a bottom half anyway.
Um, well, yeah. The bottom half is going to get run before the kernel returns to userspace. :-) > I think most of the other points you raise would probably better be handled > by driver specific extensions but are most definitely beyond the scope of > what we're trying to achieve here. Well, perhaps. Being able to latch a buffer swap onto the interrupt is a more useful kernel API issue, since if it's possible, you want your apps to be able to use it. For the reasons I mentioned previously, just being able to block on the vblank will only really be sufficient for suid root apps. > > It would be preferable in general for video apps, though, to provide a > > DRM-based api to use the overlay buffer, too. Like, a DRM-Xv. For > > desktop use, the X11 context switch may be fairly acceptable with > > something like XSYNC, but to achieve really excellent quality (eg, > > suitable for output to a TV/broadcast/etc.) in, say, a video player, a > > direct API would be nicer. > > If I'm not mistaken that's what XvMC is for. It doesn't appear to be. Providing such a thing, as well as some sort of way for a user app to synchronize on the vblank usefully without special privileges, would allow for much better video quality than Linux generally provides currently (except through some special driver-specific hacks, of course). -J ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
