[Dri-devel] Re: possible memleak in drivers/char/drm/drm_drv.h::drm_init() ?
On Wed, Mar 12, 2003 at 11:34:08PM +0300, Oleg Drokin wrote: > Hello! > >Seems this is right list/person to post this. >I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and >it seems there is a memleak on error exit path. >If DRM(stub_register)(DRIVER_NAME, &DRM(fops),dev) fails, >DRM(device) and DRM(minor) memory areas are not freed before exit. > >Is this looking real? I don't know. The drm code is intentionally obsfucated. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Update direct-rendering to current DRI CVS tree.
On Sun, Mar 30, 2003 at 09:14:58AM -0500, Nicholas Wourms wrote: > Dave Jones wrote: > > > #if LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,2) > > > #define down_write down > > > #define up_write up > > > > #if can go, like it did in other parts of the patch. > > What will replace it? Nothing. 2.4.0/2.4.1/2.4.2 are too buggy to be used. --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote: > fbdev only has one distribution vector - the kernel, DRM has multiple > distribution vectors, kernel, DRI snapshots, X releases, they all contain > their own DRM modules, also people with older kernels should be able to which is the root problem. Make sure the kernel is the canonical source and all those problems magically disappear. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote: > Yes, while I support the current rework and de-templatization of the code, I > don't support any attempt to split the drm modules to try and share code at > runtime - ie. I don't support a core/submodule approach. We had that argument already in 2000/2001 when we had the big XFree 4.1 DRM update. There's no reason drm should be different from all other kernel subsystems. If you really fear this is a problem add a monotonely increasing DRM_VERSION define for driver to check against and even better don't make any not backwards-compatible changes unless you're doing a major version bump. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote: > > > I guess one (unpleasant) way to make it work would be to add the version to > > all the symbols in the device-independent layer. Instead of drm_foo you'd > > have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple > > modules loaded or a module loaded with a built-in version. I'm not sure how > > happy that would make the kernel maintainers (not to mention how happy it > > would make us). :( It's basically like what we have now, except the current > > code has the device's name add to all the symbols and is built into the > > device-dependent module. Ugh, ugh. > > > > How do other multi-layer kernel modules handle this? For example, how does > > agpgart or iptables do it? Just make sure the driver core and subdrivers are always in sync. That's an entirely sensible thing and how all other subsystems with lowlevel calls work. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote: > And thats one of the big reasons its such a mess and doesn't work out. > Nobody is testing or reviewing it until some huge "merge point" occurs > at which point you run the risk of people saying "Actually your design > sucks", or in the 2.6 case finding out too late so that there is a patch > kit to upgrade your 2.6 to the 2.4 console driver Sorry, but the reason for the fbdev mess is that James is completely unable to do proper project managment. The model works fine for every other kernel subsystem. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:12:16AM +0100, Dave Airlie wrote: > DRM core - just the stub registration procedure and handling any > shared resources like the device major number, and perhaps parts of sysfs > and class code. This interface gets set in stone as quickly as possible > and is as minimal as can be, (Jon Smirls dyn-minor patch will help a fair > bit also). All the core does is allow DRMs to register and de-register in > a nice easy fashion and not interfere with each other. This drmcore.o can > either be linked into the kernel (ala the fb core) or a module, but in > theory it should only really be shipped with the kernel - (for compat > reasons the DRM tree will ship it for older systems). Ok. > DRM library - this contains all the non-card specific code, AGP > interface, buffers interface, memory allocation, context handling etc. > This is mostly stuff that is in templated header files now moved into C > files along the lines of what I've done in the drmlib-0-0-1-branch. This > file gets linked into each drm module, if you build two drivers into the > kernel it gets shared automatically as far as I can see, if you build as > modules they both end up with the code, for the DRM the single card is the > primary case so I don't mind losing some resources for having different > cards in a machine. Ok except you should build this only once. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote: > > > > Then drm_core would always be bundled with the OS. > > > > Is there any real advantage to spliting core/library and creating three > > interface compatibily problems? > > Yes we only have one binary interface, between the core and module, this > interface is minimal, so AGP won't go in it... *ALL* the core does is deal > with the addition/removal of modules, the idea being that the interface is > very minor and new features won't change it... Umm, the Linux kernel isn't about minimizing interfaces. We don't link a copy of scsi helpers into each scsi driver either, or libata into each sata driver. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 10:43:39AM +0100, Dave Airlie wrote: > > > > Umm, the Linux kernel isn't about minimizing interfaces. We don't link a > > copy of scsi helpers into each scsi driver either, or libata into each sata > > driver. > > true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel > component of a much larger system, of which the DRM just has to reside in > the kernel, And what makes this different? > While I agree the perfcet solution is to introduce another binary > interface, but no-one on the dri-devel list is willing to dedicate most of > their time for the next age answering questions like "well I upgraded my > r200 driver, and my mga stopped working, and the ATI binary driver killed > my dog when I changed something else", Just upgrade all of drm. You don't uopgrade a single drm driver either. Or introduce a DRM_VERSION macro ala KERNEL_VERSION.But best thing is really to keep the mast copy of drm in the latest kernel and let vendors backport if nessecary. > Ian has pointed this out on the > dri-devel list as a major issue and to be honest he is not alone in his > worries, if make the kernel responsible for the registration/de-reg only > then build everything else in the drivers, we don't have to worry about > someone adding a line to the middle of a structure and breaking the > modules from somewhere else.. not many people have two different graphics > cards and I'd rather inconvience them than increase support burden.. I think you need to start to play the kernel game if you want your code in the kernel. I know X has this strange idea of beeing useful mostly to make propritary vendors their life easier, but in kernel lands we thing differently. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote: > > Umm, the Linux kernel isn't about minimizing interfaces. We don't link a > > copy of scsi helpers into each scsi driver either, or libata into each sata > > driver. > > But regular users don't tend to pull down new scsi or ata drivers in the same > way that they do graphics drivers. Hence the concern of many drm developers > to avoid introducing new failure modes in this process. Actually regulat users do. And they do by pulling an uptodate kernel or using a vendor kernel with backports. This model would work for video drivers aswell. > People who'd never dream of upgrading their kernel have acquired the habit of > pulling down up-to-date video drivers on a weekly or monthly basis. So, for > sanity's sake, the DRI/DRM has been in the business of minimizing exposed > interfaces, and for my money, should continue to be in that business. And DRM is the most crappy code in the kernel. See any corelations? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:48:47AM +0200, Arjan van de Ven wrote: > > true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel > > component of a much larger system, of which the DRM just has to reside in > > the kernel, > > > you seem to be confusing 2 things. > > The kernel<->userspace interface is supposed to be stable, and it should > be so that you can basically decouple X and kernel versions. > > Within the kernel you should go for the best interface (where "best" is > a notion that is flexible over time) because 1) you can and 2) you are > suboptimal in both performance and maintenance if you don't seconded. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote: > > Actually regulat users do. And they do by pulling an uptodate kernel or > > using a vendor kernel with backports. This model would work for video drivers > > aswell. > > Sure, explain to me how I should upgrade my RH-9 system to work on my new i915? Download a new kernel.org kernel or petition the fedora legacy folks to include a drm update. The last release RH-9 kernel has various security and data integrity issues anyway, so you'd be a fool to keep running it. > However, introducing a new binary interface isn't going to magically transform > a fairly neglected codebase into a sparkly new one. All I can really see it > doing is saving a few K of memory in the hetrogenous dual head case. Oh, and > introducing a new failure mode to be debugged at a distance. huh? it you change the ABI your modules simply won't load. that's not exactly what I'd call debugging. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote: > > include a drm update. The last release RH-9 kernel has various security > > and data integrity issues anyway, so you'd be a fool to keep running it. > > OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link. > I got a file called "patch-2.6.8.1.bz2". I tried to install this but > nothing happened. My i915 still doesn't work. What do I do now? You could start getting a clue. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote: > > > OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link. > > > I got a file called "patch-2.6.8.1.bz2". I tried to install this but > > > nothing happened. My i915 still doesn't work. What do I do now? > > > > You could start getting a clue. > > > > Which is the problem, Keith was acting as a user with no clue, and why > should a user who can't get his graphics card working worry about kernel > upgrades, along with X upgrades, the DRI has a workable snapshot process > now that allows users to use their DRI supported graphics card now, not in A user without a clue should better be using a supported distribution. If he used Fedora Core2 instead of the totally outdated and unsupported RH9 he'd already have a kernel with i915 support on his disk. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote: > You didn't stick with that long Christoph. We're not even past first base > yet. Let's try again? > > So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother > comes in & compiles it up for me & I'm now running 2.6.8.1 - it's implausible > I know, but let's make it easier for you. Now, why isn't my i915 working? Because the drm developer took a long time to submit the driver after is was finished as they develop in a separate CVS tree instead of the kernel tree. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote: > > > > A user without a clue should better be using a supported distribution. > > If he used Fedora Core2 instead of the totally outdated and unsupported > > RH9 he'd already have a kernel with i915 support on his disk. > > What about Debian? they would have a 2.4 kernel.. is Debian not supported, > no-one told me... Due to the policies of the release manager Debian stable is a totalally lost cause. It's missing all other support bits for i915 plattforms aswell. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote: > >>So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother > >>comes in & compiles it up for me & I'm now running 2.6.8.1 - it's implausible > >>I know, but let's make it easier for you. Now, why isn't my i915 working? > > > > > > Because the drm developer took a long time to submit the driver after > > is was finished as they develop in a separate CVS tree instead of the kernel > > tree. > > OK, fair enough. We've been spoilt in the past with "automatic" merges > courtesy of some nice LKML types. > > But, now I've compiled 2.6.9 or whatever, it's still not working. My brother > says he won't come in and do any more work on my computer, so you'll have to > help me out from here... Here's a nickel, buy yourself some supported distribution and talk to their support people. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote: > Please don't think that I'm talking for Tungsten at this or any other time on > the DRI list. I'm talking for myself and have never attempted to convey here > or elsewhere a "company" view without explictly flagging it up as such. > Apologies if the use of a TG mailing address is confusing, but I will have to > continue using it for the meantime as it is the one subscribed to this list. Even if you are not speaking for Thungesten you pretty much show that Thungsten has developers that in an area that overlaps with their works are not willing to get things done the kernel way. This should be a v ery big warnings sign for potentitial Thungsten Customers to look for a better supplier or at least give very strong directions. > Likewise, are you making a RedHat statement that you believe that your > endusers need to be able to compile a kernel to use your products, or is that > a statement of a regular LK developer? I'm sure you appreciate the parallel. That's not what he said. But sees Dave's next mail. > But in general, yes, I'd like to think that you don't have to have even heard > of a compiler in order to be able to install a video driver... And how does taking random dri snapshots help you there? The only sane way to make that happen is to make sure it's in the various distro kernels ASAP. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:17:54PM +0100, Dave Airlie wrote: > Lets take an example, I'm DA graphics card vendor, I write a DRI driver > for my brand new 3d graphics cards (they rock btw :-), people buy loads of > them, I want to give them something on my website that they can deploy to > use their new card, like a driver for ANotherOS. Now I just want to give > them an XFree DDX, DRI driver and a drm module (in source form, that they > can use no matter what kernel), now at the moment no matter what kernel > they have, the DRM is a completly separate entity - the DRM code deals > with it, > > If we make a library split that sits inside the kernel, their DRM can > stop working if someone busts the interface, hence the idea of having the > core reg/dereg in the kernel, and locking it down, then they can ship a > complete DRM source tree, and do as they wish as long as they interface > properly with the core... And with each distro kernel update they have to reinstall the damn thing. If you absolutely want people to use your driver on older kernels add the right KERNEL_VERSION (or DRI_VERSION if you want to abstract this out some way) for older ones. Again, how is drm different from scsi or net or whatever drivers except that you need a big userlevel component aswell? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote: > I've got nothing to do with Tungsten whatsoever, I've never met any of the > other major DRI developers, my worries here is this is turning into a > company issue, people keep mentioning Fedora this and that, Fedora is one > distro, I happen to use it, lots of people I know dont.. it supports DRI > on IGP and i915 in Fedora 3 Test only, a DRI snapshot works on FC1 and > FC2 as well.. Fedota is only mentioned as an example because the development is so open and I happen to see what's going on (I'm not using it myself at all). I'm pretty sure SuSE has/will have soon an update for i915, but it would requite more work for me to find out. > > > > And how does taking random dri snapshots help you there? The only sane way > > to make that happen is to make sure it's in the various distro kernels ASAP. > > Again what about distros that only do security upgrades in stable > releases, I would like to give those people a chance to use their graphics > cards, and the snapshots are not the only way, Intel have i915 Linux > drivers on their site from TG, they work on most kernels/distros, I get a > machine with i915 install Debian go to Intels website and download their > drivers, it all works, now why do I have to compile a kernel again? Okay, let's take Debian stable as an example. How do you get an agpgart that deals with the i915 into the 2.4.18 kernel woody ships? You really want the whole software stack to support new hardware. And for that you best go to a kernel that's not from stoneage, either a new upstream release or a maintained vendor kernel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:17:40PM +0100, Dave Airlie wrote: > > Actually after sleeping on this, I've just realised technically whether > the code is in a core separate module or driver module is only going to > affect maybe 5% of the work and the Makefiles/Kconfig at the end, so > following the principles of a)least surprise, b) kernel must remain > stable, I think I can proceed with moving stuff into libraries and the > likes without making the final decision until later, we will probably > start with having the library type code in the driver (where it is now) > and make it possible to change later, as it evolves.. Fine with me. ad keep up your good work. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
> If the kernel developers can address this point I would be most > interested, in fact I don't want to hear any more about sharing lowlevel > VGA device drivers until someone addresses why it is acceptable to have > two separate driver driving the same hardware for video and not for > anything else.. (remembering graphics cards are not-multifunction cards - > like Christoph used as an example before - 2d/3d are not separate > functions...)... Well, Alan's proposal gets things back into a working shape with both fbdev and get additional benefits like hotplug and autloading without a major revamp of everything. The major rework will have to happen sooner or later anyway, but by fixing the obvious problems we face now first it can be done in small pieces and with far less pressure. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote: > The resource reservation conflicts are already solved in the current > DRM code. Most of the changes are in kernel and the rest are in the > pipeline. DRM loads in two modes, primary where it behaves like a > normal Linux driver and stealth where it uses the resources without > telling the kernel. Stealth/primary mode is a transition tool until > things get fixed. Once everything is sorted out stealth mode can be > removed. Not, it's not been solved. You hacked around the most common symptoms. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote: > Not to step on toes, but... From what I can tell the idea is to add code > into FB that calles functions in the DRM and vice vers. This would seam > to add another ABI. Unless the code gets linked into one module, this > idea has been flamed and killed already. in-kernel ABIs are absolutely not an issue for Linux. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote: > Alan, if you will commit Redhat to implementing all of the features > referenced in this message: You definitly start sounding like Hans ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, Sep 28, 2004 at 11:54:35AM -0400, Jon Smirl wrote: > I've checked two new directories into DRM CVS for Linux 2.6 - > linux-core, shared-core. This code implements a new model for DRM > where DRM is split into a core piece and personality modules that > share the core. The major reason for doing this is that it allows me > to remove all of the DRM() macros; something that is causing lot's of > complaints from the Linux kernel people. I gave it a quick look and it looks great so far. Some ideas that would be nice improvements still (not that some may be inherited from the old drm code, I just looked at the CVS checkout): - once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full ->probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. This would get rid of the ->preinit and ->postinit hooks. - isn't drm_order just a copy of get_order()? - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent - care to use linux/lists.h instead of opencoded lists, e.g. in dev->file_last/dev->file_first or dev->vmalist - drm_flush is a noop. a NULL ->flush does the same thing, just easier - dito or ->poll - dito for ->read - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: > Christoph Hellwig wrote: > > > - drm_flush is a noop. a NULL ->flush does the same thing, just easier > > - dito or ->poll > > - dito for ->read > > Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a ->flush at all. Similarly all file_ops for regular files and many char devices don't have ->poll. no ->read is pretty rare but 2.4 chæcks it aswell. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: > Thinking about it, it may not have been a problem of crashing, but rather that > the behaviour visible from a program attempting to read (or poll) was > different with noop versions of these functions to NULL versions, and that was > causing problems. This is 18 months ago, so yes, I'm being vague. > > The X server does look at this file descriptor, which is where the problem > would have arisen, but only the gamma & maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no ->read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. Similar in poll your return 0 now while the generic code return (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM) for fds without ->poll, and again I'd say current drm behaviour could be considered a bug. for ->flush there's no behaviour change of not supplying it. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
On Fri, Dec 17, 2004 at 12:55:59PM -0800, Mike Werner wrote: > This new version reduces the number of changes required by users of the > agpgart > such as drm to support the new api for multiple agp bridges. > The first patch doesn't touch any platform specific files and all current > platform > gart drivers will just work the same as they do now since the global > agp_bridge is still supported as the default bridge. The agp_bridge_find function pointer is bogus, that way you can only support one backend at a time. I'm not really sure how to do that propery, best have the generic code walk down the pci device parent chain until it finds an AGP bridge and allow drivers that don't present their bridges as PCI devices to supply additional ways to search. Most other bits of the patch are fine, but in either case you first need to change the agp bridge driver API to take a struct agp_bridge_data in every method, else all these changes don't make sense at all. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
On Sat, Dec 18, 2004 at 09:17:14AM -0800, Mike Werner wrote: > > The agp_bridge_find function pointer is bogus, that way you can only support > > one backend at a time. > Obviously you mean one type of backend here. > I have tried to simplify this patch as much as possible so that it only tries > to do one thing > and that is just the api change. I think the searching for valid bridges is a > separate issue > since none of the currently supported hardware needs it. The only possible > platform > that I assumed might is amd64 and Andi Kleen specifically told me it doesn't. I agree that it's a separate issue. So keep the function poniter out for the time beeing and we can discuss it last. > I don't agree that you *must* pass the agp_bridge_data pointer for every > method. > You don't need it for bind/unbind/free if you associate each memory region > allocated using agp_allocate_memory(bridge,...) with a particular bridge > which is what the patch does. That is, agp_memory knows which bridge it > belongs to. Yes, agreed. But you need to pass the agp_bridge_data to each function in some way. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Sun, May 29, 2005 at 12:25:10AM -0400, Kyle Moffett wrote: > If DRM is built-in, then AGP _must_ be built-in or not included at > all, modular > won't work. If DRM is modular or not built, then AGP may be built- > in, modular, > or not built at all. > > The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or > AGP=n, and if > DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n. > > Yes it's unclear and yes it should probably be documented in a > comment somewhere. could be written easier as depends on AGP if AGP --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux OpenGL ABI discussion
On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote: > Some of the topics raised include: > > - minimum OpenGL version required by libGL > - SONAME change to libGL > - libGL installation path I think the single most important point is to explicitly disallow vendor-supplied libGL binaries in the LSB. Every other LSB componenet relies on a single backing implementation for a reason, and in practice the Nvidia libGL just causes endless pain where people acceidentally link against it. The DRI libGL should be declare the one and official one, and people who need extended features over it that aren't in the driver-specific backend will need to contribute them back. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux OpenGL ABI discussion
On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote: > http://lists.freedesktop.org/archives/dri-egl/2005-July/000565.html > > In particular, Andy's response about why they're uninterested in a common > libGL is basically The Last Word on the subject. It would require that > nvidia expend time, effort, and money to get to the same level of > functionality they already have. This applies equally to any other IHV, and > to ISVs like XiG and SciTech too for that matter. You can have whatever > opinion you like about that stance, but it's simply an economic reality. And it's a we shouldn't care about their economic issues. Giving them a branding only if they play nice with the open source world is one of the few powers we have. And replacing system libraries is not something we can allow anyone. It's totally reasonable to have different 3cards in the same systems and they're supposed to work. Where would be get if every scsi card came with it's own scsi stack and you could just use one brand at a time? Sure, we can't forbid scsi vendors to do that, but we do everything in out power to avoid it - quite sucessfully so far. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote: > Hi! > > It appears that GPL'd DRM drivers for closed-source user-space clients > are becoming more common, and the situation appears to be causing a lot > of unnecessary work from people wanting their drivers in the mainstream > kernel. Arguments against pushing upstream include. > >* Security. >* User space interface validation and maintainability. >* Politics There are also useless. > Security: > I think from a security point of view, open docs and a thorough > documented security analysis by the driver writer should be sufficient. > This should include: I think you're just trying to push your agenda. Every closed driver I had access to was an utter piece of rubbish so far, and you'll need the code to prove otherwise. > User-space interface: > Historically driver-specific interfaces have really been up to the > driver writer and when posted for review they receive very little > comments unless there are things like 64/32 bit incompatibilities etc, > but as mentioned on the list, small programs that demonstrate the use of > all interface functions would be desirable, and very helpful if someone > decides to do write an open-source driver. Unless you actually have a generic userspace working with all drm drivers you'll also have a very hard time claiming it's not a derived work of the kernel drm. Nevermind code not having open userspace is impossible to test properly. > Politics: > It's true that sometimes some people don't like the code or what it > does. But when this is the underlying cause of NAK-ing a driver I think > it's very important that this is clearly stated, instead of inventing > various random reasons that can easily be argued against. How should the > driver writer otherwise get it right? Man-years might be spent fixing up > drivers that will never get upstream anyway. I think you're just trying to defend your business writing closed source drivers. Drivers that aren't usable without binary blobs don't have a business in the kernel tree, and your whining doesn't help it. You'd be better off spending your time getting proper open drivers done than defending doing the work to support closed binaries. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 04:52:26PM +0100, Matthew Garrett wrote: > I think "tightly integrated" could do with some clarification here. > qcserial was accepted despite not being functional without a closed > userspace component - an open one's since been rewritten to allow it to > work. Do we define "tightly integrated" as "likely to cross the GPL > line" (potentially the case with Poulsbo, not the case with qcserial), > or is it a pragmatic issue? What about specialised hardware drivers that > only have closed applications? Greg still claims that qcserial could be used by rebooting from Windows, right? In that it would still be extremly borderline to me, but it's settled now. We also have various SCSI HBA drivers that can be used just fine, but contain tons ot ioctls for management tools that aren't available as open source (or even easily obtainable at all). Personally I don't think we should merge those unless we have userspace code available freely, but it's a less urgent issue than merging drivers that can't be used at all. The DRM modules fall to me exactly into that category for "specialised hardware drivers that only have closed applications", and the answer to those should be a clear no. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
mmap abuses in drm
Folks, could someone explain what the heck is going on here:
static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
{
drm_file_t *priv = filp->private_data;
drm_device_t *dev = priv->head->dev;
drm_i830_buf_priv_t *buf_priv = buf->dev_private;
drm_i830_private_t *dev_priv = dev->dev_private;
const struct file_operations *old_fops;
unsigned long virtual;
int retcode = 0;
if (buf_priv->currently_mapped == I830_BUF_MAPPED)
return -EINVAL;
down_write(¤t->mm->mmap_sem);
old_fops = filp->f_op;
filp->f_op = &i830_buffer_fops;
dev_priv->mmap_buffer = buf;
virtual = do_mmap(filp, 0, buf->total, PROT_READ | PROT_WRITE,
MAP_SHARED, buf->bus_address);
dev_priv->mmap_buffer = NULL;
filp->f_op = old_fops;
if (IS_ERR((void *)virtual)) { /* ugh */
/* Real error */
DRM_ERROR("mmap error\n");
retcode = PTR_ERR((void *)virtual);
buf_priv->virtual = NULL;
} else {
buf_priv->virtual = (void __user *)virtual;
}
up_write(¤t->mm->mmap_sem);
return retcode;
}
(and same crap in i810_dma.c aswell)
Overriding the file operations just for mmap is for one thing racy
as hell and for another very fragile as the mmap and nopage routines
have to agree closely on what to do.
Even further why in hell do you call do_mmap from a driver? Mapping
memory into userspace from anything but syscall dedicated to it is
surely a desaster waiting to happen.
Is there any chance we can get rid of this crap (and similar stuff in
drm_bufs.c) as part of the memory manager overhaul? Long-term I'd
like to get rid of the do_mmap(_pgoff) export to avoid that people
introduce similar braindamage again.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM kernel module can not be compiled pass with compat32 mode
On Thu, May 31, 2007 at 05:11:22PM +0800, Wu, Nian wrote: > Then I compiled DRM kernel module, it reported below error info: Don't do this. Always use the in-kernel drm. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 00/23] drm: introduce drm_zalloc
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote: > Hello, > > As there are many places in drm code where drm_alloc + memset is used > this patch series introduces drm_zalloc and also makes use of drm_calloc where > needed. Most of these patches save some bytes so the benefit is a few kB saved > (gcc 4.1.2) with patch applied. Also some small (style, etc.) things are > fixed. > This patch series does the conversion drm tree-wide. All patches were compile > tested. Please just convert it to plain kzalloc/kcalloc and kill these utterly useless wrappers instead. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 00/23] drm: introduce drm_zalloc
On Thu, Aug 30, 2007 at 12:20:32PM -0400, Kristian H?gsberg wrote: > > The wrappers aren't useless the drm alloc/free passes in a memory space > > for debugging purposes so we can track memory abuse when developing, > > Do we ever use that, though? Having to pass in the pointer, the size > and the area just to free memory, sure is a bitch. Note the slab has a memory tracking feature that accounts memory to callers of the allocator. IF that's not enough for you please help improving the common code instead of inventing your own. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
