Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
On Wed, Nov 24, 2010 at 02:56:32PM -0700, Matt Dew wrote: This I'm curious about. Are there more companies that feel it's too-hard/not-worth-while for companies to contribute stuff to Xorg? I know the linux kernel has this issue, but is X's contribution difficulty larger? I think X faces the problem that our approach to code quality is pretty similar to the kernel, but the number of skilled coders with domain experience is much smaller. There's a pretty strong cultural mismatch between our willingness to accept patches and people's willingness to submit them. Vendors are willing to argue that their component suppliers have in-kernel drivers, but X.org's modular development model makes it far easier for those suppliers to argue that an out of tree X driver is equivalent to something that's maintained within X.org. The unsurprising outcome is that drivers in X.org only tend to be regularly updated if they have someone who can work with the X.org community. If they don't, it's far easier to keep the code in their own tree. Working out ways to improve this situation would seem worthwhile, but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) I think that is a little naïve. There is a difference between vendors attempting to use Xorg as a dump and run for crap code, and being a bit more relaxed about obscure drivers that are otherwise unmaintained. The latter makes a good ground for people to learn the craft, as indeed can staring at some of the finest vendor Vogon poetry and turning it into something resembling C to help get it upstream. X is a bit odd in other ways - it's history has been rather closed at times which hasn't helped as it means there isn't a long standing large developer base. It consists (for much of the relevant stuff) of a very small number of very large and very complex drivers for insanely complex bits of hardware. That doesn't have the same scaling for newbies the kernel does where there are hundreds of random USB widgets you never knew you needed that make good starting points. Maintaining the old Voodoo2 driver was a bit like minor kernel hacking. I can't even imagine how KeithP fits everything he needs to know for the intel drivers into his head. Alan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
On Thu, Nov 25, 2010 at 09:23:38PM +, Alan Cox wrote: but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) I think that is a little naïve. There is a difference between vendors attempting to use Xorg as a dump and run for crap code, and being a bit more relaxed about obscure drivers that are otherwise unmaintained. I don't entirely agree. If people provide code review and the vendor maintainer's attitude is approximately We're only willing to work with you if you accept our approach, I don't think that benefits us. It can be an opportunity for learning - I'm just not sure that it has been in the real world, so far. X is a bit odd in other ways - it's history has been rather closed at times which hasn't helped as it means there isn't a long standing large developer base. That's certainly true. The small number of developers has been a longstanding issue, and the fact that companies can't really just pick up an existing developer makes all of this much harder. It consists (for much of the relevant stuff) of a very small number of very large and very complex drivers for insanely complex bits of hardware. That doesn't have the same scaling for newbies the kernel does where there are hundreds of random USB widgets you never knew you needed that make good starting points. Maintaining the old Voodoo2 driver was a bit like minor kernel hacking. I can't even imagine how KeithP fits everything he needs to know for the intel drivers into his head. The lack of documentation for various aspects of the server doesn't help either. I found X development far more intimidating than getting involved in the kernel. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg 7.5 freezes after Linux kernel upgrade
On Wed, Nov 24, 2010 at 11:39:18AM -0500, Alex Deucher wrote: On Wed, Nov 24, 2010 at 11:02 AM, Jeremy Henty onepo...@starurchin.org wrote: I am currently happily running Xorg 7.5 on Linux kernel 2.6.35.8 . If I upgrade the kernel to 2.6.36 the screen goes black (even with the -retro argument) and the system locks up. Ctrl-Alt-Fn and Ctrl-Alt-Del do nothing, but Alt-SysRq-r followed by Ctrl-Alt-Del reboots cleanly. Do you have kms enabled in your kernel config? On both my current kernel and the new one, grepping the config for KMS gives: CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_RADEON_KMS is not set Does that make sense? I generated the new kernel config with make oldconfig and chose default options everywhere (except for enabling some of the new netfilter/iptables targets). Try booting with radeon.modeset=0 on the kernel command line No change, I'm afraid; same result, identical X server logs. or make sure the radeon drm is loaded before starting X. My kernel in non-modular so I think that's not an issue. Thanks for your help, Jeremy Henty ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
