Jeff, Others,
I've been reviewing the work in the 3.5 branch for backwards compatibility
and to me it looks like we can do it with a lot less effort. Here's what I'm
proposing, in one simple sentence:
Instigate a rule where any released ioctl will always be supported, with the
same
* Keith Whitwell [EMAIL PROTECTED] on Sat, Oct 13, 2001:
Instigate a rule where any released ioctl will always be supported, with the
same semantics and interface.
[...]
Secondly, it means no ioctls are ever removed or renamed. This was Linus'
big concern and he was
Actually 2.5 will see a lot of devices moving away from IOCTLs (even legacy
ones) as Linux gains namespace support. From the Linus threads I've read,
even older IOCTLs will be shot down. The unmaintainability and randomness
of IOCTL numbering schemes is one of the things that brought this
Well, it is late Saturday here. I know everyone is busy, but can at least
someone confirm that they know the answer but just don't have time for it ?
I'd hate to lose a weekend waiting for something that's not going to
come..
Vladimir Dergachev
--
-- Forwarded Message --
Subject: Re: [Dri-devel] Using drm (fwd)
Date: Sat, 13 Oct 2001 16:42:59 -0600
From: Keith Whitwell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
That's what I am trying to do. With not much luck so far. The reason (at
least to me) is that the 3d driver
On Sat, 13 Oct 2001, Keith Whitwell wrote:
That's what I am trying to do. With not much luck so far. The reason (at
least to me) is that the 3d driver is the interaction of 3 parts: kernel
drm module, XFree driver (like radeon_dri.c) and the dri part (whatever
goes into
On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
On Sat, 13 Oct 2001, Keith Whitwell wrote:
That's what I am trying to do. With not much luck so far. The reason
(at least to me) is that the 3d driver is the interaction of 3 parts:
kernel drm module, XFree driver (like radeon_dri.c)
On Sat, 13 Oct 2001, Keith Whitwell wrote:
On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
On Sat, 13 Oct 2001, Keith Whitwell wrote:
That's what I am trying to do. With not much luck so far. The reason
(at least to me) is that the 3d driver is the interaction of 3 parts:
well back to our cows...
I get frames from bt848 at 25 fps - F_CIF (710x576 YUV420 i.e. 12 bits) -0%
cpu usage if I just discard them.
since I get them in mmap'ed driver area and not shared memory, I use single
memcpy to copy them to one previously allocated shared memory - 25% CPU
time.
Now
On Sat, Oct 13, 2001 at 11:16:51PM +0200, Michael Zayats wrote:
well back to our cows...
hi
putting DMA might save about 25%...
A very reasonable assumption.
another 2 questions:
1) may be I should just use some optimized version of memcpy? someone knows
of MMX or SSI uses in glibc? I have
10 matches
Mail list logo
