On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote:
> On Fri, 2003-02-14 at 14:52, Martin Spott wrote:
> > Where did you take the DRM sources from ? I usually take the source for the
> > DRM module from the same DRI CVS tree I use to build the whole DRI thing,
>
> Mike Harris builds in Red
On Tue, 18 Feb 2003 14:56:04 +0100
Martin Spott <[EMAIL PROTECTED]> wrote:
>
> It appears to me that the kernel modules of Mike's build do not differ from
> XFree86 4.2.99.901 - at least he didn't include any additional patches
> that thouch the kernel modules. I have the impression he also did n
> How can get a new module? Do I have to build XF86 from source
No, you don't have to rebuild the whole XFree86. I usually take the Sources
from:
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/
xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/
and adjust the Makefile
On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
> As I was doing some minor cleanups in the mach64 drm in the new branch, I
> made some additional search and replace conversions of the mach64 DRM to
> the os independence macros (I couldn't restrain myself ;) ). However, I
> want to sh
On Tue, 18 Feb 2003, Martin Spott wrote:
> On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote:
> > On Fri, 2003-02-14 at 14:52, Martin Spott wrote:
>
> > > Where did you take the DRM sources from ? I usually take the source for the
> > > DRM module from the same DRI CVS tree I use to build
On Tue, Feb 18, 2003 at 02:34:29PM -0500, Leif Delgass wrote:
> On Tue, 18 Feb 2003, Martin Spott wrote:
> > So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ?
> I noticed that Michel's fix for large textures in
> radeon_cp_dispatch_texture() has only been in XFree86 cvs since
Michel Dänzer wrote:
On Mon, 2003-02-17 at 22:44, AnonimoVeneziano wrote:
Ian Romanick wrote:
The texmem-0-0-1 branch is a separate branch within DRI CVS. You
would check that branch out by doing:
[...]
MMM, the modules in this snap shot does not compile. The Makefile.linux
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?
Any comments anyone?
=
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.
--Arn
On Tue, 18 Feb 2003, [iso-8859-15] José Fonseca wrote:
> On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
> > As I was doing some minor cleanups in the mach64 drm in the new branch, I
> > made some additional search and replace conversions of the mach64 DRM to
> > the os independence
On Tue, 18 Feb 2003, Leif Delgass wrote:
> > My memory is failing: this might still be usefull for Xv, isn't it?
>
> Maybe, maybe not. DMA for XVideo seems to be of questionable value,
> judging from the Rage 128 driver. Plus the fact that you have to
> wait/sync when switching between GUI mast
verify_area performs any checks needed for it to be safe to use the _copy forms of
copy_*_user.
What that does varies. The normal Linux approach is
verify_area does access_ok which checks the address is a kernel view of a user space
address. _copy* functions use the MMU to fault any illegal acce
On 19 Feb 2003, Alan Cox wrote:
>
> copy_from_user sorts out the whole thing itself. In general __copy_from_user and
>verify_area
> isnt a win, except if you do lots of small copies to/from the same area, which is
>often
> a bad idea anyway.
It _can_ be a good idea, though.
In particular, it'
On Wed, Feb 19, 2003 at 01:50:49AM +, Alan Cox wrote:
>
> verify_area performs any checks needed for it to be safe to use the
> _copy forms of copy_*_user. What that does varies. The normal Linux
> approach is
>
> verify_area does access_ok which checks the address is a kernel view
> of a us
On Wed, 2003-02-19 at 01:48, José Fonseca wrote:
> I think our case is one of the exceptions: we are copying from the user
> and verifying the data at the same time (to avoid the user sending
> malicious commands to the card's DMA engine which could potentialy
> compromise the system integrity and
On Die, 2003-02-18 at 22:21, AnonimoVeneziano wrote:
> Michel Dänzer wrote:
>
> >On Mon, 2003-02-17 at 22:44, AnonimoVeneziano wrote:
> >
> >>Ian Romanick wrote:
> >>
> >>>The texmem-0-0-1 branch is a separate branch within DRI CVS. You
> >>>would check that branch out by doing:
> >
> >[...]
> >
On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote:
> I also made some other changes to the copy/verify:
>
> I added a check to the ioctl handler (mach64_dma_vertex) to check that the
> vertex buffer has an integral number of dwords (in addition to the check
> against MACH64_BUFFER_SIZE
On Tue, 18 Feb 2003, Martin Spott wrote:
>> > Where did you take the DRM sources from ? I usually take the source for the
>> > DRM module from the same DRI CVS tree I use to build the whole DRI thing,
>>
>> Mike Harris builds in Red Hat beta and in rawhide
>
>It appears to me that the kernel modu
On Tue, 18 Feb 2003, Linus Torvalds wrote:
>
> On 19 Feb 2003, Alan Cox wrote:
> >
> > copy_from_user sorts out the whole thing itself. In general
> > __copy_from_user and verify_area isnt a win, except if you do lots of
> > small copies to/from the same area, which is often a bad idea anyway.
>
On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote:
> On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote:
> > I also made some other changes to the copy/verify:
> >
> > I added a check to the ioctl handler (mach64_dma_vertex) to check that the
> > vertex buffer has an integral numbe
19 matches
Mail list logo
