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 st
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 c
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 proces
You are sort-of correct. Mark and I actually had some discussions about
making a more expanded version of it or another API that was more
generic.
In the implementation for i810 You can allocate XvMC surfaces and then,
if you know where to look. You can access the surfaces directly as
they are map
On 6 Nov 2002, Michel Dänzer wrote:
> On Mit, 2002-11-06 at 17:39, Billy Biggs wrote:
> > 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 deskto
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
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 loo
Xavier Bestel <[EMAIL PROTECTED]> writes:
> Le dim 03/11/2002 à 18:47, Keith Packard a écrit :
> > 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
Le dim 03/11/2002 à 18:47, Keith Packard a écrit :
> 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
> f
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
Hi,
I thought I'd chime in on this because we've discussed the issues
within the GGI/KGI group a lot. Our conclusions were as follows:
A) Relying on any type of signal/process wakeup from the kernel
introduces unwanted latency.
B) Not using a signal results in not being able to guarantee th
11 matches
Mail list logo
