On Sun, 2002-11-24 at 17:42, Michel Dänzer wrote: > On Mit, 2002-11-06 at 18:04, Keith Packard wrote: > > Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > > > Okay, is there anything wrong with turning the struct for the ioctl into > > > a union of a request and a reply struct? :) > > > > That is the usual way, I believe... Or, you can just build a larger > > struct containing both pieces. > > > > > Yes. The blocking ioctl also returns a timestamp, is that important for > > > the signal? > > > > Might be nice; there's plenty of space. Is it expensive to compute? > > > > > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > > > would it have to generate signals indefinitely? > > > > Might want a mode that chose between these two options, but if I had to > > pick one, I'd ask for a single signal. That's what SYNC wants. > > http://penguinppc.org/~daenzer/DRI/radeon-vbl-signal.diff > > is an attempt at this, unfortunately not successful - it locks up solid > when I request a signal to be delivered. Now I'd very much like to get > this into 4.3.0, so I'd appreciate someone pointing out the stupid > mistake(s) I'm probably making. :)
Thoughts on it so far: Is it legal to hijack the si_code field for this use? Where would the timestamp go that was talked about? Also, shouldn't you be using list_add/list_del for those list things done? -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
