Date: Thu, 29 Aug 2013 18:16:49 +0200 From: Matthew Rezny <mrezny@hexaneinc.com> To: Niclas Zeising <zeising@freebsd.org> Cc: freebsd-x11@FreeBSD.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130829181649.0000788c@unknown> In-Reply-To: <521E5CA0.6080206@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Aug 2013 22:25:04 +0200 Niclas Zeising <zeising@freebsd.org> wrote: > On 08/28/13 17:15, Matthew Rezny wrote: > > On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising > > <zeising@freebsd.org> wrote: > >> On 08/28/13 06:20, Matthew Rezny wrote: >=20 > >> Our old xorg is blocking other ports from updating, so while it > >> might not directly bring new features from your point of view, it > >> is blocking new features in other areas. > >>=20 > > What I meant was no user noticeable features in Xorg stack itself. > > I understand some other software running on Xorg might like a newer=20 > > version, but from a user perspective the older versions of that=20 > > software with working hardware rendering are more usable and useful=20 > > than newer versions stuck on software rendering. Any new features > > are nothing more than theoretical if there is no practical way of > > running them. >=20 > You are missing the point. Some software needs updated xorg stack, > because of lacking features or bugs in our current xorg. If we can't > update those packages, we are missing out on features there, and that > might in turn stop other updates. > Besides that, our current xorg is lacking support upstream, meaning > security isses might go undetected, or we need to backport patches, > which takes time and effort. >=20 Sorry, but it is actually you who misses the point. It matters not what new features are in the updated software or what new features are in the Xorg stack. If there is not a working driver then the Xorg stack is useless and thus all the software that depends on it is also useless. It can have a million new whizbang features but all that means nothing if I can't run the Xorg stack due to missing/non-functional drivers. Miss out on new features, or miss out on all of it, which is worse? Answer should be obvious. Also, "upstream" does not support our platform so we must support ts ourselves regardless what version it is. We had a version that worked thanks to the effort of you and others. It's great to know that a newer version is in the works, but until it's fully baked, don't take away what we already had working. To throw it away away prematurely is not only frustrating for those who were using it, but it also makes waste of the past efforts. >=20 > >> What versions of relevant software are you using? Do you have a=20 > >> xorg.log file to show us, so that we can see what's going on. > >>=20 > > Unfortunately, not at the moment. Relevant versions of Xorg/Mesa > > stuff is too tangled a mess to possibly remember off the top of my > > head. I can't provide an Xorg.log until I replace some hardware. The > > desktop 890FX/PhenomII/HD4870 is having instability problems due to > > VRM cooling issues on the motherboard. While diagnosing the problem, > > I pulled all the hard drives except one which has Windows7, > > primarily to prevent creeping data corruption on the FreeBSD > > drives. When I get the motherboard replaced, then I can follow up > > on this properly. The TurionII/HD4200 laptop is running Windows7 as > > I gave up on using FreeBSD on it months ago. When it had working > > R600 DRI then it was quite usable under FreeBSD with the only > > caveat being the lack of GPU power control meant battery life was a > > little short. Without functional hardware rendering, not only was > > it frustratingly slow, but the increased CPU load impacted battery > > life to the point it was unacceptably short lived away from a power > > outlet. >=20 > Without a list of software, logs and other relevant information it is > impossible to help you and debug this issue. It is not very hard to > get a list of installed ports and packages, a dmesg output and a log > from xorg. >=20 I never said it was hard to do. I said I couldn't do it right this moment and gave the reason why. > As a side note, cooling issues can probably cause all sorts of issues > that doesn't seem related at first, so that might be a place to start. >=20 I am well aware that cooling issues can cause anomalous behavior. That is why I pulled all the harddrives except one. The drives I pulled contain my important data and the FreeBSD zpool. The drive that remains is the Windows OS and app drive, which is the easiest to recreate. It is also what I needed for hardware diagnostics to determine the root cause of the problem and is what I will need to validate the new board. If it gets hosed, I can re-install it fast. When I'm sure the hardware is back in good order, then I'll put the rest of the drives in and get all that you ask. >>=20 > >>> I could almost understand if there was some actual problem with > >>> the R600 DRI, but there isn't. Starting X results in the > >>> software rasterizer, which makes KDE painfully slow . However, > >>> running certain apps I get hardware rendering. i.e. OpenArena > >>> loads r600_dri.so instead of swrast and the framerate in timedemo > >>> clearly slows hardware rendering is in fact working. Why can a > >>> game get hardware rendering but the rest of X can't? > >>=20 > >> Once again, what version of libGL and libdri and drm ports are you=20 > >> using? Are your ports tree up to date? Are you using > >> WITH_NEW_XORG or not? > >>=20 > > See above about version numbers. Port tree was up to date on the=20 > > desktop. I've been running 9-STABLE with ports updated monthly. I > > was not using the WITH_NEW_XORG recently as my understanding was > > that should only be turned on (at that point in time) for Intel KMS > > testers (not sure if can really call any of them users given the > > current state). >=20 > WITH_NEW_XORG=3D is usable for other hardware configurations as well, > and with the addition of the radeon KMS driver, it should work fine > even with radeon hardware. It might need some polish in the ports > department to get optimal performance, but we are working to get that > into the tree in time for 10.0. >=20 At this moment in time I'm not even sure what WITH_NEW_XORG means in terms of versions so I can't really guess at what it does and doesn't work with. What I know is that radeon DRI does not work with or without it when I last tested flipping the switch. The wisdom I remember reading in the past in regards to the switch was that leaving it off should be the version where DRI works, setting it on would get new Xorg which breaks DRI for sure, unless WITH_KMS is also on, in which case DRI works but only for Intel KMS. >>=20 > >>> Considering how far off KMS support is, I would hope this issue=20 > >>> would have been addressed by now. From my viewpoint, it looks > >>> like some stupid and likely trivial bug that causes Xorg to load > >>> swrast instead of r600_dri, but I haven't the time nor patience > >>> to dig through the mess that is Xorg to attempt to figure it > >>> out. > >>=20 > >> Considering KMS for Ati/Radeon cards already hit the tree, I think > >> it is safe to say we have been busy elsewhere. > >>=20 > > I recognize it is in the tree. In fact, its landing in the tree is > > what provoked me to respond to this PR at the this time. However, I > > just saw a statement somewhere on wiki or ML that it would not be > > ready for real use for another 1-2 years. From the announcement of > > it coming into -CURRENT, I get the impression it is really not > > usable beyond testing. Lacking a working console after Xorg loads > > is a total show stopper in my opinion (and why I can't call the > > Intel KMS stuff anything more than testing a year after it went in > > tree). Sure the serial console works, but that is only practical > > for testing, not daily use as a desktop. Forget use on a laptop as > > I haven't seen a serial port on one of those in a LONG time, not to > > mention the impractically of carrying some other device to be the > > console for my laptop, already a device that is massively inferior > > to a desktop in every way other than portability. >=20 > I doubt it is 1-2 years away, where did you see that mail? Of course > there will be some bugs, as always, but it has been in the works for > some time, and it has been tested and deemed ready for a release > (10.0, which is due in a couple of months). With regards to VT > switching, I can understand that it is an issue, but it is something > that's actively being worked on, and the plan is to have it resolved > before 10.0 as well, so FreeBSD is really making progress in the > graphics and desktop department. >=20 I am going by what you said last month: Niclas Zeising on Tue Jul 9 18:50:47 UTC 2013 "The reason we haven't updated to xserver 1.14.1 is partly that it is untested, and also that some drivers, most notably the UMS version of the ati driver, no longer works with this version. We are currently at version 6.14.6 of the ATI driver, which is the last to not need KMS. This will be updated some time after the ATI KMS work in the kernel is completed, and possibly merged back. This means that this work is probably a year or two (at least) away." Maybe I misinterpreted that somehow so correct me if I read it wrong. It is good to hear the VT switching issue is being worked on with intent to have it resolved by 10.0. That is much more reassuring than the last message I saw on the ML on the topic. Raphael Kubo da Costa on Fri Jun 21 12:34:54 UTC 2013 "Niclas Zeising writes: > while the VT switching issues are being worked on. Side question: is someone currently working on this? I assumed nobody had picked up that part of the work and kib wasn't interested in it." >=20 > > I do not intend to come across as unappreciative of the KMS work, > > but I'm being realistic. I understand the motives for choosing the > > ordering for KMS development. First came Intel due to the large > > number of laptops with integrated Intel graphics that didn't even > > have UMS support. Next comes ATI/AMD that needs to migrate from UMS > > to KMS for support of newer hardware. Last shall be Nvidia since > > there is a vendor supported binary driver that is sufficiently > > usable for most with that hardware. Anything else but the current > > "Big 3" will be left to rot since Xorg/Mesa are dropping/have > > dropped UMS support entirely without regard to the vast amount of > > hardware that is still in use and working perfectly well on older > > versions of the stack. The overall approach makes logical sense, > > but the problem is this gap in which UMS support is rapidly > > decaying before KMS support has graduated from it's testing status. > > Prior to the KMS mess, Radeon r100-r700 was the best supported GPU > > hardware under FreeBSD using open drivers and I'm surely not alone > > in having used that to guide hardware buying decisions over the > > last several years. The UMS support needs to be maintained in a > > better state until KMS is truly ready to supercede it, meaning not > > only have OpenGL actually work beyond trivial demos, but more > > importantly a console that works at all times. Even once we have > > newcons running atop DRM drivers, I still see immense value in > > having a method to switch back to text mode with the traditional > > console. Being able to reliably see a panic and get into the > > debugger without relying on serial ports pretty much requires a > > text mode fallback. That combined with how far in the distance > > newcons is means it should be a priority to devise a solution to > > get back to text mode now. >=20 > The problem is that we are in the hands of upstream development. > Linux has had KMS for quite some time, so it is natural that xorg is > starting to chop of support for UMS. And we need to get on that > train, or get left in the dust. The FreeBSD x11@ team is stretched > for resources as is, so we need to focus on what is important. And > newcons isn't far in the distance, it is happening. We have always been at the mercy of upstream to some extent. Yes, they have been doing KMS for a while. Yes, we need to do KMS too. That does not mean we need to throw UMS support out the window. We need to keep around the UMS support for the foreseeable future. When the day comes that all hardware supported by UMS is supported by KMS, then and only then can we safely throw away UMS support. As it is now, some hardware is vesa only on Linux but still properly supported on FreeBSD using the older Xorg. That is a good thing for us. > With regards to nVidia, why should we not use the official binary > blobs? They work (last time I heard) and are supported upstream. I > doubt we'll ever see any KMS driver for nVidia graphics cards as long > as we have this support. We are not Linus, giving the finger to all > vendors who want to support our operating system, just because they > might use a different license than the core OS uses. How far along > is the linux KMS work for nVidia hardware? The reason to not use the official binary blobs is they don't support everything. Last time I looked, the nvidia hardware support was divided across no less than three, maybe even four driver versions. Only the newest hardware is supported by the current driver which works with current Xorg stack. All the previous driver versions for the "legacy" hardware are considered "legacy" drivers and not maintained. They don't work with current Xorg stack on either FreeBSD or Linux. I cannot speak to the quality of the open drivers on Linux as I have not been using them. The nvidia hardware I have is sitting in boxes that only need text mode because there was no viable driver for any other use of it. =46rom reading the status of the nouveau project, they have a driver that is at least better than vesa (2D accel and some 3D support) which supports all nvidia hardware with the GeForce name (and maybe even some TNT stuff but not the early Riva). That goes back further than any of the nvidia legacy drivers iirc. Relying on vendor drivers leaves us at their mercy, and when it's a closed driver there is no way for us to fork it when "upstream" (vendor) drops support. Additionally, even when it is still vendor supported, we can't fix bugs ourselves. Those factors are part of why we are using an open source operating system in the first place. > Lastly, last time I checked most drivers compiled fine with the new > xorg distribution, and even with xserver 1.14 which is in experimental > testing. Unfortunately we (the x11@ team) can't test every > conceivable combination of hardware, so there might be some issues. > On the other hand, there have been few complains about video hardware > and drivers not working, so either noone is using those drivers, or > they work ok. >=20 Working drivers are one thing. Working DRI is another. Yes, the ATI driver still works for 2D and that is better than running the vesa driver. The DRI doesn't work for Xorg so that means no 3D/OpenGL in general. That is a regression since it used to work. Since a few programs can load the DRI driver directly, it's clear that the DRI driver works and the problem is Xorg forgot how to talk to it. That should be fixable. >>=20 > >>> Considering the recent suggestion of flipping the WITH_NEW_XORG=20 > >>> switch, which itself is very ambiguous, I must re-iterate a > >>> previous suggestion: Instead of having a single set of ports for > >>> Xorg, PLEASE make some versioned ports for the older versions. > >>> This would allow the "legacy" hardware (as in what I think most > >>> of us are actually using) to continue to function in a useful > >>> fashion. Considering the precedent of version-named ports (e.g. > >>> postgresql, mysql, bdb, etc), I cannot fathom why this is not > >>> done for Xorg/DRI/Mesa. > >>=20 > >> What is the problem with the name of the switch? It is fairly > >> clear what it does in my opinion. > >>=20 > > The problem with the switch is that it is relative. Someone who may=20 > > have had to flip it on at one point in time will later have to turn > > it off to retain the same working Xorg version. If they update > > ports without flipping the switch at the right time, getting back to > > working can be a nightmare. Further, the single switch only supports > > two version sets existing at any point in time. In the past, when > > there was both WITH_NEW_XORG and WITHOUT_NOVEUA switches, there were > > three possible version combinations controlled by two switches. That > > is in fact the last time anything worked for me (both set ON). In > > theory, after WITHOUT_NOVEUA went away, I should have been able to > > flip WITH_NEW_XORG to OFF and retained the same working > > configuration, but in reality that was not the case. It did not > > matter if the switch was ON or OFF, neither version would load the > > r600_dri.so when starting Xorg. I reported the problem on IRC and > > was told that was strange and shouldn't happen, but now we have a > > PR (the one I'm responding to) that says it is essentially expected > > behavior for the UMS driver that won't be addressed. >=20 > This is why we're slowly working towards getting one unified version > of xorg again, but it takes time, both because we need to port > software, and because the FreeBSD kernel and core system needs to > "catch up" in terms of new hardware support. Why unify? We should have one Xorg stack version that is frozen at the point where UMS reached it's peak. That version can be patched up with bug fixes as need be. The new KMS version is effectively a fork which should have separate ports to allow it to move forward without breaking the old UMS stack. > Currently there are two distributions, the old one, which is xserver > 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions of the intel > driver that doesn't support any modern intel GPUs, and so on. > And then there is the new distributions, which needs a modern FreeBSD > with support for intel KMS if you have a intel GPU, xserver 1.12, mesa > 8.0 and so on. So I'm not the only one who can't remember what versions correspond to the possible switch options... > I understand that it can be troublesome moving between versions. We > are doing our best to make it work, but sometimes issues occur, > especially when moving backwards, since that means ports versions > going backwards. The WITHOUT_NOUVEAU option was removed some time > ago, since NOUVEAU never really worked well on FreeBSD, as I've come > to understand it. >=20 That is exactly why versioned ports would be a benefit. It is troublesome to go backward in versions, so it should be avoided. With the ambiguous switch, one can too easily go forward by accident and then it's difficult to go back. With a versioned port, it would be easy to stay on the version that works. The reason that nouveau has not worked well on FreeBSD is that it requires both KMS and gallium. The very early versions that worked with UMS were only the start. With KMS arriving sooner on Linux, the nouveau project decided early on to go KMS only. That makes sense for them. When we have KMS and gallium support ironed out with Intel and ATI, then it should be less difficult to bring in a current nouveau driver for those that want to not use the official nvidia binary blob, either on principle or because they have older hardware that is only supported by legacy drivers which only work with a legacy Xorg stack. >=20 > >> The problem with versioned ports, apart from the fact that it > >> probably would increase our workload even more, is that it is very > >> hard to get a port to depend on different versions, with different > >> shared libraries, functions, etc. etc. You also have to remember > >> that xorg and mesa is a package, and mixing up versions in general > >> won't work. > >>=20 > > I know they are a package that need to have versions kept in sync. > > That is exactly why I advocate versioned ports. Having versioned > > ports would make it easier to keep those in sync as the ports could > > depend on the correct version and updating one would trigger others > > to the updated. Currently, when the switch is flipped, all the right > > ports need to be rebuilt in just the right order and it doesn't > > always work. Sometimes it in necessary to unistall them all and then > > rebuild everything to get Xorg to even start. I have seen numerous > > others on IRC and the ML facing the same problem. I tried freezing > > portions of my ports tree and selectively going back in time, and > > while that worked briefly, it became an unmaintainable mess over > > time and I gave up on it, resulting in spending progressively more > > time in Windows on my desktop (even before the hardware problems) > > just to get anything done. FreeBSD still runs all my server > > hardware with text consoles quite nicely. >=20 > Well then, how do you solve it if you have an application foo, that > wants libGL and xorg-server? Which version should it depend on, libGL > A.B or libGL X.Y? How do you solve that, especially for a binary > package? You can't, not with our current package manager at least. > If you install the package foo, you'll get the default versions of > libGL and xorg-server, otherwise you'll have to compile yourself > anyway. It is exactly the same now. >=20 For ports, look at the gcc situation. Some have gcc=3Dany, some have gcc=3D4.2, some have gcc=3D4.4+, some have gcc=3D4.6+, etc. It's clearly possible to say it doesn't matter, only an old version, or only version at least as new as X.Y. It should be possible to do so for the Xorg stack as well. The ports that make up the stack can be kept in sync by having the old UMS stack ports pinned to the old version and new KMS stack held together by new_version+. For X apps and libraries, anything that needs old or new can specify it. Anything that does not say can be assumed to be Xorg=3Dany. This would not be exactly how it is now. This would be manageable. As for the binary packages, I think it's solvable by depending on the proper library version, but don't quote me on that. >=20 > >> And lastly, even if we would have versioned ports, binary packages=20 > >> still would have to depend on the default version (same for perl,=20 > >> databases and so on), so it wouldn't gain you very much anyway, > >> since you would need to compile stuff from soruce to get a > >> nondefault version. Then you might as well just select version in > >> /etc/make.conf and then compile xorg to begin with. > >>=20 > > In that case, at least there would be binary packages of each > > version rather than only for the default version. Binary packages > > are meaningless to me. I have to build everything from source to > > get working OPTIONS combination anyway. At least with versions I > > could be sure I'm building what I think I am/what I know I need. > > Using versioned ports would not only allow me to retain the known > > working versions, but would make it more clear what other software > > has to be frozen at a particular version to continue using it. > > Without that, it is rather unclear what are the exact repercussions > > of staying on older Xorg stacks. I see things like the databases > > and Python/Perl as great examples of what benefits versioned ports > > bring. People relying on older versions of those ports can do so > > with confidence while newer versions become available to those that > > need them. At the same time, those relying on older versions can > > move forward to new versions in testing environments, rework their > > software as needed, and eventually migrate to a newer version with > > confidence. Without versioned ports, updating the ports tree is a > > game of Russian roulette. When it comes to the Xorg stack, it feels > > like there is only one chamber without a bullet. >=20 > Binary packages are of no interest for you, maybe, but you are > forgetting the bigger picture. It has to work as well, and all this > has to work for everyone, with different versions of FreeBSD, > different hardware, and different requirements. Can you maybe see > now why it is actually a quite time-consuming effort to maintain this. > Versioned ports would only give us even more to support, with little > gain. If you set WITH_NEW_XORG, you get the new xorg distribution, > comprising a set of N ports, with specific versions. If you don't set > it, you get another set of M ports with specific versions, those sets > might overlap, but not everywhere. You can't, however, pick different > versions of different ports, they have to work together. And you > can't install them side-by-side. While it might be possible to > version the ports, I doubt it. This discussion has happened before, > and I have still not seen any progress. > You still can choose which distribution you want, by setting *one* > option. >=20 Perhaps I should have said the provided binary packages mean nothing for me. The provided binary packages are always default options, which are rarely if ever suitable. For some people they are fine. They might even be handy for quick testing to see if it's worth compiling a port with custom options. Now that we have pkgng and poudiere, personalized binary packages become a reasonable form of testing and past version preservation. Sometime after I have my desktop back up and running, I intend to make use of those to see if I can improve this situation. My plan is to setup a build jail with an old version of the ports tree (real old, a year or more in the past). I will initially build everything from that old version. Then, I will slowly roll the tree forward, rebuilding all ports that change each step of the way. When the ports tree is up to current I should have a personal binary package repository with a nice history of the Xorg stack amongst other things from which I can cherry pick. I can quickly switch around versions by just uninstalling one package and installing another, much faster than building the ports again and again with different options and much more manageable than trying to take portions of the ports tree back in time as I had previously done. The only tricky one is the Xorg stack for which I need ports built with the WITH_NEW_XORG switch both on and off. The best solution that comes to mind at the moment is to construct slave ports that set the switch and build those slave ports so I get Xorg_foo_OLD and Xorg_foo_NEW packages. The statement that the ports might be versionable but you doubt it makes no sense. The ports that have the switch already have two versions smashed into one port. To separate them is a matter of making two ports, one that follows the flow with the switch off and the other that follows the flow with the switch on. Someone with good script-fu could probably automate this process. For personal reasons I can't commit to doing this on any timeline, but I will share my work if and when I get around to doing this. It is, after all, the backup plan should the aforementioned slave port idea not work out as hoped. > Besides, if we on top of different versions here, start adding > different versions of other ports, you can soon follow that the > dependency related issues will explode. > >=20 > > It is my opinion that the primary factor holding back the "Linux=20 > > desktop" (and by extension use of FreeBSD as a desktop OS) is the=20 > > complexity and mess of Xfree86/Xorg. For more than a decade now, > > I've periodically tried both for desktop use and always found that > > the disaster that is X keeps me from being able to use it as such > > for more than a brief stint here and there. For a long time I used > > OS X as my desktop and regarded FreeBSD as a server OS, but with > > what Apple has done in the past few years OS X is as bad if not > > worse than Windows. As a former OS/2 user that sees Windows 2000 as > > the peak of Windows usability, and OS X 10.5 as the peak of Mac OS > > usability, I find myself so desperate for a usable desktop OS that > > I almost bought an Amiga X1000. Fortunately, MorphOS released 3.2 > > with PowerMac G5 support just in time to allow me to give that a > > spin on my old Mac without dropping significant coin on new > > hardware. Still, I'd like to see the non-Mac "UNIX desktop" > > eventually reach a state where it can be practically used as an > > everyday desktop OS. With it being so difficult for a highly > > technical (programmer) user to do so, it is obviously impossible > > for any "normal" user to do so. No surprise I see people frustrated > > with Windows installing one of the "easy" Linux distros, and then > > after a couple months at most, giving up and either going back to > > Windows or buying a Mac. I can only hope that Wayland is magically > > better, but the realist/pessimist portion of me fears that it will > > be too Linux centric, a nightmare to port, and still have no stable > > ABI. Lack of stable ABI in Linux is the secondary factor that > > prevents any real success outside the server space where admins can > > dedicate their lives to chasing updates and/or backporting bug > > fixes and required features. At least FreeBSD has a sensible way of > > versioning the ABI that allows it to be much more sane and really > > excel in that exact same space since it requires less effort to > > maintain production systems and can even be a better Linux than > > Linux in terms of running older Linux binaries on current OS > > versions. >=20 >=20 >=20 > xfree86/xorg is a complicated beast, that's why we're working on > porting it and making it as easy to use as possible. I've been using > FreeBSD on my both my laptop and desktop for quite some time, without > any major hassles. I even run our testing versions, to start ironing > out issues and bugs before the rest of the community sees our > requests for further testing. > As stated before, we do our best to test this, but the sheer variety > of hardware out there makes it impossible to cover all corners. > I have friends that use some free operating system or another without > any hassle with X, and I sysadmin several Linux boxes with desktop > environments in the computer club at the university I attend. Not to > mention that the university also uses linux, so saying that the "UNIX > desktop" is a no-go is clearly wrong. >=20 The lack of testing capacity is one more reason to carefully preserve the UMS Xorg stack in a usable and easily obtainable state before we go too much deeper into KMS territory. Of course a University, with it's IT staff dedicated to the task, can manage to maintain a group of UNIX desktops/workstations with Linux and *BSD just as they had done with the proprietary UNIX workstations of the past. The little rant I put after the meat of my post was more about home and small business users without the support staff dedicated to such efforts. If it's hard for me to maintain my own personal systems, it's nearly impossible for the non-technical users. How many years has one of the major industry magazines run a "Is this the year of the Linux desktop?" cover story? I've been seeing at least one a year for no less than a decade. Each time there's a reason why THIS year will be THE year as opposed to all the others. They always miss the mark. Some businesses and governments have done Linux desktop projects and some have worked, but also some have not and they've gone back to Windows. For all those that went back, chances of them even giving Linux or another "UNIX desktop" (OS X aside) a try in the feature are slim to none. Once burned, twice shy. > Remember also that FreeBSD, and the ports collection, including all > relevant software for this discussion (except the nVidia drivers) are > open source. Feel free to help out, experiment and send patches, > that's how we in the x11@ team ended up here. And while it doesn't > seem like much, some of us spend in excess of 40hrs/week some weeks, > to make all this work. >=20 I think that we all understand this point. That is after all how we ended up here. Frustrated by vendors dropping support for the platforms we loved, or sabotaging the versions we enjoyed in an attempt to force us onto their vision of the future, is the reason we end up using open source software. If the original author drops it, so what? If it has value, the users who care can choose to continue on with it to the best of their abilities. Unfortunately for Xorg, the value is the apps that run on it more-so than the Xorg stack itself. That combined with the complexity limits the number of people willing to bury themselves in maintaining it at any version. It is not my ideal, but I would happily put 40+hours/week into it if doing so could keep food on my table, a roof over my head, and the lights on (ok, I can forgo lights, I just need the computers to stay on). A myriad of personal problems has meant that I haven't been able to do so much for Xorg/Mesa as I'm struggling enough to find sufficient paid work. If anyone wants to help change that, I'll commit to doing more for the community. Right now I must pick my battles carefully, meaning I can only put much time into advancing those aspects of my computing life that I depend on to do any paid work I can find, and that itself takes a back seat to simply finding suitable work to do. > Regards!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130829181649.0000788c>