Do you have this fix?
= linux/drm_scatter.h 1.6 vs edited =
--- 1.6/linux/drm_scatter.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_scatter.h Thu Sep 16 01:11:13 2004
@@ -73,7 +73,7 @@
DRM_DEBUG( "%s\n", __FUNCTION__ );
- if (drm_core_check_feature(dev, DRIVER_SG))
+
Hi Felix!
Monday 20, at 02:11:17 AM you wrote:
> On Sun, 19 Sep 2004 17:27:02 -0400
> Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > That should be >= in the patch not <=. The requested size needs to be
> > smaller than the permanent map size.
>
> That's not enough. You also need to change DRM(mma
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Sep 2004 12:46:13 -0400
> Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> > > One issue here... When we discussed all of this with Keith, we
> wanted
>
I've been talking to the I2C people about the right way to solve this
for the code in radeon_probe_i2c_connector(). This should be solvable
in the I2C framework by writing an EDID driver that implements the
code in it's attach_adapter/detach_adapter functions. What I2C is
missing is a way to tell
CVS server appears to be dead. I'll try again later.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your p
Your patch is correct. I was focusing on the I2C changes and didn't
check in all of the addmap parts. I'll check this is as soon as get
back to my dev machine.
On Mon, 20 Sep 2004 02:11:17 +0200, Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Sep 2004 17:27:02 -0400
> Jon Smirl <[EMAIL PRO
On Mon, 2004-09-20 at 02:46, Jon Smirl wrote:
> This is going to require some more thought. Mode setting needs two
> things, a description of the mode timings and a location of the scan
> out buffer. With multiple heads you can't just assume that the buffer
> starts at zero. There also the probl
On Mon, 2004-09-20 at 02:12, Jon Smirl wrote:
> The radeon driver has that extra code for intializing older DDC. That
> can be handled generically in the I2C layer by writing a ddc driver
> that is a superset of the eeprom driver. I'd rather get that code
> into a generic driver than repeat it in
On Sun, 19 Sep 2004 17:27:02 -0400
Jon Smirl <[EMAIL PROTECTED]> wrote:
> That should be >= in the patch not <=. The requested size needs to be
> smaller than the permanent map size.
That's not enough. You also need to change DRM(mmap), otherwise DRI
clients will fail to mmap the frame buffer. T
the one in Linus bk tree shouldn't be broken, he pulled up all my fixes
2-3 days ago...
Dave.
On Sun, 19 Sep 2004, Jon Smirl wrote:
> Where are you getting your DRM driver? The one in the Linux BK tree is
> broken. Use DRM CVS instead.
>
>
--
David Airlie, Software Engineer
http://www.skynet.
That should be >= in the patch not <=. The requested size needs to be
smaller than the permanent map size.
On Sun, 19 Sep 2004 17:24:36 -0400, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Does this fix it? I won't be on my development machine to test it for
> a few more hours.
>
>
>
> --
> Jon Smir
Does this fix it? I won't be on my development machine to test it for
a few more hours.
--
Jon Smirl
[EMAIL PROTECTED]
patch
Description: Binary data
Hi Jon!
Sunday 19, at 03:35:13 PM you wrote:
> Where are you getting your DRM driver? The one in the Linux BK tree is
> broken. Use DRM CVS instead.
>
I get the same problem (unworking dri) with lastest snapshots (20040919
and 20040918). BTW simple diff of current DRM tree shows th
On Sun, 19 Sep 2004 12:46:13 -0400
Jon Smirl <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > One issue here... When we discussed all of this with Keith, we wanted
> > a mecanism where the user can set the mode without "owning
Around 12 o'clock on Sep 19, Jon Smirl wrote:
> This is going to require some more thought. Mode setting needs two
> things, a description of the mode timings and a location of the scan
> out buffer. With multiple heads you can't just assume that the buffer
> starts at zero. There also the prob
Where are you getting your DRM driver? The one in the Linux BK tree is
broken. Use DRM CVS instead.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod M
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > Typically, with X: We don't want X itself to have to be the one
> setting
> > the mode, but rather set the mode and have X be notified properly
> before
> > and a
On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> One issue here... When we discussed all of this with Keith, we wanted
> a mecanism where the user can set the mode without "owning" the device.
The owning part is for multiuser systems. If I have four users log
On Sun, 19 Sep 2004 14:48:38 +1000, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Sun, 2004-09-19 at 08:12, Jon Smirl wrote:
>
> > I'm still undecided if there needs to be a root priv daemon caching
> > the EDID and polling for a monitor change. EDID can be regenerated on
> > each request
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> You did that from an xterm, right? Which console device is the xterm
> running on?
>
> X starts up a process that knows which device it is running and it can
> remember that device since X stays running.
>
Remember X opens the VC sepratly from it's con
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> Isn't there an enviroment variable that tells what device is the
> console for the session? How do you tell what serial port you're on
> when multiple people are logged in on serial lines?
>
The FDs 0, 1 and posibly 2 will be the console. Per posix? T
yeah we'll need to implement a msleep_interruptible in drm_compat.h if we
are running on a kernel which doesn't have it ...
drm_os_linux.h also has a schedule_timeout, that i830_wait_irq function
looks a bit bogus to me .. not sure it shouldnt look like some of the
others...
Dave.
On Sat, 18 Se
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying "save the state at the next unlock," which means
memcpying the state atoms off. When we actually see the context get
lost, then we "back up"
On Sun, 19 Sep 2004 10:59:25 +0200, Marcello Maggioni <[EMAIL PROTECTED]> wrote:
> I've finally done it :)
>
> It was quite difficult , the rendering speed was too slow and I
> couldn't reproduce the freeze with that speed (the game took hours to
> load into a stage ) .
>
> So I had to enable NM
On Sun, 12 Sep 2004 22:00:45 +0200, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
>
>
> Marcello Maggioni wrote:
> > On Sun, 12 Sep 2004 00:34:01 +0200, Roland Scheidegger
> > <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>Marcello Maggioni wrote:
> >>
> My card is a 3D prophet Radeon 8500LE with R2
Using the 09-18-2004 radeon snapshots I receive the following error. I've been looking for more information on this error and not really getting anywhere. I have a 07--27-2004 build which I do have working but this latest one is no go. I'm using a fedora core 2 system with a 2.6.6 stock kern
26 matches
Mail list logo
