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
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? :)
Michel Dänzer ([EMAIL PROTECTED]):
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
Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote:
Oh, and are there any opinions about the signal to use, SIGALRM or
something else?
You'll have to make it settable -- SIGALRM is already used by the X server
for scheduling. Of course, we could eliminate that if I could get
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
On Sun, 2002-11-03 at 22:46, Elladan wrote:
could be wrong about that, but I think you'd need rtlinux style
extensions to the kernel to achieve direct interrupt deliveries to
user-space (and you'd need to be root, and such).
You cannot deliver interrupts directly to user space without
