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=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Donnie Berkholz wrote:
> Bernardo Innocenti wrote:
>>>
>>>Is there a reason why this code is not appropriate for
>>>merging into the official DRM?
>
> You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943.
Thank you! I fetched the latest patch and it applied
quite nicely to t
> -fformat-extensions -std=c99 -c
> /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c
> /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function
> `radeon_set_pciegart':
> /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1246: warning:
> unsigned int format, dm
On Wednesday 22 June 2005 06:55 pm, Adam K Kirchhoff wrote:
> At one point in the not-too-distant past, the r300 drm would
> compile on FreeBSD 5.4.
>
> After bringing a Radeon 9550 home from work to test out and being
> really impressed with how well the driver works (without those
> pesky 9800 sp
At one point in the not-too-distant past, the r300 drm would compile on
FreeBSD 5.4.
After bringing a Radeon 9550 home from work to test out and being really
impressed with how well the driver works (without those pesky 9800
specific lockups), I decided to give it a whirl in FreeBSD.
Unfor
Jon Smirl wrote:
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
I'll add a new map type DRM_VSHM. When initializing, the chip specific
driver needs to do something like this:
if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
goto err_g1;
The map
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=3379
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Jon Smirl wrote:
2) How is a non-root drmAddMap for shared memory a bigger security risc
than shmget? I understand why SAREA containing the lock needs to be
permanent, but not subsequent ones. Why can't they be created on demand by
the master?
The memory being allocated by the drivers is
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> 1) How is allocating a second fixed sarea different from splitting the
> first SAREA in two parts? The problem is not space but future expandability
> and generality.
Both the DRM and driver sarea structs go into the first SHM. You can
use
Jon Smirl wrote:
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Hi.
Jon Smirl wrote:
On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
Second choice would be to make a new map type, DRM_VSHM. The specific
driver would initmap the needed space at load time. The co
On 6/22/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > Adding a new map type "so that you can tell them apart" doesn't make a
> > lot of sense to me. Won't two different maps have different offsets?
> > Isn't that enough to differentiate between them?
>
> Yes the offsets will be different. But how
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I'll add a new map type DRM_VSHM. When initializing, the chip specific
> > driver needs to do something like this:
> >
> > if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
> > goto err_g1;
> >
> > The map
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
>>Second choice would be to make a new map type, DRM_VSHM. The specific
>>driver would initmap the needed space at load time. The code
>>implementing it would be identical to DRM_SH
ins/rmmod of CVS radeon DRM is corrupting kernel memory when fbdev is
loaded. Core DRM is ok.
You don't see the problem until you rmmod the radeon module. Then
after a few seconds the kernel will sometimes report slab corruption.
Memory is probably always corrupted but the kernel doesn't always fi
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Jon Smirl wrote:
> On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
>
> Second choice would be to make a new map type, DRM_VSHM. The specific
> driver would initmap the needed space at load time. The code
> implementing
On 6/21/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
> On Sat, 18 Jun 2005 22:18:43 +0200
> Jerome Glisse <[EMAIL PROTECTED]> wrote:
>
> > On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > On Saturday 18 June 2005 13:38, Jerome Glisse wrote:
> > > > On 6/18/05, Vladimir Dergachev <[EMAIL PR
Hi,
I've been having a problem with text rendering in opengl applications
recently, I've searched the list but haven't seen this anywhere. First, my
setup is a Radeon Mobility 9000 on a 2.6.12 kernel with a testing/unstable
Debian environment and I normally compile Xorg, Mesa and the drm
On Tue, 2005-06-21 at 16:44 +0200, Johannes Berg wrote:
> Jerome Glisse wrote:
>
> >I can remember from the top of my head but there is maybe some patch
> >that could be revealent for ppc not included in this snapshot. Thus i think
> >you should consider trying building xorg from cvs. Anyway with
Eric Anholt wrote:
On Wed, 2005-06-22 at 02:48 +0100, Dave Airlie wrote:
After talking with Ben a few days back, I'm getting the idea we are going
to need a user-space server process that does all of this, call it 0
(zero) as X-X = 0, this 0 process is started by init and has card specific
lo
> >
> > Eventually yes, but that VHA stuff sets a load of registers in indirect
> > buffer, fills up an indirect buffer and sends it the card... to do this
> > without indirect buffers would require a fair lot of sending commands
> > between blocks to make sure the card is back in a known state ...
Hi.
Jon Smirl wrote:
On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
Second choice would be to make a new map type, DRM_VSHM. The specific
driver would initmap the needed space at load time. The code
implementing it would be identical to DRM_SHM, you just need another
map type de
21 matches
Mail list logo
