On Wednesday 11 December 2002 07:51 pm, you wrote:
> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> constraints and stability concerns. I know that this complicates things
> a little, but I don't see a practical alternative.
>
> I've created a branch called "mesa-4-0-4-b
XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
constraints and stability concerns. I know that this complicates things
a little, but I don't see a practical alternative.
I've created a branch called "mesa-4-0-4-branch" in the DRI CVS, branching
from the trunk tag (trunk-20
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote:
>Margit Schubert-While wrote:
>> From drivers/char/agp/agpgart_be.c
>> 4554,4559
>> { PCI_DEVICE_ID_INTEL_845_G_0,
>> PCI_VENDOR_ID_INTEL,
>> INTEL_I845_G,
>> "Intel",
>>
Alan,
What would you like to see be implemented to help get the job done. In
other words, what do you need from the DRI team?
On Wed, 11 Dec 2002, Alan Cox wrote:
> On Wed, 2002-12-11 at 20:12, D. Hageman wrote:
> > I have noticed some feedback from Alan and Linus already on this list. Is
On Wed, 2002-12-11 at 20:12, D. Hageman wrote:
> I have noticed some feedback from Alan and Linus already on this list. Is
> anyone taking care of things yet?
No. There isnt currently a nice setup for this.
---
This sf.net email is sponsore
On Wed, Dec 11, 2002 at 10:32:13AM -0800, Ian Romanick wrote:
> Has anybody run into problems with the vblank interrupt support on G400? In
> mgaWaitForVBlank the 'if ( !mmesa->mgaScreen->irq )' test fails (i.e., user
> mode thinks there's an IRQ), but in the kernel mga_wait_vblank returns with
>
I was talking on the dri-devel channel with Mike Harris and a few
questions popped up concerning DRM and the Kernel.
Who is the lead guy that takes care of the DRM stuff? Stuff being pulling
it out of CVS occasionally to submit to Linus, Alan, etc. for inclusion in
the kernel and making sure
Has anybody run into problems with the vblank interrupt support on G400? In
mgaWaitForVBlank the 'if ( !mmesa->mgaScreen->irq )' test fails (i.e., user
mode thinks there's an IRQ), but in the kernel mga_wait_vblank returns with
errno set to EINVAL. THe only was I can see that this would happen is
On Tue, Dec 10, 2002 at 08:34:16PM -0800, dax wood
>wrote:
>> hello out there,
>>
>> I have a problem with the current dri cvs
>> (trunk) for a Rage 128. the odd thing is that I
>>got
>> the damn thing to work (nicely), but with all
>> programming i think i found a bug in the dri side
>>of
>
On Tue, Dec 10, 2002 at 08:34:16PM -0800, dax wood wrote:
> hello out there,
>
> I have a problem with the current dri cvs
> (trunk) for a Rage 128. the odd thing is that I got
> the damn thing to work (nicely), but with all
> programming i think i found a bug in the dri side of
> Mesa 5.0.(
Dave Jones wrote:
On Wed, Dec 11, 2002 at 12:45:49PM +, Keith Whitwell wrote:
> In any case I don't think the string in the informational is very useful --
> it's a potentially inaccurate translation of state from *another* module, so
> I'm just removing the lot.
Cool, that gets my vote
On Wed, Dec 11, 2002 at 12:45:49PM +, Keith Whitwell wrote:
> In any case I don't think the string in the informational is very useful --
> it's a potentially inaccurate translation of state from *another* module, so
> I'm just removing the lot.
Cool, that gets my vote too 8-)
Da
Title: RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Accoding to the official Linux pci database at
http://www.yourvote.com
the strings in the table should be:
INTEL_I845,
"Intel",
"i845 E/MP/MZ",
and
INTEL_I845_G,
"Intel",
"i845 G/GL/GV/GE/PE",
I think that would bring a
DRI folks, this seems like duplication given that this data is available
in agpgart. How about changing this to read whatever agpgart has set in
.chipset_name ?
And it looks like the mechanism that drm uses for quering agp doesn't return
the string in question. (I don't really understand the
Dave Jones wrote:
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote:
> IIRC, the 845G is a "new" version of the 830MP chipset (it had been
> added by Abraham vd Merwe & Graeme Fisher some months ago), but acts
> basically just as the 830MP. Therefore the entry is correct Or may
YOU CAN LOOK AND FEEL YOUNGER !!! INCREASE ENERGY / ENDURANCE! LOSE WEIGHT & BUILD MUSCLE at the same time!MEN: Increase Lean Muscle Mass Reduce Body Fat Increase Exercise Performance Increase Muscle Strength Increase
Endurance WOMEN: Reduce & Control Body
Dave Jones wrote:
I'll check the chipset docs when I get time, and add a comment if
necessary. No-one seems to be complaining that it isn't working,
so I'm inclined to believe your diagnosis is correct.
I found the thread of lkml containing the discussion about that ... here
is the link to th
Title: ¿ø°íÁß°³, ÀÚºñÃâÆÇ, ÀÚ¼Àü, ±âȹÃâÆÇ µî ÃâÆǼºñ½º Àü¹®È¸»ç
ÀÚºñÃâÆÇ ¾È³»(½ÃÁý,¼öÇÊ,¼Ò¼³,°æÁ¦,°æ¿µ,ó¼¼,±âŸ)
dri-devel´Ô²²
ÇູÀÌ ÇÔ²²ÇϽñ⸦ º÷´Ï´Ù.±ÍÇÏÀÇ
¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÁß¿¡¼ ¾Ë°Ô µÈ
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote:
> IIRC, the 845G is a "new" version of the 830MP chipset (it had been
> added by Abraham vd Merwe & Graeme Fisher some months ago), but acts
> basically just as the 830MP. Therefore the entry is correct Or maybe
> if it gets co
Ooops... the patch I sent for 2.5.51 is wrong, since there I added a
INTEL_I845 instead of a INTEL_I845_G (I know vim *does* weird things in
my back 8-)
Here is the correct one...
Regards
Nicolas.
--
Nicolas Aspert Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (E
Margit Schubert-While wrote:
From drivers/char/agp/agpgart_be.c
4554,4559
{ PCI_DEVICE_ID_INTEL_845_G_0,
PCI_VENDOR_ID_INTEL,
INTEL_I845_G,
"Intel",
"i845G",
intel_830mp_setup },
Surely this is wrong or ?
Sh
On Wed, 2002-12-11 at 10:38, Juan Quintela wrote:
> could you told me what X version against are your dri
> patches?
>
> I am having a bad time (not being an XFree hacker) to merge the X part
> of your patch (the kernel patch was a no brainer).
>
> Basically my problem is that the
> "charl" == Charl P Botha <[EMAIL PROTECTED]> writes:
Hi
charl> New binary snapshots of the DRI suspend/resume modified Radeon drivers are
charl> available at http://cpbotha.net/dri_resume.html - these are the first DRI
charl> suspend/resume driver snapshots since the merge of XFree86 HEAD i
23 matches
Mail list logo
