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.
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 ABI
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 starts
On Thu, 04 Mar 2010 14:32:02 -0500
Jeff Garzik j...@garzik.org 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.
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#174; Parallel Studio Eval
Try the new software
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
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.
There
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 the
On Fri, 05 Mar 2010 07:49:32 -0800 (PST)
David Miller da...@davemloft.net wrote:
From: Daniel Stone dan...@fooishbar.org
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
On Fri, 5 Mar 2010 16:56:10 +0100
Luca Barbieri luca.barbi...@gmail.com 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
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 people about
On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
David Miller da...@davemloft.net wrote:
From: Daniel Stone dan...@fooishbar.org
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
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
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
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 non
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 something
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 non
On Fri, 15 Jan 2010 12:40:30 + (GMT)
James Simmons jsimm...@infradead.org 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
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 a
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
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
bullshit,
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
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.
* 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)
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 what
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)
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 have
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
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 its a
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/drivers/char
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
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 tlb
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 wrapped the
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
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 of
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 both
I
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
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 like
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 and you
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 the single
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.
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
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_addr15
== 0) for all lines.
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
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
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 location
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 part
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 so
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 access via
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
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 patch to the 2D driver needed
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 able
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
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
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 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 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) Leave
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 do
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 Dnzer 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'll
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
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 the
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 Khling 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 (if?)
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
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 -
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 nave
implementation of DRI
On Mer, 2004-12-01 at 12:19, Thomas Hellstrm 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 finding
On Maw, 2004-11-30 at 20:09, Thomas Hellstrm 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 task.
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 textures or
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)
On Iau, 2004-10-21 at 16:49, Thomas Hellstrm 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 - local
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 user
On Llu, 2004-10-11 at 09:42, Thomas Hellstrm 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 the
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 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 and
On Iau, 2004-10-07 at 15:40, Ville Syrjl 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
page
On Mer, 2004-10-06 at 16:56, Dieter Ntzel 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 they
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.
From
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 of
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
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 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. It
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 the VT
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
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 a
On Mer, 2004-09-22 at 22:14, Eric Anholt wrote:
2.2 kernels and kernels not properly configured for Pentium3 CPUs. So,
what's the right way on a 2.4 or a 2.6 kernel to determine if an app can
use SSE? What about BSD?
On FreeBSD we just use a convenient little sysctl to pull out
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 because
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
On Maw, 2004-09-21 at 08:58, Kean Johnston wrote:
That's not a statement thats safe to make. BSD (or any other OS
that XOrg supports) may not have Linux's I2C driver system. TODAY.
What if, next week, BSD gets such a beast, or HP-UX does, or
Well they can't use the low level Linux code anyway,
On Maw, 2004-09-21 at 16:19, Jim Gettys wrote:
Please read, understand and comment on the license policy strawman I
posted both to dri-devel and the xorg list.
Oh I did, don't take my response as anything but throwing up the
logical conclusion to that policy. I'm not in favour of that
On Maw, 2004-09-21 at 19:18, Dag Bakke wrote:
1. Is the rv360 (9600xt) close enough to the developers hardware to
a) benefit from the 2d improvements already made w.r.t. CP acceleration
b) be of any use for testing purposes
The 6.8.0 server supports 2D acceleration up to the PCI Express cards
On Maw, 2004-09-21 at 16:56, Jon Smirl wrote:
Driver decides to either do it itself in kernel, or call userspace
helper if that would be too complex.
It is
The driver almost always needs to go to user space to get the file of
mode line overrides that the user can create. But there is
On Sul, 2004-09-19 at 21:40, Keith Packard wrote:
I just need to know where the frame buffer lives; it can move or change
pitch at any time. I can even deal with the frame buffer moving without
warning if necessary. What I can't handle is off-screen memory suddenly
disappearing on me; I
1 - 100 of 406 matches
Mail list logo
