Re: No DRM kernel support for i830 ?
On Wed, 2004-08-11 at 13:01, Charles Sprickman wrote: On Wed, 11 Aug 2004, John Baldwin wrote: The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head because of a security problem with the code. Just out of curiousity, does this support the original i810 chipset? ie: agp0: Intel 82810E (i810E GMCH) SVGA controller mem 0xff00-0xff07,0xf400-0xf7ff irq 9 at device 1.0 on pci0 No, it doesnt. Actually, the Intel driver going forward currently is the i915 driver, which is going to be in the next X.Org release, is apparently secure, is ported to FreeBSD (untested iirc -- I'm setting up a machine now), and supports i830-i915. There's been a suggestion that i915 could be extended to support i810 as well, which would deal with the security model issues that I suspect are the same on i810 as i830. That would be the hardest but perhaps best option. The alternate route is to just port the i810 driver as-is. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 2003-12-21 at 12:08, Daniel Eischen wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? From what I understand, having thread-local variables would be a big bonus for OpenGL. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Matrox Parhelia XFree86 Busmastering kernel module?
On Sat, 2003-10-11 at 19:56, Igor Pokrovsky wrote: On Thu, Oct 09, 2003 at 05:40:30PM +0200, Daniel Lang wrote: Hiho, There seems no freebsd-xfree list, but this is only XFree related, it's rather kernel oriented. Matrox offers a RedHat-Linux driver for their Parhelia based boards (Parhelia, P650, P750). The XFree86 driver module mtx_drv.o itself is OS independent and works with FreeBSD, as successfully tested on my desk, even with a multihead configuration. :) Alas, to use acceleration (2D xaa as well as 3D dri, OpenGL, etc) it requires a kernel module to enable bus mastering on the card. (I don't know if this is a common thing with Linux, or with some graphic boards? I am not aware of bus mastering is required for AGP boards, isn't AGP a dedicated bus anyway?) AFAIK, you can enable bus mastering using pciconf(8) by setting appropriate registers. Why do you need any additional kernel module? Or I'm completely missing the point? -ip Busmastering is not an important part of kernel modules used for aiding accelerating graphics, if it is at all. Notably, XFree86 enables busmastering itself for all the cards it supports that need it (radeon, r128, mga, i8x0, etc.). What that module is more likely for is doing things that require kernel support, such as handling of interrupts to efficiently use the card's DMA support and sharing of resources between various competing direct-rendering clients. I'm not aware of anyone working on Matrox binary driver support. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
per-open device private data, mmap
To work properly, the DRM needs an area of memory per open of the device which stores information on whether that fd is authenticated and also to have a unique identifier for use in the lock. Currently we use drm_find_file_by_proc to get the private data and use the pid as the unique identifier, but for example this causes problems if a fork occurs (threaded linux programs). This information is needed in the entry points (open, close, ioctl). (read, write, and poll from the current code are being stubbed out because they are unnecessary). To do this, I'm working on following what dev/streams/streams.c does in creating a new struct file and setting its own fileops and using the f_data field for the pointer to the private data. This looks pretty good for open/close/ioctl, but there's a problem with mmap. Currently we use drm_find_file_by_proc in the mmap handler to see if that process is authenticated, but there's no way from the mmap handler to get the private data because the struct file * isn't passed in. My initial thought was to instead check the authentication in the DRM(mapbufs) ioctl, where the vm_mmap is done by the X Server or clients. The problem with this is that a process could still do an mmap() on the fd and avoid the authentication check. What I'm wondering at this point is, is there any way to prevent the mmap() from succeeding (nothing legitimate uses mmap -- it's all done with the mapbufs ioctl), or a way to make it so from the device's mmap handler I can detect whether mmap() or mapbufs made the mapping, or to have different mmap handlers for those two vm_mmap callers. What's the best way to do this? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: per-open device private data, mmap
On Fri, 2003-03-14 at 13:59, Eric Anholt wrote: To work properly, the DRM needs an area of memory per open of the device which stores information on whether that fd is authenticated and also to have a unique identifier for use in the lock. Currently we use drm_find_file_by_proc to get the private data and use the pid as the unique identifier, but for example this causes problems if a fork occurs (threaded linux programs). This information is needed in the entry points (open, close, ioctl). (read, write, and poll from the current code are being stubbed out because they are unnecessary). To do this, I'm working on following what dev/streams/streams.c does in creating a new struct file and setting its own fileops and using the f_data field for the pointer to the private data. This looks pretty good for open/close/ioctl, but there's a problem with mmap. Currently we use drm_find_file_by_proc in the mmap handler to see if that process is authenticated, but there's no way from the mmap handler to get the private data because the struct file * isn't passed in. My initial thought was to instead check the authentication in the DRM(mapbufs) ioctl, where the vm_mmap is done by the X Server or clients. The problem with this is that a process could still do an mmap() on the fd and avoid the authentication check. What I'm wondering at this point is, is there any way to prevent the mmap() from succeeding (nothing legitimate uses mmap -- it's all done with the mapbufs ioctl), or a way to make it so from the device's mmap handler I can detect whether mmap() or mapbufs made the mapping, or to have different mmap handlers for those two vm_mmap callers. What's the best way to do this? Gah, and the instant I hit 'send' I realize that things /do/ use mmap and mapbufs is only for agp/sg memory. I guess it'll be okay to keep drm_find_file_by_proc and grab authentication information from there; it shouldn't be too big of an issue. The unique identifier is the big problem and the fileops trick should work for that. However, is this going to get easier some day? Are there any plans to pass the struct file down to the drivers and have a void * in there for private data? Also, we need to be blocking SIGSTOP and such things while the lock is held so that people don't hang the X Server by suspending a client while it holds the lock. Does anyone know about how to do this? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: X11 display problem
On Fri, 2002-10-25 at 10:07, Brandon D. Valentine wrote: On Fri, 25 Oct 2002, Paul Schenkeveld wrote: On Fri, Oct 25, 2002 at 11:57:59AM -0500, Brandon D. Valentine wrote: I'm not near my FreeBSD machines at this moment but this weekend I'll hack up the necessary patch if nobody else bothers. Probably better to call it something less ambigious like X11_LISTEN_TCP or similar so those who want to put it in make.conf don't incur namespace ambiguity and possible collision with other ports that might use similar make variables with different semantic meaning. WITH_TCP doesn't have the same sort of global meaning that WITH_GNOME does. May I suggest WITH_STARTX_TCP ? My $0.02 If I have any input it'll be WITH_X11_TCP or X11_LISTEN_TCP or similar. If the upstream xdm is fixed to turn off listen_tcp by default we'll want one flag to turn the behavior back on for both xdm and startx so naming the make variable startx would only serve to obscure it from xdm users (myself included). WITH_TCP_(LISTEN_)DEFAULT? It's not exactly a compile-time option like most WITH_BLAH. However, this plus a message at the start of the build and maybe a pkg-message note makes me much more comfortable with the startx/xdm changes. I may get to it this weekend. Complete patches submitted will get it done sooner :) -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: KLD mmap question
On Thu, 2002-05-30 at 13:14, Tom Tang wrote: Hello, I have a question about implementing mmap functions in device drivers. Thinking it would be simple, I contigmalloc'd a buffer of PAGE_SIZE and returned it using atop like other mmap device implementations. However when my userland program mmaps the device with offset 0, when I try accessing the returned pointer, it returns me invalid memory address. Any help would be appreciated... An associated question: while I was looking at the DRM's mmap for the shared memory area, I think I figured out that you didn't need memory that was going to be mmapped to be physically contiguous (since the device pager would get each page of it separately). Was I right? -- Eric Anholt [EMAIL PROTECTED] http://gladstone.uoregon.edu/~eanholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DRI, XFree86-4.0.3 and -current.
Oops, I'll have to clarify that. No, you don't need to keep an XFree86-4 tree around at all. Just get the X-DRI tree from sourceforge, and install it over your XFree86-4 install. I have both XFree and X-DRI CVS trees (downloading the 90MB or whatever per X release just isn't going to happen through my 28.8): /usr/local/src/xfree is X CVS (cvs.xfree86.org, updated/installed rarely, as most changes end up in X-DRI soon enough anyway) /usr/lcoal/src/xdri is X-DRI CVS (cvs.sourceforge.net bsd-2-0-0-branch, compiled/installed frequently). I'm working on making it so we can have an official port of the DRI -- you'll install the XFree86-4.x port (which would install X, the dri modules, libGL, libGLU, etc.), then go to graphics/drm-kmod and install that, and you'll be done installing. It's not quite finished yet, and I am waiting to get to a faster line (2 weeks) before downloading the X release to test against. On Friday 07 September 2001 03:12, Volker Stolz wrote: In local.freebsd-hackers, you wrote: On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: I have a page about the DRI for FreeBSD at=20 http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works I had a look at that, but it wasn't too clear what I needed to do. I suspect that I'm expecting to checkout the DRI tree _over_ the top of the XFree86-4 tree but perhaps I don't need to do that. Neither was I. Could you clarify on merging XFree from the ports and the CVS? I tried copying the CVS-stuff over the port, but the build stopped with: cleaning in programs/Xserver/hw/xfree86/input/calcomp... cd: can't cd to calcomp -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DRI, XFree86-4.0.3 and -current.
I have a page about the DRI for FreeBSD at http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on -stable. There is one compile error on -current that should be obvious to fix in the kernel modules, but I haven't uploaded patches as I haven't actually tested it yet (I'm still setting up my new -current installation). On Thursday 06 September 2001 10:57, Josef Karthauser wrote: Has anyone got patches for DRI under -current? Joe -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
