On Wed, 29 Jun 2005, Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
current CVS xorg, CVS Mesa and the tagged r300 driver
'the_perfect_frag') it all works,
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://bugs.freedesktop.org/show_bug.cgi?id=3398
[EMAIL PROTECTED] changed:
What|Removed |Added
--
On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are
> > marked differently it is way for my driver to tell AGP from PCI cards.
>
> I would advise against that. There are (rare) cases where user-mode
> wants to select AGP par
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hamish Marson wrote:
> Just as a status report...
>
> On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
> current CVS xorg, CVS Mesa and the tagged r300 driver
> 'the_perfect_frag') it all works, 1600fps on glxgears, but the
> flickeri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
current CVS xorg, CVS Mesa and the tagged r300 driver
'the_perfect_frag') it all works, 1600fps on glxgears, but the
flickering is awful on OpenGL apps...
(C
At one point I had all of the drm drivers working off from a single
set of defines in drm.h. Now it appears that most of the structures
and defines are duplicated in xf86drm.h, but the first thing xf86drm.h
does is include drm.h. All of the symbols are differentiated with a
underscore.
What this d
On Tue, 2005-06-28 at 20:13 -0400, Jon Smirl wrote:
> On 6/28/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > > The callgate for getting to mode setting has to be in the kernel. That
> > > provides a standard API and a secure user-root transition. After the
> > > call is in the kerne
On 6/28/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > The callgate for getting to mode setting has to be in the kernel. That
> > provides a standard API and a secure user-root transition. After the
> > call is in the kernel each driver can choose to satisfy the call
> > in-kernel or
> The callgate for getting to mode setting has to be in the kernel. That
> provides a standard API and a secure user-root transition. After the
> call is in the kernel each driver can choose to satisfy the call
> in-kernel or use something like call_userhelper() to do the work in
> user space.
As
>
> Looks like that Dave Airlie has pushed another set of patches
> made by Paul Mackerras into the DRM code.
> My patches support a wider range of chipsets (Matrox, R128 and Radeon)
> and provide a framework which makes it easy to add ioctl32 support
> to more chipsets.
> Furthermore they have su
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://bugs.freedesktop.org/show_bug.cgi?id=3259
[EMAIL PROTECTED] changed:
What|Removed |Added
--
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://bugs.freedesktop.org/show_bug.cgi?id=3248
[EMAIL PROTECTED] changed:
What|Removed |Added
--
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://bugs.freedesktop.org/show_bug.cgi?id=3259
Bug 3259 depends on bug 3248, which changed state.
Bug 3248 Summary: MGA driver fail
list = drm_alloc(sizeof(*list), DRM_MEM_MAPS);
memset(list, 0, sizeof(*list));
same as drm_calloc()
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simpl
This ...
if (found_map->size != map->size) {
DRM_DEBUG("Matching maps of type %d with "
"mismatched sizes, (%ld vs %ld)\n",
map->type, map->size, found_map->size);
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://bugs.freedesktop.org/show_bug.cgi?id=3613
--- Additional Comments From [EMAIL PROTECTED] 2005-06-28 14:38 ---
I tri
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> You got me wrong. Item 2 above states that the device specific code
> specifies the number of possible SAREAS and their sizes to main DRM as
> part of its initialization.
>
> typically for two sareas something like
>
> static uint32_t via_
These should be inlines in an h file. There people on lkml that will
complain about unneeded symbol exports.
unsigned long drm_get_resource_start(drm_device_t *dev, unsigned int resource)
{
return pci_resource_start(dev->pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_start);
unsigned l
Jon Smirl wrote:
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Having thought a bit more about the SAREA problem, I'd like to see the
following solution:
1) AddMap returns an error if the flag CONTAINS_LOCK is not set. The
first SAREA otherwise for
backwards compatibility.
2) The
You can make AddMap simpler by using a stack based drm_map_t and then
allocating the real one at the end. It lets you remove all of the
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
This should be done at the very end after all of the error returns:
if (drm_core_has_MTRR(dev)) {
On 6/28/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> I've just committed the previous diff, with the move to presetup. I'm
> now looking at 2 things:
> - Cleaning up driver hooks as previously described, so I can propose a
> patch for it.
> - Getting BSD working again. I think this is going to re
On Tue, 2005-06-28 at 16:36 -0400, Jon Smirl wrote:
> On 6/28/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-06-28 at 16:22 -0400, Jon Smirl wrote:
> > > This fixes so that my egl driver will get started. You probably need
> > > to test it further.
> > >
> > > You are creating the maps
On 6/28/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-06-28 at 16:22 -0400, Jon Smirl wrote:
> > This fixes so that my egl driver will get started. You probably need
> > to test it further.
> >
> > You are creating the maps in radeon_preinit and it only gets called
> > once at driver lo
On Tue, 2005-06-28 at 16:22 -0400, Jon Smirl wrote:
> This fixes so that my egl driver will get started. You probably need
> to test it further.
>
> You are creating the maps in radeon_preinit and it only gets called
> once at driver load time. Map creation needs to be moved over to the
> open_hel
This fixes so that my egl driver will get started. You probably need
to test it further.
You are creating the maps in radeon_preinit and it only gets called
once at driver load time. Map creation needs to be moved over to the
open_help function so they will get rebuilt each time.
--
Jon Smirl
[E
On Tue, 2005-06-28 at 15:17 -0400, Jon Smirl wrote:
> I don't think the radeon driver works at all with this patch,
>
> [drm] Initialized drm 1.0.0 20040925
> [drm:drm_init]
> [drm:drm_get_dev]
> [drm:drm_addmap] offset = 0xfe9e, size = 0x0001, type = 1
> [drm:drm_addmap] offset = 0xf4
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://bugs.freedesktop.org/show_bug.cgi?id=3378
[EMAIL PROTECTED] changed:
What|Removed |Added
--
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://bugs.freedesktop.org/show_bug.cgi?id=3377
[EMAIL PROTECTED] changed:
What|Removed |Added
--
I don't think the radeon driver works at all with this patch,
[drm] Initialized drm 1.0.0 20040925
[drm:drm_init]
[drm:drm_get_dev]
[drm:drm_addmap] offset = 0xfe9e, size = 0x0001, type = 1
[drm:drm_addmap] offset = 0xf400, size = 0x0400, type = 0
Maps are added in radeon_preinit
Alan Hourihane writes:
> On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote:
> >
> > >
> > > I was just a little perplexed (as I'm sure Egbert was too) that the bug
> > > #943
> > > hadn't been updated by Paul and all of a sudden it appears in the kernel
> > > first without being
Dave Airlie writes:
>
> >
> > I was just a little perplexed (as I'm sure Egbert was too) that the bug
> > #943
> > hadn't been updated by Paul and all of a sudden it appears in the kernel
> > first without being in the DRM CVS for at least a little while to get
> > tested here.
>
> Paul
Dave Airlie writes:
>
> > >
> > > I've started pushing the kernel bits to the kernel from Paulus, Linus has
> > > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
> > > r128 and whatever other bits are in Egberts patch...
> >
> > If this stuff is in the kernel, hasn
On 6/28/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Smirl wrote:
> > From what I can tell vesafb use is pretty rare. A while ago I broke
> > things in DRM CVS so that vesafb wouldn't work, it was about two
> > months until we got a compl
Dave Airlie writes:
>
> I've started pushing the kernel bits to the kernel from Paulus, Linus has
> accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
> r128 and whatever other bits are in Egberts patch...
I have solved the map->handle issue differently in my code.
Also
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Having thought a bit more about the SAREA problem, I'd like to see the
> following solution:
>
> 1) AddMap returns an error if the flag CONTAINS_LOCK is not set. The
> first SAREA otherwise for
> backwards compatibility.
> 2) The device-spe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> From what I can tell vesafb use is pretty rare. A while ago I broke
> things in DRM CVS so that vesafb wouldn't work, it was about two
> months until we got a complaint. DRM CVS is fixed for vesafb but the
> long lag indicates that t
Hi!
Some comments for current implementations of VIA chipsets:
Jon Smirl wrote:
We should discuss the design of DRM maps so that we don't work at
cross purposes.
The register map should be marked read only or root only. I don't need
access to the register map.
A lot of syncing is done usi
DRM_ERROR("Offset failed range check (reg=%04x
sz=%d)\n", reg, sz);
To me it looks perfectly fine - we have a for cycle, a switch statement
inside and an error check in one of switch statement clauses.
It looked perfectly fine when you sent it. It doesn't look fine by
th
On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > 1) Should the maps be created once at driver load time or on
> > open/close? I can probably make the egl drivers work either way.
>
> I did it at neither time in the MGA driver. When I added support there
> for PCI cards, I added a DMA boot-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
> On Mon, 2005-06-27 at 12:13 -0700, Ian Romanick wrote:
>
>>Does this maintain the 256-byte alignment requirement for the WARP
>>microcode?
>
> Addmap aligns to the same size as the allocation itself. I just assumed
> that the wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> We should discuss the design of DRM maps so that we don't work at
> cross purposes.
>
> I have a new requirement coming from the egl-driver work that my user
> space driver does not have root priv so it can't create the maps. This
>
We should discuss the design of DRM maps so that we don't work at
cross purposes.
I have a new requirement coming from the egl-driver work that my user
space driver does not have root priv so it can't create the maps. This
implies that the drivers need to pre-create the maps.
To access the maps I
Alan Hourihane writes:
> On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote:
> >
> > > Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
> > > support? 64bit applications are working fine, but 32bit apps always
> > > use software rendering on my machine (Radeon 750
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote:
>
> >
> > I was just a little perplexed (as I'm sure Egbert was too) that the bug #943
> > hadn't been updated by Paul and all of a sudden it appears in the kernel
> > first without being in the DRM CVS for at least a little while to get
>
> I was just a little perplexed (as I'm sure Egbert was too) that the bug #943
> hadn't been updated by Paul and all of a sudden it appears in the kernel
> first without being in the DRM CVS for at least a little while to get
> tested here.
Paul and Egbert discussed it on the bug at the time Pa
On 6/28/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> >
> > I can also predict the probable outcome on kernel submission if we use
> > the stub to start building suspend/resume in two different places -
> > DRM and fbdev.
>
> My stub isn't your totally fb in the stub, we are only going to put
>
On Tue, Jun 28, 2005 at 02:02:39PM +0100, Dave Airlie wrote:
>
> > >
> > > I've started pushing the kernel bits to the kernel from Paulus, Linus has
> > > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
> > > r128 and whatever other bits are in Egberts patch...
> >
> > If
> >
> > I've started pushing the kernel bits to the kernel from Paulus, Linus has
> > accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
> > r128 and whatever other bits are in Egberts patch...
>
> If this stuff is in the kernel, hasn't it been committed to the DRM CVS ??
M
>
> I can also predict the probable outcome on kernel submission if we use
> the stub to start building suspend/resume in two different places -
> DRM and fbdev.
My stub isn't your totally fb in the stub, we are only going to put
initially interrupt handling, suspend/resume, PCI driver handling a
On 6/28/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > > Is anyone working on a stub driver ??
> >
> > While you wait on the great stub debate to be settled (it has been
> > going on for about 18 months with no action) why not simply fix
> > intelfb to work right on the i915?
>
> I've said this
On Tue, Jun 28, 2005 at 01:16:14PM +0100, Dave Airlie wrote:
>
> > > bugzilla 943 on bugs.freedesktopp.org
> > >
> > > Egbert is hoping to look at it again, I keep getting hopelessly lost in
> > > types when I start looking at it.. I don't have the hardware to test it
> > > on...
> >
> > Egbert's
On 6/27/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > You could be a pioneer and write the first stub driver. I've looked at
> > the problem and you need about 80% of the fbdev code in the stub. I
> > just didn't think it was worth the engineering effort to split 20
> > existing fbdev d
> > bugzilla 943 on bugs.freedesktopp.org
> >
> > Egbert is hoping to look at it again, I keep getting hopelessly lost in
> > types when I start looking at it.. I don't have the hardware to test it
> > on...
>
> Egbert's patch has been updated and it's looking good.
>
> I'd suggest committing it t
> > Is anyone working on a stub driver ??
>
> While you wait on the great stub debate to be settled (it has been
> going on for about 18 months with no action) why not simply fix
> intelfb to work right on the i915?
I've said this before I think, but intelfb is very broken, apart from the
fact it
On 6/28/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> O.k. I've yanked the code from CVS for this now, as I don't want to pollute
> things if they're not going to work properly.
>
> Is anyone working on a stub driver ??
While you wait on the great stub debate to be settled (it has been
going on
On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote:
>
> > Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
> > support? 64bit applications are working fine, but 32bit apps always
> > use software rendering on my machine (Radeon 7500).
> > It looks like an kernel issue.
On Tue, Jun 28, 2005 at 12:09:52PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2005-06-24 at 09:58 -0400, Jon Smirl wrote:
> > On 6/24/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > I'm update with your changes this morning. I'm still seeing this at
> > > system shutdown. I modprobe drm,radeon 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://bugs.freedesktop.org/show_bug.cgi?id=3613
--- Additional Comments From [EMAIL PROTECTED] 2005-06-28 00:33 ---
O.k,
58 matches
Mail list logo
