[Dri-devel] Re: [Mesa3d-dev] miniglx and DDX version checking
Jon Smirl wrote: I don't think they are necessary so the _SOLO defines could be extended. Keith wrote the code so I'm not sure what he intentions were. --- Dave Airlie [EMAIL PROTECTED] wrote: The current miniglx fakes up some DDX version numbers but these only work for the radeon drivers, (4.0) is used, but the i810 drivers is only on version 1.0, Is there any need for this to be checked at all should the _SOLO defines in utils.c:driCheckDriDdxDrmVersions be extended to cover the DDX check? There's no need to check the faked up numbers. Feel free to patch them out of existence, if possible. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Three proposed new generic DRM IOCTLs
Michel Dnzer wrote: On Sun, 2004-03-14 at 07:14, Jon Smirl wrote: This is a first pass at the three new IOCTL patch. It is against the DRM copy in the Mesa tree. And exactly why does that still exist? I know you don't listen to me, but I don't think you can ignore Keith. If there's any reason for this remaining, I'd like to hear it. Keeping the headers is justifiable, I guess, but I don't want to see the DRM drivers living in two places. If there's an argument that it's time to start a new tree for the DRM code to live in, I'm happy to progress in that direction. In general, having one client of the drm blessed with the duty of holding the DRM code gives a skewed approach to the design of those modules. Having them become a first-class project with their own tree hopefully their own, concerned, developers looks like a more rational way forward. So, I guess that's a vote from me for a new tree. But certainly I don't want to see the guts of the DRM jump into the Mesa tree. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Three concepts for changing the way video works in Linux
Michel Dänzer [EMAIL PROTECTED] writes: On Sun, 2004-03-14 at 21:00, Jon Smirl wrote: Linux's current design has lots of holes in it. Start two X servers on two different VTs (not just two sessions to the same X server) How do you start two sessions to the same X server? *shrug* you're going to reboot your machine. Works fine here... Works fine for me too, but only one of the two Xservers is opengl accelerated. I've been using this for months - I run ratpoison on one Xserver and E on the other. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] miniglx and DDX version checking
Hi! Yep, I had the same problems, trying to get the TDFX/solo work. Keith? I don't think they are necessary so the _SOLO defines could be extended. Keith wrote the code so I'm not sure what he intentions were. --- Dave Airlie [EMAIL PROTECTED] wrote: The current miniglx fakes up some DDX version numbers but these only work for the radeon drivers, (4.0) is used, but the i810 drivers is only on version 1.0, Is there any need for this to be checked at all should the _SOLO defines in utils.c:driCheckDriDdxDrmVersions be extended to cover the DDX check? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person = Regards, Borca Daniel http://www.geocities.com/dborca/ __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM locks usage?
Hi! Is it possible to use the heavyweight drm locking mechanisms for other locks than the global hardware lock? What I'm after is a mechanism to suspend drm-aware processes until a display resource gets available and then wake them up on a FIFO basis when the process that currently holds the resource signals it's availability. Typically processes hold the resource for at least 10 ms, so the global lock is not an option; spinlocks are too cpu-consuming. I was wondering if one could implement a second lock struct in the private part of the SAREA and then use a drm IOCTL on that one, but briefly browsing the headers I see no way to pass a private lock to the DRM? Any help would be greatly appreciated. Regards Thomas --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Binary incompatibility breaks snapshots (was: DRI savage on FC1 w/2.4)
I've got no problem with savage-20040303-linux.i386.tar.bz2, Next step would be to have it working on 2.6: Should I be following the steps in install.sh? Which differences are there between 2.4 and 2.6 installation of DRM and DRI stuff? Thanks, Albert. On Fri, 2004-03-12 at 15:33, Alex Deucher wrote: --- Felix Khling [EMAIL PROTECTED] wrote: On Fri, 12 Mar 2004 14:48:45 + avilella [EMAIL PROTECTED] wrote: The DRI seems to be enabled: - [snip] yes, looks good. - and here is the log of: [avb]$ LIBGL_DEBUG=verbose glxinfo - name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so display: :0 screen: 0 direct rendering: No [snip] This looks like the binary incompatibility. The old Xserver or server-side glx code (not sure) doesn't work correctly with the new client-side glx code. With a new Xserver compiled from CVS I get this: name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6-DRI/lib/modules/dri/savage_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 display: :0 screen: 0 direct rendering: Yes [...] In other word, your only option is to compile from source until this is tracked down and fixed. we could provide an updated xfree86 binary and associated glx libs in the mean time. I'm not sure which files we need off hand. Alex Regards, Felix __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Binary incompatibility breaks snapshots (was: DRI savage on FC1 w/2.4)
On Mon, 15 Mar 2004 09:01:16 + avilella [EMAIL PROTECTED] wrote: I've got no problem with savage-20040303-linux.i386.tar.bz2, Next step would be to have it working on 2.6: Should I be following the steps in install.sh? Which differences are there between 2.4 and 2.6 installation of DRM and DRI stuff? The driver works with 2.6, though PCI cards are currently not supported with 2.6 kernels. But install.sh in the snapshots needs to be updated for 2.6. I'm going to tackle this ASAP. Thanks, Albert. Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 1811] Error during compile 2.6.1-rc2-mm1
http://bugme.osdl.org/show_bug.cgi?id=1811 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |CLOSED Resolution||CODE_FIX --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM locks usage?
Thomas Hellström wrote: Hi! Is it possible to use the heavyweight drm locking mechanisms for other locks than the global hardware lock? What I'm after is a mechanism to suspend drm-aware processes until a display resource gets available and then wake them up on a FIFO basis when the process that currently holds the resource signals it's availability. Typically processes hold the resource for at least 10 ms, so the global lock is not an option; spinlocks are too cpu-consuming. I was wondering if one could implement a second lock struct in the private part of the SAREA and then use a drm IOCTL on that one, but briefly browsing the headers I see no way to pass a private lock to the DRM? Any help would be greatly appreciated. You should look at the way vblank interrupt waiting is handled in the radeon driver. That works by just having the calling process block in an ioctl. The other way to do it would be by using a standard futex. Either should work. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Three proposed new generic DRM IOCTLs
Jon Smirl wrote: 1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented 2) VGA_ENABLE -- this is used to control the active VGA card in the system. 3) BLANK - simple call to allow Vesa power management to blank the display. How does all this work on non-x86 systems? Since the rest of the world, thankfully, doesn't use compiled machine code in the on-card firmware, how is that handled? *Is* that handled? :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM in a standalone tree
Could someone with admin privs at fd.o please make a new project and put the two DRM directories into it? It is probably easier to get them from Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there. Right now the mesa and dri versions are identical so it doesn't matter. If you would rather get them from the DRI tree you need: dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel As soon as this is done I will alter the mesa build process to use a pointer to the new tree. That will allow us to keep everything building off from a single copy of the h files preventing them from getting out of sync. After I get the pointer working I'll remove the copy from mesa. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm:i830_wait_ring
Patrick Dohman wrote:
I have been able to reproduce several x server crashes by killing a
process from tty 1,2 or 3 that is running on tty5 this crash occurs
after killing a variety of process such as evolution and mozilla and
then attempting to switch to tty5 from tty 1,2 or 3. I am running
XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) on Linux version
2.4.24(gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7))
The errors printed to the terminal are below.
[drm:i830_wait_ring] *ERROR* space: 131048 wanted 131064
[drm:i830_wait_ring] *ERROR* lockup
Why, pray tell, are you using the mach64 branch with an i830? Please go
to http://dri.sourceforge.net/cgi-bin/moin.cgi/Download and get a recent
binary snapshot. That will install the *correct* driver for your chip.
If that still doesn't work (and it may not), please send your complete
XF86Config (or XF86Config-4 depending on your system),
/var/log/XFree86.0.log, and relevant information from /var/log/messages
('grep -i drm' should do the trick).
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Three proposed new generic DRM IOCTLs
--- Ian Romanick [EMAIL PROTECTED] wrote: How does all this work on non-x86 systems? Since the rest of the world, thankfully, doesn't use compiled machine code in the on-card firmware, how is that handled? *Is* that handled? :) The main purpose is to initialize secondary adapters that the system BIOS did not init. So the patch only gets activated when there are multiple video adapters installed. A much better fix for this would be to alter the Linux kernel to initialize these adapters during the very beginning of the boot process before entering protected mode. This is really a BIOS shortcoming that we are trying to fix in user space. There are several problems but the problems are not unique to my patch, X and framebuffer have the same issues. X contains a variation of this code that runs in user space. Mucking with PCI bridges from user space seems very risky to me. The patch uses the kernel entry points to muck with the bridges. 1) X86 card in a non-X86 machine. People usually do this to save money. Most common case is running X86 card in PPC. Another time this occurs is on the Itanium. To address this I have the source for a x86 emulator that can be linked into the video-reset program. I haven't tried doing this yet because I don't own any non-X86 hardware. 2) OpenFirmware. These cards won't work as secondary unless the system BIOS supports it. If someone has an OpenFirmware interpreter this could be made to work on other architectures. Nothing bad will happen in my code, the entry point where I jump to just has an x86 return instruction in it. There is no universal solution for all platforms. Right now framebuffer doesn't address secondary adapters, so I wouldn't be surprised if they took some of the code out of the DRM patch and added it back to framebuffer. Other parts of the code are copied straight from framebuffer; the code in framebuffer was derived from the code in X. Of course I wouldn't need to do this at all if we had enough information from the manufacturers to add a reset function to the device drivers. I'm trying to build a unified driver that combines the best of framebuffer and DRM so there is code that I copied from both places. I then want to take the unified driver and add some new features to it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM in a standalone tree
Jon Smirl wrote: Could someone with admin privs at fd.o please make a new project and put the two DRM directories into it? It is probably easier to get them from Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there. Right now the mesa and dri versions are identical so it doesn't matter. If you would rather get them from the DRI tree you need: dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel As soon as this is done I will alter the mesa build process to use a pointer to the new tree. That will allow us to keep everything building off from a single copy of the h files preventing them from getting out of sync. After I get the pointer working I'll remove the copy from mesa. Just CC'ing Daniel Stone, the all-purpose fd.o admin guy apparent melbournite. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Three proposed new generic DRM IOCTLs
On Llu, 2004-03-15 at 16:51, Ian Romanick wrote: Jon Smirl wrote: 1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented 2) VGA_ENABLE -- this is used to control the active VGA card in the system. 3) BLANK - simple call to allow Vesa power management to blank the display. How does all this work on non-x86 systems? Since the rest of the world, thankfully, doesn't use compiled machine code in the on-card firmware, how is that handled? *Is* that handled? :) It doesn't work on x86 machines either. Not all cards even have a video bios. Not all cards are VGA and not all cards do vesa blanking. Take for example the Voodoo1. Does frame buffer nicely right now, does X with the voodoo driver or glide driver, is not VGA, has no VBIOS and doesn't support vesa blanking --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Three concepts for changing the way video works in Linux
On Sul, 2004-03-14 at 20:00, Jon Smirl wrote: However, I am saying that we need a blend between framebuffer and DRM. Not DRM bolted on top of framebuffer. You keep imposing policy in the mid layer. How do you know whether you need a blend or not - its card specific. Some cards have 2D/3D seperate, others have them closely intertwined so that the fb acceleration for text does want to use the DRM layer. Virtual terminals may be implemented differently too. Why can't each virtual terminal have a screen buffer allocated in VRAM? Then on VT switch the video base pointer is simply moved around. Now run xserver with compositing. Since you have all of the VTs in video RAM they can be composited along with all of the other X windows. Thats hardware specific. The voodoo for example can't do this, the frame buffer layout is hardware fixed. A large number of very low end PDA like graphics controllers are similar. There is one frame buffer image, it starts at the beginning and you can't alter it. Linux's current design has lots of holes in it. Start two X servers on two different VTs (not just two sessions to the same X server) you're going to reboot your machine. File a bug. It works for me I do it all the time, and it should work for you. Modprobe in the framebuffer driver for your video card from an xterm window, you're going to reboot to fix it. Root is allowed to do stupid things, news at 11. 1) There should be a single device drivers controlling access to the video hardware You need this to handle hot plug as well. I don't think anyone disagrees 2) There should a single device driver presenting virtual hardware. Other apps/devices can then use this virtual device however they see fit. Why ? 3) Every app and device driver has to completely cooperate with each other and never take an action that will interfere with another's user of the video hardware. Thats a matter for locking. 4) Each VT session can do what it wants to the video hardware. At VT swap the entire state of all registers, VRAM, AGP memory, outstanding DMA, interrupt handlers, etc is saved and the state of the next VT is loaded. That is an argument for #1, and maybe an argument that the device driver has some responsibility for context management. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM in a standalone tree
Around 8 o'clock on Mar 15, Jon Smirl wrote: Could someone with admin privs at fd.o please make a new project It would surely be a lot easier to just create a new module in an existing project. I think the DRM fits reasonably well under the DRI banner. -keith pgp0.pgp Description: PGP signature
[Dri-devel] Re: DRM in a standalone tree
On Mon, 2004-03-15 at 21:03, Keith Packard wrote: Around 8 o'clock on Mar 15, Jon Smirl wrote: Could someone with admin privs at fd.o please make a new project It would surely be a lot easier to just create a new module in an existing project. I think the DRM fits reasonably well under the DRI banner. I was going to say the same thing. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM in a standalone tree
Jon Smirl wrote: Could someone with admin privs at fd.o please make a new project and put the two DRM directories into it? It is probably easier to get them from Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there. Right now the mesa and dri versions are identical so it doesn't matter. If you would rather get them from the DRI tree you need: dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel And dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Driconf
Em Seg 15 Mar 2004 18:44, you wrote: On Mon, 15 Mar 2004 17:30:48 -0300 Paulo R. Dallan [EMAIL PROTECTED] wrote: Em Ter 09 Mar 2004 20:09, you wrote: Paulo R. Dallan [EMAIL PROTECTED] wrote: Em Seg 08 Mar 2004 13:31, you wrote: Em Seg 08 Mar 2004 08:35, you wrote: snip Hi Felix, How are you doing? Sorry for not talking about the driconfig support, but I was out of town for some days and was completely off-line. But did not forget about the help promised! :) Well, we have some progress, so here we go. snip See the end of the design doc for some XML-references. Though I don't think you need to deal with XML directly either. There are macro definitions for some common options in xmlpool.h. You only need to write some XML if you want to add new options. But that's pretty intuitive and the existing options in xmlpool.h should give good examples. snip I've been studing the dri configuration documentations, checked the macro possibilities in xmlpool.h, and following your tip, analysed how it was implemented for the mga card (the code in mga_xmesa.c). So, basically, it's a macro at compiling time, correct (actually a good idea)? The macros expand to exactly the XML document that you see with xdriinfo options mga. Ok, I checked the output of xdriinfo options mga and xdriinfo options savage. This last one, obviously, returned nothing (because this is what is supposed to be being implemented now), the other one returned a page of xml info (and, in fact, very /few/ options, basically vblank_mode, texture_depth and color_reduction). Yes, anyone is welcome to add new options. ;-) (i) Now comes one question: this options implemented, what is their relation to the options described in the man page of the driver (e.g. man mga or man savage? Is there any relation between both? Does the man page contains all of them, /plus/ others related to X86 general options etc? The man pages refer only to the 2D drivers. The 3D driver options aren't documented in any manpages. The hope was that they are self documenting, but currently the descriptions are rather terse. There is some more verbose documentation of some options in the Wiki. (ii) So, in order to implement the options for the savage driver, I have to go through the code itself, or is there any document which I should follow (i.e., how to verify which are the options of xmlpool.h which are aplicable)? If it is throught the code, good, will learn a lot; but it won't be that easy at the present stage! ;) - any tip for where to start from? The first step will be to add the necessary boilerplate to the screen- and context data structures, add a first simple (maybe empty) option description in __driConfigOptions and to call the initialization functions in CreateContext and CreateScreen. If you want to see output from xdriinfo you can safely add options without actually implementing any code that evaluates them. The hard part will be adding the actual implementation of options. That's where you'll have to go into different parts of the driver and make the behaviour depend on some options. Often it's a good idea to read an option value in CreateContext and store it somewhere in the Context structure. Then it can be accessed more quickly later on. Best regards, Paulo PS1: In parallel, have been studing the Redbook ( having a view in the Bluebook) and also following some tutorials in gl, glx and, more especifically, in glu glut (for Linux). Have been having some problems in image viewing, or funcions not being implemented. Is it relevant, or not really fully implemented yet so we may get some trouble in it? Someone else complained about this. The funny thing is that the relevant mesa demo (don't remember the name, something with pix I think) works on my system, but not on another user's system. Someone is going to have to fix it at some point. I have other priorities ATM. PS2: Funny that to compile glu glut programs, I have to especifically use the -L option to indicate the location of the libraries, although my ld.so.config file seem to include the path (/usr/X11R6/lib)... Have you had the same problem? I don't think so. I usually use this in Makefiles: LDFLAGS=-lGL -lGLU -lglut Though the search paths of the compiler don't have anything to do with the search paths of the dynamic linker IIRC. PS3: Will have a look at the meeting today (actually, have done that twice already). Will be quiet (as usual), just watching. :) The funny thing is that the messages seem to take so long to get. I don't know if I'm getting them delayed somehow. Don't know. Sometimes it's a bit hard to follow because all the threads of discussion are interleaved. And sometimes people take some time to type a good answer or have to look something up first. Cu, Felix P.S.: I think it would be good to make this thread
[Dri-devel] DRM reorganization
We're looking at reorganizing the way DRM drivers are maintained. Currently, the DRM kernel code lives deep in a subdirectory of the DRI tree (which is a partial copy of the XFree86 tree). We plan to move it up to its own module at the top level. That should make it *much* easier for people that want to do things with the DRM but don't want all the rest of X (i.e., DRI w/DirectFB, etc.). When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? This is cross-posted to LKML dri-devel, and I'm not on LKML. If you reply, please hit the 'Reply to all' button. :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM reorganization
Ian Romanick [EMAIL PROTECTED] wrote: We're looking at reorganizing the way DRM drivers are maintained. Currently, the DRM kernel code lives deep in a subdirectory of the DRI tree (which is a partial copy of the XFree86 tree). We plan to move it up to its own module at the top level. That should make it *much* easier for people that want to do things with the DRM but don't want all the rest of X (i.e., DRI w/DirectFB, etc.). When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
--- Andrew Morton [EMAIL PROTECTED] wrote: Ian Romanick [EMAIL PROTECTED] wrote: We're looking at reorganizing the way DRM drivers are maintained. Currently, the DRM kernel code lives deep in a subdirectory of the DRI tree (which is a partial copy of the XFree86 tree). We plan to move it up to its own module at the top level. That should make it *much* easier for people that want to do things with the DRM but don't want all the rest of X (i.e., DRI w/DirectFB, etc.). When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. we (as dri developers) should probably also sync the other way more regularly too. sometimes there are changes in the kernel tree that don't get back to the dri/drm tree in a timely manner. Alex __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
Andrew Morton wrote: Ian Romanick [EMAIL PROTECTED] wrote: We're looking at reorganizing the way DRM drivers are maintained. Currently, the DRM kernel code lives deep in a subdirectory of the DRI tree (which is a partial copy of the XFree86 tree). We plan to move it up to its own module at the top level. That should make it *much* easier for people that want to do things with the DRM but don't want all the rest of X (i.e., DRI w/DirectFB, etc.). When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. I'm not 100% sure what you mean. Right now the files in our CVS are split between two directories. There's a common directory, which is used on both Linux BSD, and a Linux-specific directory. Our intention is to shift around where some of the files are in our CVS. I don't think we intend to move where things are in the Linux source tree. That's part of why I'm asking. From talking to Linus in the past, I know that merging in changes is a PITA due to our funky directory structure. I'd like to make that easier. :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
Ian Romanick [EMAIL PROTECTED] wrote: When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. I'm not 100% sure what you mean. Right now the files in our CVS are split between two directories. There's a common directory, which is used on both Linux BSD, and a Linux-specific directory. Our intention is to shift around where some of the files are in our CVS. I don't think we intend to move where things are in the Linux source tree. That's part of why I'm asking. From talking to Linus in the past, I know that merging in changes is a PITA due to our funky directory structure. I'd like to make that easier. :) Oh. So what was the question again? As far as I know, there's nobody in DRI-land who actually prepares and sends patches. Fixing that would be a good first step ;) I've had a 130k DRM patch in -mm since February 8th. Presumably it's out of date. As far as I know nobody is pushing more recent patches upstream. What's the process here, and who should I be dealing with? Thanks. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
--- Ian Romanick [EMAIL PROTECTED] wrote: That's part of why I'm asking. From talking to Linus in the past, I know that merging in changes is a PITA due to our funky directory structure. I'd like to make that easier. :) Part of the pain could be caused by the shared/linux split in the DRM tree. The kernel tree doesn't have that split. Also DRM makefile.kernel and the kernel char/drm/Makefile are similar but not the same. So any changes to the build procedure would need to be updated into char/drm/Makefile. drmstat.c/dristat.c should be pulled out of the driver directory and put it in a directory for apps. Where should Doxyfile and config.in go? The savage driver is not currently in the kernel. Should the mach64 driver be moved out of the branch and into the DRM project? The best solution would be to have some kind of scipt in the DRM project that builds a directory that can simply be copied into char/drm. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] tdfx build fixes and driinterface conversion
The first patch (against the Mesa tree) fixes tdfx_screen.c to use the new
interface. The second patch (against the DRI tree) fixes the Imakefilery to
use the new interface and link against the common objects.
Without these two tdfx is completely broken. With them, it works as well as
it did before driinterface was merged (which for me means textured apps are
hosed but glxgears works fine). That's next on my chopping block. I tested
this on 16-bit and 24-bit depths.
Comments are welcome. I don't particularly like how this duplicates loops in
*_dri.c and *_screen.c. I'd like to see a shared visual config table defined
in a header somewhere so we don't have to touch multiple places, but I
suspect that'd get ugly quick.
Index: src/mesa/drivers/dri/tdfx/tdfx_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/tdfx/tdfx_screen.c,v
retrieving revision 1.2
diff -u -r1.2 tdfx_screen.c
--- src/mesa/drivers/dri/tdfx/tdfx_screen.c 8 Dec 2003 17:14:47 - 1.2
+++ src/mesa/drivers/dri/tdfx/tdfx_screen.c 16 Mar 2004 01:37:04 -
@@ -316,6 +316,129 @@
.SwapBuffersMSC = NULL
};
+#ifdef USE_NEW_INTERFACE
+/*
+ * new interface code, derived from radeon_screen.c
+ * XXX this may still be wrong
+ */
+static PFNGLXCREATECONTEXTMODES create_context_modes = NULL;
+
+static __GLcontextModes *tdfxFillInModes(unsigned pixel_bits,
+ unsigned depth_bits,
+ unsigned stencil_bits,
+ GLboolean have_back_buffer)
+{
+ __GLcontextModes *modes;
+ __GLcontextModes *m;
+ unsigned num_modes;
+ unsigned vis[2] = { GLX_TRUE_COLOR, GLX_DIRECT_COLOR };
+ unsigned deep = (depth_bits 17);
+ unsigned i, db, depth, accum, stencil;
+
+ /* Right now GLX_SWAP_COPY_OML isn't supported, but it would be easy
+ * enough to add support. Basically, if a context is created with an
+ * fbconfig where the swap method is GLX_SWAP_COPY_OML, pageflipping
+ * will never be used.
+ */
+
+ num_modes = (depth_bits == 16) ? 32 : 16;
+
+ modes = (*create_context_modes)(num_modes, sizeof(__GLcontextModes));
+ m = modes;
+
+ for (i = 0; i = 1; i++) {
+ for (db = 0; db = 1; db++) {
+ for (depth = 0; depth = 1; depth++) {
+ for (accum = 0; accum = 1; accum++) {
+ for (stencil = 0; stencil = !deep; stencil++) {
+ if (deep) stencil = depth;
+ m-redBits = deep ? 8 : 5;
+ m-greenBits = deep ? 8 : 6;
+ m-blueBits = deep ? 8 : 5;
+ m-alphaBits = deep ? 8 : 0;
+ m-redMask = deep ?0xFF00 :0xF800;
+ m-greenMask = deep ?0x00FF :0x07E0;
+ m-blueMask = deep ?0xFF00 :0x001F;
+ m-alphaMask = deep ? 0x00FF : 0;
+ m-rgbBits = m-redBits + m-greenBits +
+ m-blueBits + m-alphaBits;
+ m-accumRedBits = accum ? 16 : 0;
+ m-accumGreenBits = accum ? 16 : 0;
+ m-accumBlueBits = accum ? 16 : 0;
+ m-accumAlphaBits = accum ? 16 : 0;
+ m-stencilBits = stencil ? 8 : 0;
+ m-depthBits = deep
+ ? (depth ? 24 : 0)
+ : (depth ? 0 : depth_bits);
+ m-visualType = i ? GLX_TRUE_COLOR
+ : GLX_DIRECT_COLOR;
+ m-renderType = GLX_RGBA_BIT;
+ m-drawableType = GLX_WINDOW_BIT;
+ m-rgbMode = GL_TRUE;
+ m-doubleBufferMode = db ? GL_TRUE : GL_FALSE;
+ if (db)
+ m-swapMethod = GLX_SWAP_UNDEFINED_OML;
+ m-visualRating = ((stencil !deep) || accum)
+ ? GLX_SLOW_CONFIG
+ : GLX_NONE;
+ m = m-next;
+ if (deep) stencil = 0;
+ }
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
+/**
+ * This is the bootstrap function for the driver. libGL supplies all of the
+ * requisite information about the system, and the driver initializes itself.
+ * This routine also fills in the linked list pointed to by \c driver_modes
+ * with the \c __GLcontextModes that the driver can support for windows or
+ * pbuffers.
+ *
+ * \return A pointer to a \c __DRIscreenPrivate on success, or \c NULL on
+ * failure.
+ */
+void * __driCreateNewScreen( Display *dpy, int scrn, __DRIscreen *psc,
+ const __GLcontextModes * modes,
+ const __DRIversion * ddx_version,
+ const __DRIversion * dri_version,
+ const __DRIversion * drm_version,
+ const __DRIframebuffer * frame_buffer,
+ drmAddress pSAREA, int fd,
+ int internal_api_version,
+ __GLcontextModes ** driver_modes )
+{
+ __DRIscreenPrivate *psp;
+
+ psp = __driUtilCreateNewScreen(dpy, scrn, psc, NULL,
+ ddx_version, dri_version, drm_version,
+ frame_buffer, pSAREA, fd,
+ internal_api_version, tdfxAPI);
+
+ create_context_modes = (PFNGLXCREATECONTEXTMODES)
+ glXGetProcAddress((const GLubyte *)__glXCreateContextModes);
+
+ if (create_context_modes != NULL) {
+ /* divined from tdfx_dri.c, sketchy */
+ TDFXDRIPtr dri_priv = (TDFXDRIPtr) psp-pDevPriv;
+ int bpp = (dri_priv-cpp 2) ? 24 : 16;
+
+ /* XXX i wish it
