Date: Sun, 23 Mar 1997 21:01:52 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Steve Passe <smp@csn.net> Cc: Amancio Hasty <hasty@rah.star-gate.com>, multimedia@freebsd.org Subject: Re: Changes for Audio control on the bt848 code Message-ID: <19970323210152.33663@ct.picker.com> In-Reply-To: <199703211908.MAA23449@Ilsa.StevesCafe.com>; from Steve Passe on Fri, Mar 21, 1997 at 12:08:57PM -0700 References: <199703211842.KAA00387@rah.star-gate.com> <199703211908.MAA23449@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe: |definately. I just added Randall's Notify Event code to cause xtvremote |to track changes to controls made by fxtv. Works fine, but I think it should |be taken a step further. I don't know how this is traditionally done in |X, so I will describe it generically. | |CONTROL_CLIENT: any program wanting to cooperate in the use of the | picture control ioctl()s. | |each CONTROL_CLIENT registers itself with the kernel via an ioctl() | |whenever any of the picture control values change via ioctl()s each |registered CONTROL_CLIENT is sent a signal by the kernel (say SIG_USR1). | |each CONTROL_CLIENT responds to the signal by updateing its local values. | |comments? (Just now sitting down to catch up on my filtered list mail folders...) I think some sort of async driver notification of value changes to driver clients would be nice, but using signals is problematic with X as it isn't reentrant. To process a signal safely, you end up just setting a global that's checked when you get back to the main event loop anyway, so other approaches would work as well. The capture process also imposes a reasonable interrupt load on the system that we probably don't want to stress by kicking off signals to N clients 30 times a second when, for example, the user slides a value scrollbar for Hue around. Since we already have a file descriptor open for read to the capture device (and now also the tuner device), what about having the driver write out value changes to the open driver file descriptor. X clients can just XtAppAddInput on the driver file descriptors, and when they swing around into the main event loop next, their AddInput callbacks will fire and they can slurp off all the queued value changes since they slurped last and update accordingly. Since we're not in a signal handler, it's safe to use X calls. And since all queued updates can be slurped off at once, we can compress the GUI updates required down very easily (e.g. if hue has updated 30 times since we last swung through the loop, just do one GUI update for the last one). Also since each client has its own file pointer, they can all slurp updates at their own rate (input style like pipes and sockets, with no random access in the stream allowed). What do you think? Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970323210152.33663>