On Tue, 14 Sep 2004 02:21:21 +0100, Sérgio Monteiro Basto
<[EMAIL PROTECTED]> wrote:
>
>
> Hi Alex and everyone
>
> " http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
> the code still needs the "develdri" #ifdefs added."
I'll probably commit the merge of the savage DRI driver to xorg cv
Hi Alex and everyone
" http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
the code still needs the "develdri" #ifdefs added."
Savage dri works quite well (again) on xorg 6.8, except on xv video mode
with some mpegs, as I reported at first time.
The good news is direct rendering is enabled
This causes problems when DRI and fb are loaded and you unload dri.. guess
what happens your fb??, or it does in theory I might have time to practice
later,
now the quick fix is to take the stealth/non-stealth code from CVS which
we know works or we wait for Alan to finish his vga device code and
Add pci_enable_device()/pci_disable_device. In the past, drivers often worked
without this, but it is now required in order to route PCI interrupts
correctly.
Evan Paul Fletcher found this problem with 2.6.9-rc1-mm4 and X.org 6.8.0
and verified that this patch fixes it.
Signed-off-by: Bjorn Helg
On Tuesday 14 September 2004 00:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
>
> fbdev only sets the mode on a single head. My cards have more that one
> head. When I tried adding mode setting to DRM so that I could handle
> my
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
It looks like the only way to tell the difference between the two
extensions is "!!ARBvp1.0" vs. "!!VP1.0" in the program text. I
suppose we could track the glVertexAttrib3fvARB as non-aliased, but
compile a !!VP1.0 pro
Hi,
the return value of drm_probe seems to be ignored when probing in
stealth mode. I saw a user logfile where it printed
[drm:drm_probe] *ERROR* Cannot initialize the agpgart module.
but apparently the driver continued loading. Should drm_init fail if
drm_probe returns something non-zero? Or am
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
It looks like the only way to tell the difference between the two
extensions is "!!ARBvp1.0" vs. "!!VP1.0" in the program text. I
suppose we could track the glVertexAttrib3fvARB as non-aliased, but
compile a !!VP1.0 program to use the attr
On Mon, 13 Sep 2004 13:42:19 -0700, David Bronaugh
<[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> >How would any of these plans handle power management and ACPI events?
> >I'd like to be able to suspect my laptop with the DRI enabled, or have
> >the DDX (or whatever) handle acpi lid and butt
On Mon, 13 Sep 2004 23:08:07 +0200, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Dieter Nützel wrote:
> > Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
> >
> >>I've updated the drm.watchdog.2.patch
> >>http://marc.theaimsgroup.com/?l=dri-devel&m=108551485018672&w=2
> >>to latest DRM
Hi,
while I've had less success (read: hard locks and reboots) with the recently
drmtest and r300_demo, I did use glxtest to find out registers of the R300.
Basically, what I did is run a small GL program, get the command buffer,
make some small changes and rerun. Often, this results in only a
Ian Romanick wrote:
Brian Paul wrote:
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes.
This conflicts with GL_NV_vertex_program and changes the policy
defined in GL_ARB_vertex_program (where aliasing was opti
On Mon, Sep 13, 2004 at 10:33:26PM +0200, Fionn Behrens wrote:
> What is the status on the M10 line of ATI GPUs (Mobility FireGL [T2]) so
> far? I am a happy new owner of a Notebook with this chip but the only way
> to enable DRI with this so far was the dreaded fglrx driver. Is trying CVS
> worth
Brian Paul wrote:
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes. This
conflicts with GL_NV_vertex_program and changes the policy defined in
GL_ARB_vertex_program (where aliasing was optional).
The GL_ARB_v
On Mon, 13 Sep 2004 16:41:06 -0400
Alex Deucher <[EMAIL PROTECTED]> wrote:
> On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> > On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > > How would any of these plans handle power management and ACPI events?
> > > I
Dieter Nützel wrote:
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-devel&m=108551485018672&w=2
to latest DRM CVS and it works together with
"ati.unlock.1.patch" and "ati.drm-r300-version.1.patch"
http://marc.thea
What is the status on the M10 line of ATI GPUs (Mobility FireGL [T2]) so
far? I am a happy new owner of a Notebook with this chip but the only way
to enable DRI with this so far was the dreaded fglrx driver. Is trying CVS
worth a shot for me or isnt anything here yet for this GPU?
br,
Fionn
On Monday 13 September 2004 04:41 pm, Alex Deucher wrote:
> On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> > On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > > How would any of these plans handle power management and ACPI events?
> > > I'd like to be able
Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
Since I've been doing a little b
On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > How would any of these plans handle power management and ACPI events?
> > I'd like to be able to suspect my laptop with the DRI enabled, or have
> > the DDX (o
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> How would any of these plans handle power management and ACPI events?
> I'd like to be able to suspect my laptop with the DRI enabled, or have
> the DDX (or whatever) handle acpi lid and button events or put the
> chip into various power m
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
> I've updated the drm.watchdog.2.patch
> http://marc.theaimsgroup.com/?l=dri-devel&m=108551485018672&w=2
> to latest DRM CVS and it works together with
> "ati.unlock.1.patch" and "ati.drm-r300-version.1.patch"
> http://marc.theaimsgroup.co
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes.
This conflicts with GL_NV_vertex_program and changes the policy
defined in GL_ARB_vertex_program (where aliasing was optional).
The GL_ARB_vertex_shader exten
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-devel&m=108551485018672&w=2
to latest DRM CVS and it works together with
"ati.unlock.1.patch" and "ati.drm-r300-version.1.patch"
http://marc.theaimsgroup.com/?l=dri-devel&m=108551675805810&w=2
when the UT2003/2004 lockups ('S
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus Torva
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
> The IA64 people want a file/ioctl interface on the /dev/vga0 devices
> so that they can issue control calls to the active device in each "VGA
> space"
I think ppc and sparc want this too, we'll use it for issuing legacy in/out.
Thanks,
Je
It wasn't intended to stay in the PCI layer. Something needs to be
done about hotplugging bridges. There aren't callouts from the PCI
layer for that. A hotplugged bridge can be capable of VGA routing and
have VGA devices behind it. I just started off in the PCI layer while
I figured out what hooks
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IR
How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.
So when a card gets hotplugged, which driver do I
On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
Already covered - although at the moment the question is open about who
tells the vga generic code "It has 4 heads" ?
Had a look over your class code - its
By the way i got a little question regarding ACPI. Does any one
is looking for this issue (i guess it is a drm issue) ? Maybe it
is a part of the on going work of drm restructuration.
What ACPI issue ? If you mean that you can't suspend, this is because the
video card loses its state so completely
On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
> On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dïnzer wrote:
> >
> > > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> > >>
> > >> I th
Doesn't the base platform need to be designed to also treat individual
heads as resources?
fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other heads there was a big uproar that fbdev owns mode setting
On Mon, 13 Sep 2004 10:54:50 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> >>
> >> Vladimir Dergachev
> >
> > I will look at all this as soon as i get back home :) I was doing
> > some research on this R300 stuff too but with little success.
> >
> > By the way
On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
>
> So, as Jon rightly points out the "multiple drivers" scheme only makes
> sense in the current usage patter - you either use X or framebuffer, never
> both at the same time and you consider a few seconds per switch normal.
You are
On Mon, 2004-09-13 at 08:30, Dieter Nützel wrote:
> Am Mittwoch, 8. September 2004 15:26 schrieb Roland Scheidegger:
> > Roland Scheidegger wrote:
> > > Dieter Nützel wrote:
> > >> Only some rejections in
> > >>
> > >> src/mesa/main/texcompress_s3tc.c
> > >
> > > I'll fix it, but you have to wait a
On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
> > It depends how the various components fit together. Clearly for Radeon
> > you want everyone using the DMA command path when DRI is loaded. That
> > doesn't require "one driver"
>
> Alan, do I understand right that you are proposing to hav
On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
> It also needs something to sort out both drivers using pci_drvdata()
> to get to their private data. For example in the hotplug routines you
> only get passed a pdev and you want to use that to locate your private
> data.
The hotplug routines for vga
Am Mittwoch, 8. September 2004 15:26 schrieb Roland Scheidegger:
> Roland Scheidegger wrote:
> > Dieter NÃtzel wrote:
> >> Only some rejections in
> >>
> >> src/mesa/main/texcompress_s3tc.c
> >
> > I'll fix it, but you have to wait at least another full week.
>
> Ok, new version can be found as usu
On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
>
> The overlay window is currently using part of what is being proposed by
> "multiple drivers" proponents. It has to make engine queiscent so it can
> write data directly to the video memory. It does *not* have to save the
> state.
It doesn't e
On Mon, 13 Sep 2004, Alan Cox wrote:
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers o
On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> Well this is what I came up with so far. It creates a vga class so you
> can bind the drivers to functions of the card (and we can add/remove
> functions later as appropriate), tells functions about each other and
> now imple
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
> However, if we want the switch from X to framebuffer to be as fast as
> switching between different text consoles (assuming they have the same
> resolution) and if we want to be able to run different Xservers on
> different consoles or Xse
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dänzer wrote:
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
Vladimir Dergachev
I will look at all this as soon as i get back home :) I was doing
some research on this R300 stuff too but with little success.
By the way i got a little question regarding ACPI. Does any one
is looking for this issue (i guess it is a drm issue) ? Maybe it
On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
> The worst things that will happen for all concerened is this:
> Jon does all this work on a merged solution outside the kernel, and it
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets push
>Hi all,
>
> I have made some moderate progress in getting R300 3d to play nicely,
>you can see the results at
>
> http://volodya-project.sf.net/R300.php
>
> So people with Radeon R300 or later cards that want to experiment with
>their powerful GPUs can try out the code and mess with it at the le
Jon Smirl wrote:
On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. ->quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1
48 matches
Mail list logo
