> 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.
---
about things they
said they would do. Actually I think they've been quite restrained. I'd
probably have proposed a licence change to make it only work on FreeBSD
and Solaris given that treatment ;)
> Even if you need to change the interface, I've actually looked at the
> patch in q
ose_ try to avoid at all cost being
compatible."
Great way to make friends.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and f
) behaviour. I've yet to see anyone meaningfully argue it was
the wrong thing to do.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and
are you screaming at the DRM and Nouveau people about the
breakage ? That's the bit I really don't understand.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling,
smart enough to
handle the Nouveau old/new ABI before the patch went upstream. Hindsight
is an exact science.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, f
7;d be pretty
> > ace.
>
> You have to support less than %10 of the amount of hardware we have to
> support.
If we believe the changelogs including X.org userspace then they also have
a good deal less than 10% of the contributors.
Alan
developers don't control Fedora packaging policy, in fact the GPL licence
specially ensures the control is not theirs.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed
on of a set of decisions and
misunderstandings by Linus, Fedora and the Nouveau developers together
that combined to create the mess.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yoursel
produced a problem. It happens all the
time, screaming and blaming may be how politicians sometimes behave but we
can surely do better ?
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for you
> 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 softw
git tree ? Alternatively does it need
to be easier to have multiple Nouveau libdrms autoselected according to
the kernel side versioning. ELF library versioning is not rocket science
and both the old and new libraries exist and can be installed so all the
bits are present except for th
Developers start doing the cleanup
Linus throws a tantrum because they did the cleanup after
merge
*YOU* forced the early merge (rightly or wrongly)
*YOU* effectively created the API break problem
So blami
r offence than breaking an ABI - its called not RTFM.
Alan
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel
> lockup was reported after the 1s CP activity timeout.
>
> Signed-off-by: Jerome Glisse
--
Alan.
"One must never be purposelessnessnesslessness."
--
Download Intel® Parallel Studio Eval
or this issue.
> >
> > Okay, I'll set it up later.
Created as Bugzilla #15385. I added you to the CC: list. Further
communication should be CC'ed to linux-pm and dri-devel.
Alan Stern
--
Download In
d" this means "turn on the wakeup power
> for this devices and enable its wakeup GPE unconditionally before suspend".
> If it shows "disabled", it means "leave that to someone else" (that's
> analogous
> to the "on" and "auto"
ng?
>
> Not really. There are two separate flags for wakeup. One of them is a
> property of the "physical" device object (eg. PCI device structure) and that
> one is set/unset via sysfs. The other is a property of the device's ACPI
> "shadow" object and is
Rafael J. Wysocki wrote:
> On Thursday 04 February 2010, Zhenyu Wang wrote:
>
>> On 2010.02.03 23:44:41 +0100, Rafael J. Wysocki wrote:
>>
>>> On Wednesday 03 February 2010, Alan Jenkins wrote:
>>>
>>>> Hi
>>>>
>>&
r suspend (mentioned here:
http://article.gmane.org/gmane.linux.kernel.pci/4696).
Regards
Alan
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the be
nsole might do something as part of its
suspend/resume path IFF the vt in question is in graphics mode.
Alan
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and th
m the suspend/resume
logic ? The problem starts there. If it was being handled off the device
suspend/resume method then there wouldn't be a mess to start with ?
Start at the beginning
- Why do we switch to arbitarily chosen 'last vt'
- Why isn't vt rela
> 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 Wed, 20 Jan 2010, Tomas M. wrote:
> since 2.6.32 you can change the resolution with video=VGA-1:640x480 boot
> parameter and emulate the old behaviour.
That works even with Fedora-12, which uses a 2.6.31-based kernel.
Thanks.
Alan
save the exact output but this is close):
mode: "1280x1024-0"
D: 0 MHz H: 0 kHz V: 0 Hz
geometry: 1280 1024 1280 1024 32
timings: -1 0 0 0 0 0 0
rgba: 8/16,8/8,8/0,0/0
Alan Stern
-
ad a console
> font at boot up. Depending on the distro if that is the case you will have
> to disable it.
It turns out that preventing the mode switch is easier. Finding it
took a certain amount of digging, but the "nomodeset" kernel paramet
000:00:02.0 on minor 0
Thanks,
Alan Stern
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to
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
there are legal questions
involved why on *earth* do people keep asking them on public mailing
lists when they know the lawyers views/opinions/decisions will not be
publishable there ?
Ted, you of all people know that if you want to
was shipped by Intel with an nVidia card (and has a power supply that
> craps out if you don't use several hundred watts of power, so I can't
> change it to something more power-efficient - seriously).
Alan
---
d to do that then ask why Fedora should, its not
their code either.
Alan
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
_
> 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
excuse too - which I also know is
> bullshit, because I can look at the git tree Fedora apparently uses, and
> it merges without any conflicts what-so-ever.
So merge it - it's your call as the maintainer of the master tree - or put
it in staging and dike out the microcode
> 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 re
el?
I know BSD & OpenSolaris really don't matter much, but there are still
some of us using libdrm on kernels other than Linux.
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X W
app then it sounds to me like it's not a general kernel interface so
probably isn't a good interface anyway, let alone what the code may do.
Alan
--
Enter the BlackBerry Developer Challenge
This is your chance to win
> 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)
-
working along with 2D render, then submit the bits the need to do
hardware rendering. After that tackle what is needed for 3D - as is
happening with the Nvidia drivers and then submit a DRM module for their
work.
Alan
-
> * 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)
--
me systems (Solaris for instance), setting _XOPEN_SOURCE
reduces the available API to just the X/Open standards, instead of extending
it as it does on Linux - the AC_USE_SYSTEM_EXTENSIONS knows how to set this
correctly for both.
--
-Alan Coopersmith- alan.coopersm...@sun.com
th buffer in Mesa. The DDX doesn't really need to
know about it.
Alan.
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
On 10/27/08, Eric Anholt wrote:
> On Mon, 2008-10-27 at 14:27 +0000, Alan Jenkins wrote:
>> What does this mean, should I do anything about it? Is tiling nice to
>> have?
>>
>> It sounds like GEM broke something - though maybe it just added a more
>> verbose erro
On 3/23/09, Alan Jenkins wrote:
> On 10/27/08, Eric Anholt wrote:
>> On Mon, 2008-10-27 at 14:27 +0000, Alan Jenkins wrote:
>>> What does this mean, should I do anything about it? Is tiling nice to
>>> have?
>>>
>>> It sounds like GEM broke
> > 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
policy on this, I refer you back to the Intel wireless and
binary management daemon discussions. I likewise refer you to some of the
input device discussions related to USB HID and devices where vendors
wanted us to exclude their device in favour of propr
ior to a swap.
I've committed this already to the gallium-mesa-7.4 branch, but any
comments appreciated before I push to the master branch?
Thanks,
Alan.
commit b163d4f9ee2ab4d54daf7c17c097cae51c9c6db2
Author: Alan Hourihane
Date: Thu Feb 19 18:39:08 2009 +
glx: add support for
Alan Jenkins wrote:
> Alan Jenkins wrote:
>> What does this mean, should I do anything about it? Is tiling nice
>> to have?
>>
>> It sounds like GEM broke something - though maybe it just added a
>> more verbose error report.
>>
>> System: EeePC 701
interested in is the "Disabling tiling".
Thanks
Alan
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great pr
Alan Jenkins wrote:
> What does this mean, should I do anything about it? Is tiling nice to have?
>
> It sounds like GEM broke something - though maybe it just added a more
> verbose error report.
>
> System: EeePC 701
> Kernel: v2.6.36-rc1-5-g23cf24c
> Chipset: Int
the kernel
source layout very well.)
--
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - X Window System Engineering
>From 2babb8b8b68b74185bf16a927095906e75744245 Mon Sep 17 00:00:00 2001
From: Alan Coopersmith <[EMAIL PROTECTED]>
Date: Thu, 5 J
ZE_TYPE__
#else
# warning "__SIZE_TYPE__ not defined. Assuming sizeof(size_t) ==
sizeof(unsigned long)!"
# define DRM_SIZE_T unsigned long
#endif
--
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems,
On Fri, 2008-06-06 at 12:36 +0100, Alan Hourihane wrote:
> On Fri, 2008-06-06 at 11:23 +0100, Dave Airlie wrote:
> > > Dave,
> > >
> > > Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted
> > > the --enable-ttm-api flag in mesa now
does
> the decoupling from the mm interface.
Ouch.
It would be good to know Kristian's plans.
Alan.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just ab
ease of libdrm as 2.3.1, Mesa needs to deal with
> this for 7.1.
Dave,
Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted
the --enable-ttm-api flag in mesa now ??
Alan.
-
Check out the new SourceFor
m
> would be even more logical?
I think gpu is better - we are seeing various GPU as CPU accelerator
toolkits appearing and assuming the AMD one ends up open source we will
end up with gpu/something that isn't video.
Remember GPU = Grahi^WGeneric Processing Unit ;)
Alan
--
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
On Wed, 2008-04-09 at 09:34 -0700, Jesse Barnes wrote:
> On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote:
> > On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote:
> > > On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote:
> > > > I was going to
differently now then since the last time I looked at the code,
> > are you sure that stage_two is being run?
>
> I'll have to check, I'm not sure I'm even getting interrupts...
Jesse,
Is this i915 or i945/i965 you are testing on ??
Alan.
--
> 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
On Wed, 2007-09-26 at 15:43 +0100, Keith Whitwell wrote:
> Alan Hourihane wrote:
> > linux-core/drm_drv.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > New commits:
> > diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from
> > 0
> 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
ever gets merged this would also help as
you could possibly grab a huge page from the allocator for this purpose
and have to flip only one TLB entry.
Alan
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping th
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
couple of GLX module cleanups, and I think it's all ready
> > > > to push:
> > > >
> > > > http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2
> > > > and
> > > >
> > > > http://gitweb.freedesktop
e the X server changes
> now plus a couple of GLX module cleanups, and I think it's all ready
> to push:
>
> http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and
> http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2
>
> One thing
On Wed, 2007-04-11 at 19:13 +0100, Alan Hourihane wrote:
> On Wed, 2007-04-11 at 10:40 -0700, Jesse Barnes wrote:
> > On Wednesday, April 11, 2007, Jesse Barnes wrote:
> > > Some people were asking about modeseting on #dri-devel this morning so I
> > > thought I'd p
if ((retcode = dev->driver->load(dev, ent->driver_data)))
> + goto error_out_unreg;
> +
> retcode = drm_ctxbitmap_init(dev);
> if (retcode) {
> DRM_ERROR("Cannot allocate memory for context
On Wed, 2007-02-28 at 10:55 +0100, Michel Dänzer wrote:
> On Sun, 2007-02-25 at 19:35 +0000, Alan Hourihane wrote:
> > I know what the problem is here. And bugzilla #5714 will cure it. So I'm
> > getting inclined to pull the frontbuffer-removal branch into master and
> >
I know what the problem is here. And bugzilla #5714 will cure it. So I'm
getting inclined to pull the frontbuffer-removal branch into master and
fix up the drivers on the fly.
How does this sound to others.
Alan.
On Sat, 2007-02-24 at 15:00 -0800, [EMAIL PROTECTED]
wrote:
&
ve this bug.
>
> <>
Also note that changes should be supplied as a patch diff from the
original file, not the complete file itself otherwise the changes can't
be easily reviewed.
>
--
Alan.
"One must never be purposelessnessnesslessness."
signature
Following the instructions on dri.sourceforge.net and stupidly expecting
them to work, I got this error from Mesa:
(I've highlighted the line I think is causing it to fail.)
../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:405: warning: 'spec[0]' may
be used uninitialized in this function
../../../..
When I run the CVS R200 kernel modules, many megabytes of
synchronization errors appear in xorg.log and it still crashes when I
run any GL app, including glxinfo. It doesn't matter what version of
Mesa I'm running, it should be impossible to crash the kernel like this.
=\
--
If you tell a linux
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized mach64 2.0.0 20060718 on minor 0:
[drm] Used old pci detect: framebuffer loaded
[drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held,
held 0 owner f72941c0
[drm:drm_unlock] *ERROR* Process 5048 using kernel context 0
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
Andi,
That's a bug that's been around for a while, and regardless of the
machine having no AGP, you still need agpgart for the 965 driver to
function as internally it's really an AGP device.
Alan.
On Sun, 2006-08-13 at 11:06 +0200, Andi Kleen wrote:
> Hello,
>
> After
gt; (gdb) frame 0
> #0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
> at main/framebuffer.c:384
> 384if (buffer->Name) {
> (gdb) p buffer
> $1 = (struct gl_framebuffer *) 0x0
>
> Anyone else seeing this?
Update your CVS.
I've already f
On Thu, 2006-06-01 at 11:20 -0600, Brian Paul wrote:
> Alan Hourihane wrote:
> > On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote:
> >
> >>On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote:
> >>
> >>>-BEGIN PGP SIGNED MESSAGE-
>
On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote:
> On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Jacek Poplawski wrote:
> > > On 5/30/06, Pedro Maia <[EMAIL PROTECTED]> wrot
at exist in the DRI driver. I'm not sure exactly why it doesn't
though.
Doing this...
export LD_PRELOAD=/usr/lib/libGL.so
to force the libGL linkage fixes the issue.
Alan.
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sat, 2006-02-18 at 19:49 -0500, Adam Jackson wrote:
> On Saturday 18 February 2006 19:41, Adam Jackson wrote:
> > On Wednesday 15 February 2006 20:34, Alan Hourihane wrote:
> > > Already fixed in CVS. Some code got away that's in-progress for the
> > > f
On Sat, 2006-02-18 at 19:41 -0500, Adam Jackson wrote:
> On Wednesday 15 February 2006 20:34, Alan Hourihane wrote:
> > Already fixed in CVS. Some code got away that's in-progress for the
> > front buffer removal from the DRI.
> >
> > I'll be uploading a muc
On Wed, 2006-02-15 at 20:00 +, Dave Airlie wrote:
> > libGL error: drmMap of framebuffer failed (Invalid argument)
> > libGL error: reverting to (slow) indirect rendering
>
> I've been wondering about this, I mentioned it to Alan + Keith at XDC,
>
> I've
uire the newer version.
The DDX was bumped, but the check in intel_screen.c was missed to check
for the newer DDX.
I've just fixed that now.
Alan.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
fo
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
It's not a problem.
Don't worry about it.
Alan.
On Wed, 2006-01-25 at 21:56 +0100, Peter Weber wrote:
> Hello,
> I hope I've got the right mail-adress, I have a question at the i915 (GMA900)
> developer of the i810 driver?!
> As far as I know nearly everyone wit
r now.
But the next logical step is to remove this mapping from the DRI layer
and leave it upto the drivers to map it just as if it were a back or
depth buffer.
Any objections or comments on this, as it may well break binary drivers
that depend on the DRI mapping it ??
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 Fri, 2005-09-23 at 22:07 +0800, Antonino A. Daplas wrote:
> Alan Hourihane wrote:
> > Has anyone any objections to me removing the MTRR code from the DRM.
> >
> > It doesn't have the intimate knowledge needed to properly configure
> > MTRR's and fails
of defining an ABI. Obviously
users who replace system libraries with ones they got from another
source get burned whether its a perl "upgrade" required by a vendor or
libc.
Alan
---
This SF.Net email is sponsored by:
Power Architecture
of "is XYZ accelerated" as an API but
that is an upstream flaw.
Alan
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
-
I tried to build Mesa on BeOS and this is a summary of the errors...
Apparently the beos port is quite stale...
errors
Description: Binary data
BeOS Attributes
Description: application/be_attribute
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
e is one we can just do nothing,
> or add one if not .. or a drm driver option to enable/disable it..
My other point here is that some hardware requires MTRR's to be aligned
and the DRM doesn't know how to do that it just ships off the current
region to mtrr and doesn't look
On Fri, 2005-09-23 at 12:46 +0100, Dave Airlie wrote:
> acceptable.. some way to perhaps have the X server tell the DRM driver to
> not bother with them...
In the interests of backwards compatibility I suppose this may be a
reasonable option though.
1 - 100 of 1004 matches
Mail list logo
