On Thu, Sep 09, 2004 at 06:48:59PM -0600, Brian Paul wrote:
José Fonseca wrote:
Hi,
Doxygen documentation of DRM and Mesa is generated every night from CVS
into http://freedesktop.org/~dri/doxygen/ .
Enjoy,
Thanks, José. I added new sections for the glapi and shader modules
and
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 07:09 ---
hi,
I've
That is expected behavior. Without vesa the savage driver can take
complete control of the hardware and mark everything in use.
With vesa loaded the DRM driver will detect that it is loaded and
switch into stealth mode. In stealth mode DRM uses all of the
resources without telling the kernel. It
-- Forwarded message --
From: Mihai Rusu [EMAIL PROTECTED]
Date: Fri, 10 Sep 2004 10:33:44 +0300 (EEST)
Subject: DRM X.Org 6.8.0 oops
To: LKML [EMAIL PROTECTED]
Hi
There seems to be some DRM problem with X.Org 6.8.0 on 2.6.8.1. I recently
switched from XFree86 and there I did
You need to use the i915 kernel module, not the i830 one.
On Fri, 10 Sep 2004 11:13:30 -0400, Jon Smirl [EMAIL PROTECTED] wrote:
-- Forwarded message --
From: Mihai Rusu [EMAIL PROTECTED]
Date: Fri, 10 Sep 2004 10:33:44 +0300 (EEST)
Subject: DRM X.Org 6.8.0 oops
To: LKML
On Gwe, 2004-09-10 at 16:11, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load it separately.
Your personal plan.
On Fri, 10 Sep 2004 16:14:38 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 16:11, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load it
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=729
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 06:23 ---
I have this
On Fri, 10 Sep 2004 17:00:33 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 17:37, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load
Hi all ,
I've posted for AA few days ago, and I'm here again :)
Now the problem is with UT2004 .
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've downloaded the demo , and the game seemed to run fine at
least until I tried to
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
My personal plan has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various aspects of the plan were
Addressed and eliminated would be closer. The
PS: Don't get me wrong - we have to address the main points on that list
(the ones on the list not in your head). The last thing I want to see is
another person march off into the distance with a framebuffer agenda and
a lack of understanding about the importance of getting
from where we are now
What became of the proposal of making fb a DRM client
that I saw on dri-devel some time ago?
It sounded like a good idea to me.
Philipp
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod
On Fri, 10 Sep 2004 18:04:19 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
My personal plan has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various
I tested your patch with Savage, without VesaFB:
# cat /proc/iomem
...
d000-d7ff : PCI Bus #01
d000-d7ff : :01:00.0
d000-d7ff : savage
...
dc00-ddff : PCI Bus #01
dd00-dd07 : :01:00.0
dd00-dd07 : savage
...
On my notebook, where
drm.h should be located in /include/linux/ or /include/video instead
of /drivers/char/drm. The code for sharing the DRM major number with
the VGA device needs to pick some constants up out of drm.h. Can we
move it in the next kernel drop?
--
Jon Smirl
[EMAIL PROTECTED]
No changes in the code, it's just regenerated against current DRM CVS.
--
Jon Smirl
[EMAIL PROTECTED]
= linux/drmP.h 1.11 vs edited =
--- 1.11/linux/drmP.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drmP.h Fri Sep 10 17:09:37 2004
@@ -56,6 +56,7 @@
#include linux/smp_lock.h /* For
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 05:59 ---
I have a
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1195
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 15:10 ---
Created an
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1195
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 15:14 ---
Created an
You are focusing on the resource claiming problem. That is an easy
problem to solve, it's also not the one that is causing the hard
problems.
I have to agree with Jon, nobody has addressed any of the issues he raises
except the one that is quite simple to solve, resource sharing is easy,
I
drm.h should be located in /include/linux/ or /include/video instead
of /drivers/char/drm. The code for sharing the DRM major number with
the VGA device needs to pick some constants up out of drm.h. Can we
move it in the next kernel drop?
It should probaly be in include/linux alright, but
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same
On Gwe, 2004-09-10 at 14:31, Felix Khling wrote:
The first region (frame buffer and apperture) is claimed (partially) by
vesafb, the second one (MMIO registers) is not claimed at all. I don't
see an obvious way to fix this.
Its already fixed in the stuff I'm working on. Given the list of all
On Gwe, 2004-09-10 at 22:56, Jon Smirl wrote:
drm.h should be located in /include/linux/ or /include/video instead
of /drivers/char/drm. The code for sharing the DRM major number with
the VGA device needs to pick some constants up out of drm.h. Can we
move it in the next kernel drop?
Ughhh.
On Gwe, 2004-09-10 at 22:30, Jon Smirl wrote:
No changes in the code, it's just regenerated against current DRM CVS
- drm_probe(pdev, DRM(pciidlist[i]));
+ DRM(probe)(pdev, DRM(pciidlist[i]));
Seems to revert macro clean up work.
+
On Sad, 2004-09-11 at 00:10, Jon Smirl wrote:
I'm counting on Ian to provide the memory management code. I haven't
even looked at it very much. The point is simply that we have to have
something, you just can't support multiple heads without minimal
memory management and fbdev doesn't
I need a major number for the VGA device. I used
register_chrdev_region() to free up some space from DRM. First 512
minors are assigned to DRM then I need a few starting at 226,512 for
vga devices. I could use dynamic majors for the VGA device but that
would mean that everyone needs udev and you
2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not more so.
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most cards have two
inter_module can't be removed until we move to the drm_core design
with personality modules. inter_module has always been in DRM and I
believe DRM is the only current user. I'm all for switching to the
drm_core design as soon as we can convince everyone to do it.
The DRM(probe) macro is there
On Gwe, 2004-09-10 at 19:19, Philipp Klaus Krause wrote:
What became of the proposal of making fb a DRM client
that I saw on dri-devel some time ago?
It sounded like a good idea to me.
That falls out from just about all sane and non-sane ways of
tackling the problem. Its essentially a freebie
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=814
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 06:31 ---
Same
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone
We've addressed this before. Zillions of drivers provide multiple
functions to multiple higher level subsystems. They don't all have to
be compiled together to make it work.
2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not
The current DRM code doesn't suffer from resource conflicts anymore.
DRM now supports two modes: primary and stealth. In primary mode DRM
behaves like a Linux device driver should, it attaches to it's PCI
IDs, claims it's resources, registers with sysfs, generates hotplug
events, etc.
On the
You're probably right, but it still doesn't follow that this driver must
include all the fbdev and DRM code as well. Both fbdev and the DRM could
use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
I think your wrong, look at drivers/video/aty/radeon* and tell me what in
36 matches
Mail list logo
