> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really
> They want the benefits of lots of testers, without wanting to be
> courteous to those testers.
Except for the small rather important detail that the Nouveau developers
didn't ask for it to be merged in the first place.
---
> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The
> guy who is, as far as I know, effectively in charge of that whole
> integration. Yeah, I realize that there are other people (Kyle?) involved,
> and maybe Dave isn't as central as I think he is, but I learnt from last
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact
> that the thing was done in such a way that it's basically impossible to
> support the old/new ABI at all!
What did you expect them to do. They said when you first forced a merge
that they would do this. They have no c
On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
David Miller wrote:
> From: Daniel Stone
> Date: Fri, 5 Mar 2010 18:04:34 +0200
>
> > So you're saying that there's no way to develop any reasonable body of
> > code for the Linux kernel without committing to keeping your ABI
> > absolutely rock-solid st
> So the watershed moment was _never_ the "Linus merged it". The watershed
> moment was always "Fedora started shipping it". That's when the problems
> with a standard upstream kernel started.
>
> Why is that so hard for people to understand?
So why are you screaming at the DRM and Nouveau peop
On Fri, 5 Mar 2010 16:56:10 +0100
Luca Barbieri wrote:
> It seems to me that Linus' technical argument is indeed being mostly ignored.
>
> While breaking the ABI is unfortunate, the real problem that Linus
> complained about is that you can't install several userspace versions
> side-by-side.
I
On Fri, 05 Mar 2010 07:49:32 -0800 (PST)
David Miller wrote:
> From: Daniel Stone
> Date: Fri, 5 Mar 2010 17:41:43 +0200
>
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
>
> You have
> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."
Not to belabour the obvious - they didn't. Linus ordered them to merge it.
> We're better than that.
If you consider
> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable." Because that's complete garbage
Staging has to have the no API rules. Read some of the stuff in there to
understand why or apply about 30 seconds of thought to what it would mean
to you.
Th
> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone. And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.
>
> It's about the tester base, and this breakage shrinks the tester base
> co
> Why does the X community not understand simple library versioning?
Why does Linus Torvalds not understand the Kconfig of his own staging
directory ?
Alan
--
Download Intel® Parallel Studio Eval
Try the new software too
On Thu, 04 Mar 2010 14:32:02 -0500
Jeff Garzik wrote:
> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > "Please note that these drivers are under heavy development, may or may
> > not work, and may contain userspace interfaces that most likely will be
> > changed in the near future."
>
> Ship
> So man up, guys. Face the problem, rather than say "well, it's staging",
> or "well, we can revert it". Neither of those really solve anything in the
> short run _or_ the long run.
Linus stop and think for a minute instead. Maybe a timeline would help
Nouveau development star
> The conclusion is crystal clear, breaking an ABI via a "flag day"
> cleanup/feature/etc is:
Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
junk that is in there being cleaned up it would be *insane* to keep their
old APIs
See there's a bigger offence than breaking an
> Obviously I'd like to clean it up, though.
>
> So, what device should handle this in your opinion?
My guess would be the relevant device driver for the hardware layer
So fbcon would probably not switch because it can put video modes back,
KMS obvious likewise. The text console might do somethi
> > But in that case we should be able to disable the VT switch disable
> > path; we just have to check each driver as it's loaded.
>
> OK, what the right sequence of checks would be in that case and where to place
> them?
Why are we even driving a vt switch direct from the suspend/resume
logic ?
> This probably belongs in the core DRM KMS code instead of the driver.
> I can imagine that there may be some X driver code that still needs to
> be executed on suspend/resume for some drivers, so this may introduce
> bugs, but it's definitely the right way to go.
You can have a mix of KMS and no
> I've been testing this patch for over a week and haven't seen a single problem
> related to it during this time.
>
> Are there any objections to it?
Usual question 8) - explain the locking. What happens if we suspend as
kms is initialising/being removed.
Also what happens if you have KMS and n
On Fri, 15 Jan 2010 12:40:30 + (GMT)
James Simmons wrote:
>
> > > Yeap. I can have patch ready for you this weekend. I lack the hardware to
> > > test it tho. Never been able to find a intel pci card that is not built
> > > into the motherboard.
> >
> > They don't exist, other than the old
On Fri, 11 Dec 2009 07:45:41 -0500
ty...@mit.edu wrote:
> On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote:
> >
> > Well the main thing was I wasn't mean to discuss possible legal issues
> > and still don't have permission, you know as well as I do once lawyers are
> > involved you hav
> I realize that you have some emotional attachments to Red Hat, but ask
> yourself (and answer honestly): what would you think if some random other
> distro was packaging tens of thousands of lines of kernel code and not
> apparently working at trying to get them upstream?
Like Ubuntu does for
> But not only is Fedora not following the rules,
You changed the rules. You require a Signed-off-by:. Fedora can no more
add a signed off by than you can. It's not their code nor Red Hat's code
any more than they "own" the kernel because they pay someone to work on
it.
> See above. It's not you
> The big question is what we call ctxprogs: binary blobs that are
> clearly executable, running somewhere in the GPU. No-one seems
> to know, if those are copyrightable, or if they can be redistributed.
> In their current form, they have been recorded from the nvidia
> proprietary driver using mmi
> The fact is, if there are license questions, then Fedora had better not be
> distributing the code either. And they clearly are.
Their choice, but it's not their project - they are just chosing to
import it.
> I've heard the "but it's hard to merge" excuse too - which I also know is
> bullshi
> Last time they were asked that, they wanted to be free of changing their
> kernel/userspace interface before upstreaming.
So put it in staging with a note to that effect. That'll also get it more
exposure and review.
Alan
> I think "tightly integrated" could do with some clarification here.
> qcserial was accepted despite not being functional without a closed
> userspace component - an open one's since been rewritten to allow it to
It got as far as staging with a good deal of complaint. I am not sure it
would ha
> Greg still claims that qcserial could be used by rebooting from Windows,
> right? In that it would still be extremly borderline to me, but it's
qcserial has a firmware loader app nowdays (someone wrote one in April)
http://www.codon.org.uk/~mjg59/gobi_loader/
indeed Matthew wrote it 8)
-
> If the common agreement of the linux community is to *NOT* allow these
> drivers in, so be it, then be honest and go ahead and tell the driver
> writers. Don't make them respin their development trying to fix minor
> flaws when their driver won't get in anyway!
The existing policy based on wh
> * fully functional GPL user-space driver.
>
> How can you argue that something as tailor made as a DRM interface can
> be used without it being a derived work?
Our prior policy has been to reject such stuff (both the Intel wireless
driver regulatory daemon and the GMX driver)
--
> > By the same logic, would you support including the proprietary NVIDIA
> > driver while we wait for Nouveau to catch up?
>
> The license of the NVIDIA driver does not allow that to even be a
> possibility.
I'm not convinced this is any different. If you accept the 3D changes you
step into a da
> The non-existence of an open-source 3D implementation doesn't really
> alter that situation.
I think it does to an extent
>
> However, if there's a policy issue about adding Linux kernel support for
> closed-source user-space drivers, I think it helps to be explicit about
> that.
Actually i
On Thu, 29 May 2008 11:05:08 +0200
"Alexander van Heukelum" <[EMAIL PROTECTED]> wrote:
> On Thu, 29 May 2008 10:46:22 +1000, "Dave Airlie" <[EMAIL PROTECTED]>
> said:
> > Hi,
> >
> > So I've been growing more annoyed with the current layout of the drm
> > tree in the kernel,
> >
> > a) it lives
This is a fairly simple change but affects all the drivers. The actual
lock is pushed down rather than eliminated. Hopefully it will then get
pushed down further. More importantly it helps us get rid of the old BKL
locked ioctl
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff --git a/d
> Interrupt handler - userspace plays with the irq lines, I think we could
> have issues getting interrupts when we have no master.
Undoubtedly - PCI interrupts are asynchronous to the other busses and can
turn up suprisingly late. It ought to be sufficient to clear the IRQ
cause kernel side and
> At a minimum, there must be a program to determine which outputs have
> monitors
> attached, and what modes are available on those monitors. It's possible this
> could be hardcoded in simple or embedded cases, but for a dynamic system it
> should probably be done in userspace, since EDID ove
> allocate pixmap gets cached memory
> copy data into the pixmap
> pre-use from hardware we flush the cache lines and tlb
> use the pixmap in hardware
> pre-free we need to set the page back to cached so we flush the tlb
> free the memory.
> Now the big issue here on SMP is that the cache and/or t
On Mon, 13 Aug 2007 00:05:30 -0400
"Scott Thompson" <[EMAIL PROTECTED]> wrote:
> patchset against 2.6.23-rc2 and this set is an audit of
> /drivers/char/a*
> through drivers/char .
>
> this corrects missing ioremap return checks and balancing on
> iounmap calls..
Your mail client has wrapp
Ar Mer, 2006-08-23 am 15:24 +0200, ysgrifennodd Gerhard Pircher:
> BTW: Can anybody explain the format of the graphics address remapping table
> or point me to some docs where it is described?
Its usually described and defined in the chip documentation. Generally
speaking it is a simple linear ar
On Maw, 2006-01-31 at 10:24 +0100, Philipp Klaus Krause wrote:
> The SiS 530 is fully documented, but it's a bit outdated and AFAIK
> there's no 3D driver for it yet.
> AFAIK The Vodoo cards are fully documented and the driver is so bad it
> could need a rewrite.
The Voodoo 3 and higher need a lot
On Iau, 2005-12-08 at 19:52 +0800, Austin Yuan wrote:
> buffer. Because the interface of "alloc_by_type" only receives a
> simple parameter "type", here I hide the user space address into
> "type" and re-get it in alloc_userspace_memory.
That should probably be fixed by extending the API to pass b
On Gwe, 2005-11-25 at 14:23 -0500, Lee Revell wrote:
> On Fri, 2005-11-25 at 20:13 +0100, Arjan van de Ven wrote:
> > of course sometimes having less but more coarse locks is actually
> > faster. Taking/dropping a lock is not free. far from it.
>
> True but couldn't it be a problem for devices li
On Iau, 2005-11-24 at 05:49 -0500, Lee Revell wrote:
> BTW can you point me to a good explanation of DRM locking? There's so
> much indirection in the DRM code I can't even tell whether there's one
> DRM lock or several, what kind of lock it is or what it's protecting
> (beyond "access to the hard
On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote:
> On Wednesday 23 November 2005 07:48, Michael Frank wrote:
> > Testing 2.6.15-rc2 in-kernel DRM, why still no mach64
> > support which works fine for me from snapshots/cvs?
>
> Because it's still insecure.
Michael - If you've got a Mach64 a
On Iau, 2005-09-29 at 22:02 +0200, Christoph Hellwig wrote:
> And replacing system libraries is not something we can allow anyone.
> It's totally reasonable to have different 3cards in the same systems
> and they're supposed to work.
Agreed - but the LSB job is still that of defining an ABI. Obvi
On Iau, 2005-09-29 at 09:49 +0200, Christoph Hellwig wrote:
> On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote:
> > Some of the topics raised include:
> >
> > - minimum OpenGL version required by libGL
> > - SONAME change to libGL
> > - libGL installation path
>
> I think t
On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote:
> Do we need to restrict the size of the maps we allow the DRI clients to
> acess in the FB area?
Yes - SiS has a 64K command queue in the frame buffer for example
---
SF.Net email is spons
On Sul, 2005-09-25 at 15:06 +0200, Thomas Hellstrom wrote:
> *VIA docs are rumored to require the (src_addr%4 == dest_addr%4) for all
> lines, and this is what is implemented as a sanity check. However,
> apparently there is a bug in the chip that also requires (system_addr&15
> == 0) for all li
On Gwe, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote:
> drivers) also setup an mtrr which frequently stops subsequent processes
> from adding a new one that overlaps an existing write-combining range.
It expects the other users to have the brains to add non-overlapping
ones 8)
> But the *fb dr
On Maw, 2005-09-13 at 12:24 +1000, Tim Long wrote:
> I have tracked down the orignal paper on the subject online at:
> http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/The%
> 20Graphics%20Pipeline/Virtual%20Graphics.pdf
SGI were doing it before that paper, years before. I think Mark
Kil
On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote:
> > 2. 1MB of the card memory is allocated for the front buffer and pinned.
> > 3. Process A allocates (and commits) a 7MB region for a big texture.
> > 4. Process B allocates (and commits) a 2MB region for a texture. To do
> > this, it kick out
On Maw, 2005-08-23 at 14:48 -0700, Keith Packard wrote:
> I'm starting to look at multi-user environments where each user has an X
> server which isn't in control of the whole screen, but rather just
> paints X windows into off-screen memory where an external trusted
> application can take those ap
> The framebuffer (including color, Z, stencil, etc)
> Pbuffers
> Renderbuffer/Framebuffer objects
> Pixel/Vertex buffer objects
> Texture images
> OpenGL miscellaneous (e.g. vertex/fragment programs)
> X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects.
> 1. The l
> The log design presents numerous opportunities for rogue processes to do
> bad things. At some level, that's inherent in the nature of direct
> rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be moving towards
be
On Maw, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote:
> > Another part would be to only allow mapping owned parts of the
> > framebuffer.
> >
>
> You'd have to get the cliprects from a trusted source then...
Memory management hardware isn't that fine grained. Doing cliprect
register acces
On Maw, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote:
> Is there any way to make that work without going to the kernel for each
> allocation? Personally I'd like to have the protection even if it
> degrades performance slightly.
X allows applications to read the displayed video memory anyway s
On Sul, 2005-08-14 at 21:03 +0200, Philipp Klaus Krause wrote:
> > not yet. Alan Cox had a semi-working version here:
> > http://www.linux.org.uk/~alan/sis6326.tar.gz
>
> This only contains the DRI part. Does that mean it uses the same
> DRM as the 305?
There is a small p
On Gwe, 2005-07-08 at 09:18, Thomas Hellström wrote:
> Is this because they are not physically contigous or because they may not
> be accessible to the PCI device? I was thinking of using vmalloced memory
> instead of kmalloced for the device sg-list, and since it is a linked list
> it should be ab
On Iau, 2005-07-07 at 23:50, Thomas Hellström wrote:
> 1.) get_user_pages() should presumably lock a page into physical memory.
> Will this always cause a segfault for an invalid address?
You'll get an error for invalid space. You may also get null entries in
the array for locking the paged if th
On Sul, 2005-07-03 at 05:04, Jon Smirl wrote:
> There are three DRI drivers with no DRM. What is up with these?
> gamma
> s3v
> trident
trident was never finished
s3v and gamma were both against old DRM and are not shipped in curren
trees
---
On Llu, 2005-06-27 at 01:02, Eric Anholt wrote:
> > definitely vote for 120. You will need to do some manual touch up
> > after Lindent. It will mess up formatting of C99 initializers and some
> > constant blocks.
>
> Please, 80 is standard.
Not for most code I've looked at. 80 generates horrible
> I very strongly believe that the right model moving forward is for
> user-mode to say to the kernel, "I beg of thee. Initialize thyne self."
Much of the initialization of chips is complex and messy and not
neccessarily good kernel material. SAREA setup I agree seems an obvious
kernel thing to d
On Sad, 2005-06-18 at 16:54, Jon Smirl wrote:
> How about this as a safe first step:
> 1) Remove the general root capability check
> 2) Change the semantics of the root_only field on these calls to mean
> master only.
> 3) Push the root capability check into each of these IOCTL individually.
> 4) L
On Sad, 2005-06-18 at 20:22, Jon Smirl wrote:
> Then this is a card by card problem. If user space needs to get to the
> registers, and we can't split the safe registers from the unsafe
> (security issues) ones, then the user space drivers also needs to run
> as root.
Incorrect. See the via driver
On Sad, 2005-06-18 at 23:30, Adam Jackson wrote:
> The issue is that drmAddMap, the function that sets up these maps, is
> currently run from the server during DDX bringup. These maps can just as
> easily be created during DRM init - and as a design issue, probably _should_
> be created there.
On Llu, 2005-06-13 at 11:28, Matt Sealey wrote:
> You have a good point. I still say it would not endear you to SiS.
> It is way too easy for them to be spiteful than help.
As I understand it SiS no longer own the graphics parts anyway but they
were
merged with trident and dumped off somewhere.
On Mer, 2005-05-25 at 21:42, Michel Dänzer wrote:
> Anything that isn't used for pre-R300 chips as well, as those don't seem
> to suffer from the same kind of lockups.
Assuming alignment is just performance could be erroneous if there are
chip bugs like interlocking errors however, or end of ring
On Mer, 2005-05-11 at 02:16, Ian Romanick wrote:
> I was afraid of that. :( The problem is that the MGA can *only* DMA
> commands & vertex data from "PCI" memory or AGP. In the case of the
> G200 (typically only 8MB), you don't want to use 1/8th of your on-card
> memory for commands either. I
On Maw, 2005-05-10 at 22:59, Ian Romanick wrote:
> 2. Primary DMA buffer. The DDX carves of 1MB for the primary DMA
> buffer. I don't think that's outside the reasonable realm for
> drm_pci_alloc. If it is, can this work with a smaller buffer?
You'll have trouble grabbing that linearly from m
> This in itself is a little bit strange since, if the following occurs:
>
> * Check condition
> * if false, go to sleep
>
> and DRM_WAKEUP is called by the interrupt handler in between those two,
> the sleep should never occur, which now it seems to do anyway.
Is the current code still using t
On Gwe, 2005-03-11 at 19:42, Dave Jones wrote:
> We got a bug report in our bugzilla from a user that saw
> SiS DRM crashing when he restarted X.
This object could be vmalloc()'d
---
SF email is sponsored by - The IT Product Guide
Read honest
On Iau, 2005-01-06 at 18:36, Felix KÃhling wrote:
> Hi all,
>
> has anyone ever considered using the video overlay for 3D page flipping?
> It always bothered me that the page-flipping method used by the radeon
> drivers is so complicated WRT 2D/3D interaction and it would even stop
> working when
On Maw, 2005-01-04 at 09:18, Alan Hourihane wrote:
> The DDX and DRM driver are still in the DRI CVS on the trident-0-0-2 branch.
0-0-2 seems to be empty, but 0-0-1 has code ?>
---
The SF.Net email is sponsored by: Beat the post-holiday blues
On Llu, 2005-01-03 at 14:46, Sjoerd Langkemper wrote:
> Hello,
>
> I would like 3D acceleration for my on-board Trident Cyberblade (VIA
> PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What
> do I have to program in order to get this done?
You would need to write
- Locking
On Gwe, 2004-12-17 at 20:55, Mike Werner wrote:
> [2/4] Run Lindent on generic.c
Please don't mix reformatting with oither submissions, especially as
Dave Jones is parallel working on and submitting patches for the various
cache/tlb flush violations in the current code that will overlap such a
ref
Does this not break compatibility with 6.8.0/6.8.1 - that seems at least
as big a problem as the breakage from 6.7 because it will prevent anyone
stuck with a 6.8.* driver from updating to get security fixes ?
---
SF email is sponsored by - The
On Sul, 2004-12-12 at 18:53, Eric Anholt wrote:
> An all-fallback DRI driver is slower than software indirect GLX, if I
> remember right.
If your fallback driver has the frame buffer mapped and allocates the
backbuffer in main memory it ought to give good performance. A naÃve
implementation of DRI
On Mer, 2004-12-01 at 12:19, Thomas HellstrÃm wrote:
> Actually, I've been running with a 512Kb userspace / kernel buffer, and
> I've not seen any noticable drop in performance, but I'm not sure that the
> submissions actually will be that large with the programs I've tested.
Might be worth findin
On Maw, 2004-11-30 at 20:09, Thomas HellstrÃm wrote:
> Textures in AGP memory is currently not allowed, but they are disabled
> in the Mesa driver as well, for some reason. If they are allowed in the
> future, Texture address checks probably have to be implemented but that
> should be a minor ta
On Sul, 2004-11-28 at 23:36, [EMAIL PROTECTED] wrote:
> Hello,
>
> I would like to know if a dri kernel module for the sis-6326 video card
> is in development or if a version is available for download? I am using
> Fedora Core 1.
I got it vaguely working but never had time to debug texture
On Mer, 2004-11-24 at 02:28, Dave Airlie wrote:
> That is due to the new remap_pfn_range stuff, I'm not sure we can put
> checks for it into our CVS tree, as -mm trees don't have different
> KERNEL_VERSION than Linus trees, you could try building the linux-core
> tree rather than the linux-2.6 tree
On Iau, 2004-11-18 at 23:22, Ian Romanick wrote:
> The problem with that is the X-server will have to render everything 3
> times. That's going to suck. You'll have some of the same problems
> that Jacek had with his stereo patch.
No the X server needs to render everything (expensive bit) _onc
On Iau, 2004-10-21 at 16:49, Thomas HellstrÃm wrote:
> architecture-independent library should be able to determine whether the
> connection is local or not. Any hints on how to do best do this without
> using drm?
Try DRM first and see if it fails.
There really isn't much else you can do - "loca
On Maw, 2004-10-12 at 01:14, Dave Airlie wrote:
> application so it could modify them after validation if it was sufficently
> sneaky enough... for the mach64 the idea was to allocate a pool of private
> buffers using pci interfaces and use those to pass command streams after
> verification.. the u
On Llu, 2004-10-11 at 09:42, Thomas HellstrÃm wrote:
> So what is your actual suggestion?
> Export read-write as default or, as proposed, export read-write when
> "AllowInsecureDRI" is enabled in the X server config?
AllowInsecureDRI is less secure than forcing users to run things as root
or fix t
On Iau, 2004-10-07 at 15:40, Ville SyrjÃlà wrote:
> Why can't we make AGP memory cached? Wouldn't it be enought to flush the
> caches at some critical points?
Possibly although it is not trivial to see how we get that right,
especially with the 4Mb kernel maps. The x86 processor cannot handle a
p
On Iau, 2004-10-07 at 00:41, Thomas Hellstrom wrote:
> One option is to do command verification for 2D commands only, and
> tighten up the DDX. In this way the DRM could go into the kernel and be
> usable with XvMC. OpenGL possibly as root, until someone has the time to
> fix up the 3D driver an
> Note that there's some code in there already which uses the blitter to copy
> from framebuffer to agp memory, though it tries to implement the entire
> readpixels() operation rather than being a useful low-level operation.
AGP memory is hostside uncached (CPU limitations on x86 for one) which
On Mer, 2004-10-06 at 22:02, Ian Romanick wrote:
> Here's my question. Is there any way to "trick" it into doing
> back-to-back reads as a single PCI transfer? So, if I did something like:
Not that anyone has found. I'm not sure PCI even really allows it except
for prefetchable memory.
Except
On Mer, 2004-10-06 at 19:36, Ian Romanick wrote:
> from video RAM to system RAM. It has to convert the pixel data from its
> native, on-card format to RGBA. In the case of my patch, it
> converts from BGRA to RGBA while doing the copy. That's why it needs
> the SSE2 shift instructions.
>
On Mer, 2004-10-06 at 16:56, Dieter NÃtzel wrote:
> What about MMX2, 3DNow, 3DNow2 (pro), SSE (1)?
>
> It would be nice if we have this like MPlayer:
Soreen wrote a set of routines for this that are in Xorg 6.8.* and
optimise the readback of video memory for render operations - naturally
enough t
On Sul, 2004-10-03 at 23:42, Jon Smirl wrote:
> Is there are device driver level interface defined for controlling
> tuners?
Both at the Xv and the kernel level yes.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
> In particular, I can contribute the code that does Framebuffer->System Ram
> transfers over PCI/AGP. It is currently GPL licensed, but there is no
> problem if BSD folks want it too.
This will do *wonders* to X render performance if used pr
On Sad, 2004-10-02 at 22:43, Adam Jackson wrote:
> > That looks very cool. I hope someone copies the code into mesa.
>
> I hope they don't, Mesa is BSD now and according to their sf project page
> sw-shader is {L,}GPL:
>
> http://sourceforge.net/projects/sw-shader
LGPL is fine for most things.
On Iau, 2004-09-30 at 13:56, Keith Whitwell wrote:
> > Looking in the i810 driver, it seems like the ringbuffer is flushed and
> > disabled until the X server calls EnterVT again, and AGP memory is
> > unbound. How is the client generally notified about this?
>
> The server holds the hw lock until
On Mer, 2004-09-29 at 22:52, Felix KÃhling wrote:
> Module Size Used by
> savage 3520 0
> drm62500 3 savage
>
> Is it normal that the savage module looks unused?
looks like a bug. If the drm layer provides the file_operations for
the device
On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote:
> - once we have Alan's idea of the graphics core implemented drm_init()
>should go awaw
Last I heard Dave Airlie had that working having fixed my bugs.
---
This SF.net email is spons
On Sad, 2004-09-25 at 04:41, Patrick McFarland wrote:
> Not to sound ignorant, but isn't that a bug in the
> mobo/bios/chipset/processors? That shouldn't even be possible, should
> it? (And if it 'is', shouldn't Linux disable SSE usage on both
> processors?)
You can mix PII and PIII processors in
On Iau, 2004-09-23 at 17:21, Philipp Klaus Krause wrote:
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : 11 occurred at PC=0x4D4E5A16
> Function=(null)+0x4D4E5A16
Looks like a buffer overrun or memory corruption. Are you trying to
use mesa very thre
On Iau, 2004-09-23 at 17:22, Ian Romanick wrote:
> The folks on #freedesktop suggested parsing cpuinfo, and I wrote some
> simple code to do that. Are you saying that, if CPUID returns the SSE
> bit set and we're on a 2.4 or later kernel, we're good to go? That
> would make me very happy becau
1 - 100 of 455 matches
Mail list logo
