Just a suggestion that comes to mind as I'm crawling through the
kernel-level code...
[the xfree 4.2.0 version]
but it looks to me like if userland passes in an incorrect context number
in a call to DRM_IOCTL_LOCK, it could cause a kernel panic, due to
no array bounds checking in
drm_drv.h,
Sorry, sorry.. missed seeing the bounds check, even though its right there.
It's late where I am, and it's been a long day.
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice that the structure is quite similar to Ians texmem
design. This is the first
dri-devel,
nwjbefeyfdl
[EMAIL PROTECTED]nwjbefeyfdldri-devel
+wzf¢+,¦ì¢·o$¥Év+HÀÞ½éh¥©Þv
騲×(Þ
éì÷×å{ç(uçÚ+Êj{¬x* yö¬µêÂü/¾¯htÌ-s
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the lightweight
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
the lightweight lock will not
On Tue, Feb 18, 2003 at 09:58:41PM -0500, Leif Delgass wrote:
On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote:
It's now official: I'm coding on this. I'm adding the _ioctl suffix to
most IOCTLs (e.g., agp_alloc - agp_alloc_ioctl) to leave to the
agp_alloc for internal DRM usage, and
On Die, 2003-02-18 at 22:37, Michael Mazack wrote:
IIRC, your log file that you attached a few days ago
said that the mga hal could not be found.
Perhaps this has something to do with your problem?
I doubt it. All the OpenGL code is in mga_dri.so.
--
Earthling Michel Dänzer (MrCooper)/
Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the lightweight
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
the
Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the lightweight
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
the
---BeginMessage---
On Die, 2003-02-18 at 22:37, Michael Mazack wrote:
IIRC, your log file that you attached a few days ago
said that the mga hal could not be found.
Perhaps this has something to do with your problem?
I doubt it. All the OpenGL code is in mga_dri.so.
--
Earthling
Ok, I have to correct myself , this drivers have many bugs, now all
the open GL utilities have textures corruptions . I think that this
drivers are very immature at this time, but seems to reach their goal.
Bye
---
This SF.net email is
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least on
hic-up when trying to test UT2k3 with 'LIBGL_ALWAYS_INDIRECT=y'.
I realize that
Another thing, if I install only the DRM module in the cvs tree the
textures don't seems to be corrupted and the problems in vendetta are
solved, but the system freeze up in 10-20 seconds. Only the reset button
can do something
Bye
---
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least on
hic-up when trying to test UT2k3 with
Ian, this commit includes references to rmesa-hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time to
investigate the problems yet, but most of the code looks to be identical
to
Leif Delgass wrote:
Ian, this commit includes references to rmesa-hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time to
investigate the problems yet, but most of the code looks
Brian Paul wrote:
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least
on hic-up when trying to test UT2k3 with
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported
I mean that they are not listed by GL_EXTENSIONS. This caused at
least on hic-up when trying
On Wed, 19 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Ian, this commit includes references to rmesa-hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time to
Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice that the structure is quite similar to Ians texmem
On Wed, 19 Feb 2003, Brian Paul wrote:
Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice
21 matches
Mail list logo
