Slashdot Mirror
X.Org Server 1.11 Released
An anonymous reader writes "Phoronix is reporting that X.Org Server 1.11 has been officially released to users of Linux and other operating systems. This time around their reporting is more detailed than the official release announcement."
Is it just me, or are most open source project "official" releases getting rather humdrum?
If I have a bug that needs fixin', I use the beta (or just apply the patch(es) manually). If I don't, I generally don't fix it until a feature it has seems interesting, or my package manager says "omg you need this!".
Version 10.00 is just around the corner.
http://michaelsmith.id.au
If you had read the article you would have seen that nVidia's binary blob already supports it and Ati's isn't far behind.
Shh.
I'm pretty sure it's just X crashing, have you tried SSHing in?
--sitharus
The NVidia driver is directly accessing the hardware so when it goes there isn't much X can do about it.
Nvidia is notorious for that. Linux introduced kernel tainting when non-Free modules were loaded specifically so developers wouldn't waste their time when the oops was just yet another case of the Nvidia driver crapping all over everything.
So X is Robert and Wayland is Joffrey? Of so, I really hope Unity is Ned.
PlusFive Slashdot reader for Android. Can post comments.
I mentioned about this a while back on OSNews when I got my new laptop and noticed that it has two graphics cards instead of one: the other one is a higher-powered one able to churn away on games, 3D-modeling and whatnot at acceptable speeds, the other one is a very low-powered one that is barely able to do regular 2D sufficiently. The system switches between those two when I plug/unplug the AC adapter, though it also allows me to switch between them at will.
The thing here is that the low-powered one saves HUGE amounts of battery compared to the high-powered one, even if I go to such drastic measures as downclocking it. Using two separate chips instead of incorporating both in the same chip, or just having more aggressive power-saving capabilities on the more powerful chip is not the same thing for several reasons: being able to buy and use both chips separately means the manufacturer may be able to save money by buying different batches of chips from different places, and it obviously allows the manufacturer to mix-and-match at will. And adding more aggressive power-saving capabilities to a chip always means having to make compromises that could otherwise be omitted. It simply makes some sense to use two chips for saving battery, and I've noticed several manufacturers lately trying that. It remains to be seen whether or not it'll actually become a trend, though, or just a passing fad.
Unfortunately though X.org doesn't support such a scheme. You can't just switch between cards on-the-fly, you must muck around first, then restart whole X, thereby defeating the whole idea. And it doesn't seem like there are any plans for remedying this, or atleast I can't find anything relevant.
Unity is Jaime.
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Because Windows is 99.2% of the market and nVidia throws engineers at Windows drivers like firemen throw water at an oil refinery fire?
Because the nVidia marketing assholes have to be reminded on a daily basis that Linux (or OSX) even exists?
Because the Linux nVidia staff is three guys in a room who get less respect than a vomiting crack whore in the Sistene Chapel?
Idiot.
Starting from Vista, Windows runs as much as possible of the driver in userspace which means that if it craches it just restarts the driver resulting in a quick blink on the screen and you're back to normal.
Indeed. With Windows 7 being able to recover from a graphics driver crash and GNU/Linux not being able to I wonder what happened to the Unix philosophy...
Sometimes. I have a corrupt video that'll crash Win7 whenever DXVA (DirectX Video Acceleration) is enabled. It's pretty neat when it works though, because on Linux X crashing is as bad as the kernel crashing for a desktop.
Live today, because you never know what tomorrow brings
It's not always doing it, in fact.
If the driver somehow succeeds for instance to lock up the system bus, the game is over.
You can only TRY to recover when kernel-mode drivers do stupid things.
I haven't had such an instance myself. I've been overclocking my graphics cards like mad, doing this and that crazy stuff, and every single time the graphics card has locked up Windows has been able to restart the driver successfully. Not once has my system locked up completely due to graphics card - related issues. It's really handy and it still baffles me why X.org devs don't seem to consider doing the same thing.
Well how is Windows 7 doing it then?
Linux has a framework for some sort of recovery on GFX crash but that would require NVidia port their drivers to work with KMS and they havn't bothered.
You want changes? Make them. Start being a part of the solution rather than just complaining about things you don't like.
Ugh. That's really, really elitist, you know. Not everyone has the necessary skills and talent to work on the things that they wish improved, like some people are good at programming and others are good at writing fiction, or agility training, or architechtural design. Being great at agility training helps one in no way at all at improving X.org's graphics capabilities, for example.
You only managed to make yourself look like an elitist fool, nothing more.
I think saying "whoosh" is standard Slashdot etiquette.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
This is not really an X problem.
This is a Nvidia providing crappy drivers problem.
Also it means your system has also most likely been set to not restart the X server, if it did indeed crash.
What most likely is happening is it is stuck in a loop, which is is not exiting, or something along those lines.
Regardless, most likely you just need SSH in and restart X.
The good news is these days it very rarely takes the kernel down with it, at least in regards to FreeBSD.
Not if you have a VT220 on a trolley plugged in to your console port good sir :-)
The performance issues are not an X issue, but a driver issue.
The major issue when it comes to performance and X is the drivers, which are largely crap. Unfortunately there is very little information on the internals of most cards, which makes writing good drivers complex or damn near impossible. This also requires a nice bit of programming and math knowledge in various areas.
Changing graphics server technology won't fix this issue.
Your replying to a troll. If you waste your time like that replying to every troll etc in such a manner, you will have much wasted time.
What layers? Last I looked Xlib calls are all there are for low level graphics. Can you show me a system with fewer layers than X?
http://michaelsmith.id.au
Your replying to a troll. If you waste your time like that replying to every troll etc in such a manner, you will have much wasted time.
Well, good thing I have lots of free time on my hands then! :3
I stopped using Linux a year ago. It simply does not even begin to compete with Windows 7 anymore. Sorry guys, the train left and you are still on the station arguing about how to pack the luggage.
Can I light a sig ?
What linux developers? You act like the source code for the driver or the card specs are available to them or something
Sometimes the drivers can actually leave the keyboard and screen in a state where you can't do anything. The Magic SysReq key comes in handy here. Very occasionally, the kernel-mode portion of the drivers will actually somehow hardlock the kernel. Then the Magic Powerbutton comes in handy.
You forgot one important one:
Because Windows has a driver model and Linux doesn't?
Linux drivers are actually kernel modules, accessing things through constantly changing internal APIs. They are part of the kernel source and thus need said source - or at least the header files - to compile. And because the internal APIs are constantly changing, someone needs to keep maintaining the driver just to track the changes and dealing with them.
I don't think that Linux driver situation is going to change until this does, and I don't think that this is going to change, as it would interfere with kernel development, and kernel developers are in charge here.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
That's not what they mean here. They are talking about making input scroll events (mouse wheel, presumably) be less jumpy and more smoothed out. See this article: http://www.phoronix.com/scan.php?page=news_item&px=OTUyNw
I agree. Nothing can beat Windows 7 at taking 10 minutes to get to a usable desktop. Stupid Linux doesn't even try and gets me there in a piss-poor minute or so. Doesn't even bother reading the entire harddrive for god knows what reason!
It may also be my drivers, but I've found X on my laptop to be damn snappy, and it at least *feels* snappier than Windows 7 on the same machine.
This is what SSH is for. Unless the kernel has actually paniced, I've never seen a unrecoverable error in recent drivers for Intel or Nvidia.
Last I saw was with the S3 ViRGE, which post restart would have corruption issues unfixable except for a reboot.
Sometimes that isn't readily available. Also, chances are, if X has crashed, all the programs that you care about are gone too. You might as well power cycle, or use the Magic SysReq key to do a clean-ish reboot. If you can't use the Magic SysReq key, you probably can't SSH in either.
I'm on the same thoughts. Windows 7 is solid enough for an all-around machine, although it's still nice to have a Linux netbook around for hacking.
Nope. NVidia themselves say that API churn in Linux is not so bad: http://www.phoronix.com/scan.php?page=article&item=nvidia_qa_linux&num=7 In fact, you can check NVidia's compatibility layer (it's distributed in source code). It's tiny, any adjustments are easy to do.
Anyway, closed-source drivers are not going anywhere. OpenSource drivers are slowly (very slowly) catching up with them, and native Linux drivers have huge advantage, they JustWork(tm).
Which are the design problems you speak of? It's pretty simple.
Maybe RD doesn't have a lot of use for the average desktop user, but it is used in the corporate world and it is used by power users. Just because *you* don't use it doesn't mean nobody does.
> who are you to say the drivers are crap?
I'm the user - the one who actually uses them, and as such is the only person qualified to make the judgement. You don't have to be a whale to write "Moby Dick", and you most certainly do not have to be a contributor or even a developer to notice that your drivers are slow and buggy.
Maybe RD doesn't have a lot of use for the average desktop user, but it is used in the corporate world and it is used by power users. Just because *you* don't use it doesn't mean nobody does.
Here are some of the use cases where remote X has been important to me:
You could summarize these in the way that, for power use(r)s, the number of users is very different from the number of computers. For starters, I'm not going to buy extra monitors, keyboards and mice for all my machines, just because some desktop user thinks remote X is obsolete. In the case of supercomputers and similar specialist machines, it is physically impossible for all users to sit by the same computer. Plus it would be expensive (money, time, environment) for everyone to get there.
Many people argue that remote X can be replaced by more platform-independent systems like VNC. In some cases that is true; in fact, there are cases where remote X does not work, for example when the OpenGL/CL code need to run on the same machine as the rest of the program. On the other hand, VNC is often much heavier on the network, as it needs to transfer the entire bitmapped screen. For example, my fluid mechanics work involved relatively simple 3D modelling, and it worked fine over a 1-megabit ADSL and cable, but VNC is often sluggish even on a LAN.
Escher was the first MC and Giger invented the HR department.
Firemen know better than to throw water on an oil fire...
You can also think of the "network transparency" part as being a side-effect of the client-server model implemented by X, which fully isolates applications from the graphics hardware. That isolation contributes in a very positive way to system stability and portability.
And, once you have a client-server model, it doesn't really matter how far apart the two are. Hence the "network transparency" part.
Regardless, anyone who argues against X because of its "network transparency" feature is arguing from a point of ignorance.
b.g.
VNC is a screen-scraper, with all the issues that come with that. If that's all you have then it's at best only tolerable. The rest of the time, it's a crappy alternative. Windows Remote Desktop falls into the same category, as far as I'm concerned.
It's far better that X work the way that it does, and we use it that way. X's client-server model contributes very positively to system stability, portability, and maintainability; and when the client and server are on the same machine, as is the case with the OP, the "overhead" really isn't there at all. Any objection to X on this basis is pure and ignorant FUD.
Oh, and by the way, since X is client-server, we can move the two onto different machines. And add more machines into the mix.
I'm just not seeing the problem here...
b.g.
I want to do a quick calculation in mathematica. I don't have a mathematica license on my personal machine. I log in to the research server, launch mathematica remotely, do my thing, log off.
Are you really claiming this is use case is no longer important? At my university I see it all the time.
Maybe I'm missing something.
Despite having a freedom hating binary only driver, Nvidia's track record for keeping up to date is really good. It certainly keeps ahead of the three most popular distributions without problem. Even Arch Linux, a bleeding edge rolling release distribution, has remarkably little breakage with the binary drivers.
Roll on the FUD, troll.
I want this account deleted.
I agree. Linux is way beyond that silly wannabe OS. One can hardly call it a competition at this point.
I want this account deleted.
I haven't had such an instance myself. I've been overclocking my graphics cards like mad, doing this and that crazy stuff, and every single time the graphics card has locked up Windows has been able to restart the driver successfully. Not once has my system locked up completely due to graphics card - related issues. It's really handy and it still baffles me why X.org devs don't seem to consider doing the same thing.
Because the X.org devs don't actually control the nvidia driver blob?
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Comment removed based on user account deletion
Comment removed based on user account deletion
Windows has been able to restart the driver successfully
Consider yourself lucky. When playing SC2 under Windows I get a complete lockup once every 3 or 4 days.
in the fantasy of modularization, different pieces of the computer machine are separated and individual.
in reality, they are all mushed together through undocumented, hacked-together crap. alot of driver-writing is black-box guesswork, and always has been, probably always will be. Nvidia's binary closed blob only makes the problem worse --- you are basically taking unknown undocumented kernel bits and putting them into your linux kernel (IIRC)
there are various ways to get rid of this problem... theoretically the 'microkernel' OSes like Plan9 or the Hurd should not crash with video driver problems... but those plans never seem to work in reality.
lastly, there is the old argument taht linux "crashes" are often not really 100% crashes... if you only had a serial-port terminal, like an old VT100, you could plug it into your machine and log into the linux console, reset the keyboard, video, etc, and get everything back up running. Of course, machines don't even come with serial ports anymore, and i dont know the new version of the argument.
i hate to go all Glenn Beck here, but we know the microsoft Standard Operating Procedure. We know how they think. We know how they act.
introducing subtle incompatabiities and crashes into product in order to crush competition is just another day at the office for those guys.
they probably are putting political pressure on Nvidia to give them special access to their internal documentation or something.
this is precisely why 'closed blob' drivers are bad. . . . because it allows the enemies of Linux and FOSS to destroy it. closed blob drivers are a step away from closed, un-sniffable hardware. it is like the story of the WinModems all over again. . if the situation with WinModems was repeated for Graphics cards, mice, keyboards, monitors, etc, then Microsoft could really destroy Linux.
vomiting crack whores are welcome in the church, they can get counseling and treatment... something they would never find at a linux convention.
I read that line in GPP's post and thought, "that analogy may be more accurate than you know ..."
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
So, you don't use it which means nobody does? My guess is if you don't use it it's because you don't understand how to use it, or the only way you talk to other machines over the network is via a browser.
I use it daily, not for troubleshooting or admin, but just for average use. Running a browser from one machine onto another is a great way to not have to worry about a locked down machine using a bad browser by default and I get to keep all my shortcuts and plug-ins as is no matter where I am. Yes, there are other ways to do the same, but this just works.
Are there some things that could be done better? probably. I'd love a smoother way of getting the xauth setup between two machines, and maybe some way of launching programs that is one-click (a program launcher on the remote machine that can be started easily from a shortcut?). But those kinds of thing have nothing to do with the X architecture itself, just user-level tweaks.
My biggest issue is I want X to be used more, not less. instead of the web browser interface for my router, I'd love an X-app that displays on my PC. And, too bad my phone can't send the contacts app to my desktop when I want to use my keyboard and mouse instead of the touchscreen. And let's not even get into how useful my TV would be if it had a built-in X server...
AB HOC POSSUM VIDERE DOMUM TUUM
Fascinating. I use Arch+nVidia as well, and I've never had any problems.
"People don't want to learn linux" hasn't been a valid excuse since '03.
It's far better that X work the way that it does, and we use it that way. X's client-server model contributes very positively to system stability, portability, and maintainability; and when the client and server are on the same machine, as is the case with the OP, the "overhead" really isn't there at all. Any objection to X on this basis is pure and ignorant FUD.
Oh, and by the way, since X is client-server, we can move the two onto different machines. And add more machines into the mix.
This. I thought the merits of modular coding would be widely acknowledged already. We use higher level languages with object orientation, even though assembler might be a little faster.
Just today, I've been discussing how to make a cluster of FPGAs for a certain parallel job. I then realized that the same ideas of modularization would help my code even on a single chip. (Partly because the async links would help with some clocking issues, making each module independent clock-wise).
Escher was the first MC and Giger invented the HR department.
Point taken, but Linux as a user experience on the desktop does not compete with Windows. I thought we were over this stage. We all agree that Linux' architecture and flexibility is superior and servers and blah blah, *but* as a whole, it does not work as a desktop alternative for GrannyOnTheGoogle@hotmail.com and duckface4u_hihihi999@aim.com. Linux On The Desktop (tm) had it's chance with the Ubuntu 8.x series, then they started getting buzzword compliant and god knows what the fuck happened at Canonicial after that.
Can I light a sig ?
and what was the last time, you really used remote X? Everone uses ssh X-Forwarding for that. First, because ssh runs anyway, second most people do not want their x-server to listen on tcp, when using ssh is sufficient. And ssh is encrypted, remote X or even xdmcp is not.
> [goat.cx]
and what was the last time, you really used remote X? Everone uses ssh X-Forwarding for that. First, because ssh runs anyway, second most people do not want their x-server to listen on tcp, when using ssh is sufficient. And ssh is encrypted, remote X or even xdmcp is not.
ssh X-Forwarding uses normal remote X over TCP/IP. ssh can forward any TCP connection.
http://michaelsmith.id.au
The design problems mainly have to do with timing of animations.
Since you need support for running over a network, things such as vblank support and anything in general which require knowledge of the update frequence/stats for my screen can't really be done*.
*Except by extensions which don't support network.
I don't see why vblank information can't be sent over the wire like everything else. Or, as you mention, it can be done outside the wire, just like shared memory images are done. The problem we've had with vblank is that neither the protocol nor the toolkits have any infrastructure for dealing with it. There have been vblank and sync extensions for years, but nobody uses them. Meanwhile, DRI and DRI2 have been used extensively by applications and desktop frameworks/window managers, and DRI and DRI2 are considerably more complicated than a vblank extension.
Once again, the problem isn't really the network transparency, it's the users (not the end users!) and lack of foresight from the 80s (which is understandable, but unfortunate).
Or an SSH client for your phone (something I've used for recovery several times, since I often run unstable software). I need to switch to wifi to get in, since my box is on a private reserved network block, but other than that, it's a quite adequate replacement for the VT220 I discarded back around '88. :)
The Unix philosophy was started by some guys in the mid-to-late 1960s, and grew during the 70s and 80s and then had a resurgence in the 90s when Linus wrote his little 386-only experimental OS that grew into something much larger.
The guys who came up with the Unix philosophy are all really old, or dead. Even Linus himself is getting up there. The guys doing the newest things now are younger, and obviously have a totally different mindset, and that's why we're getting stupid things like the Gnome3 debacle, i.e. a desktop environment that instead of helping you do serious work like writing and debugging complicated software, is optimized for ADHD children who just want to use Facebook.
Actually, I rather like the point that X is to Wayland as http: is to file: for the web. It's a silly comparison, however.
Personally, I like the philosophy behind Wayland, as it does a nice repartition of the problem that better fits. I use remote X all the time and assume I will continue to use remote applications when Wayland is popular. Modern X toolkits use techniques that are a poor match for remote X anyway (mostly rendering to bitmaps internally and then outputting them via X). Things are changing regardless of what protocol we use for remote user interfaces. It's not a healthy thing to stick with technology due to nostalgia, and considering that there is nothing yet to compare X to in a Wayland solution for remote interfaces (or, for real world use, for *local* interfaces), it seems remarkably premature to declare X a winner.
I'm happy to see what develops and then make a choice. X is neat, I've used it for a long time, but I'm not going to ignore the *possibility* that something better might come along out of bizarre loyalty.
Until there are actual mature implementations of both methods, why choose a camp?
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
I have 6 and 7 year old kids and know a granny and grandpa that use that use the so called complicated Linux desktop just fine. In fact, I have yet to witness this illusive demographic that has trouble using the Linux desktop. Mostly it's just regurgitated internet blather about what was once true years ago.
The truth is Windows is pre-installed on virtually every desktop out there. The truth is Windows is marketed on every medium imaginable from stickers on boxes to the fucking idiot in the blue shirt at best buy to the laptop ads on TV. They practically advertise having a Windows OS louder than their own brand name. Don't pretend that that kind of product placement has nothing to do with Linux on the desktop's adoption.
Now you can blather about and say something stupid like "id too complixcated" because you saw it modded insightful some years ago but is it really still true? I've heard it regurgitated so many times now that it has got to be true? Even though most of the "insightful" can't actually say what users are getting stuck on?
No, not what you think they're going to get stuck on, but what you actually saw them get stuck on. Seriously what did you see them get stuck on and why didn't you submit a bug report for it? (Don't even say that it would fall on death ears or other such FUD. There's a whole damned company which you mentioned who has a hard-on for such things).
Now don't get me wrong here. I'm not one of those peace loving Linux hippies that try to push it on everyone as if they were saving the world from the horrible Microsoft Man. I just don't buy the whole "Linux is crippled by a complex desktop experience" argument. I've had total computer newbs over to my house ask if they could use my computer for one thing or another and they did without much trouble at all. They all were able to find a web browser, a word processor, or whatever just fine. One user even found her self through all the complexities of the Linux desktop to a game Mahjongg game when she'd finished checking her web mail. Really is Mahjongg much different on Linux? I guess not. I didn't have to show anyone what to click on I just told them they should be able to find it and set them lose while I pretended to be busy doing something else.
People are a lot more resilient to differences in UIs than geeks and nerds give them credit for (Every cellphone or toaster oven out there has a different UI... and people change their phones frequently). Geeks feel more like the expert (ego boost) if they can assume something they use is too complex for that average idiot. Also geeks tend to go out of their way see all the complexities that a system has to offer. Yes you can do some amazingly complex things with a Linux OS. That doesn't mean everyone has to.
I want this account deleted.
One thing I'll point out is that RDP (using the current Windows clients and servers) is extremely efficient compared to "network-transparent" X. When I use Wireshark to look at what's on the wire, opening a Firefox window on Windows and displaying it to my desktop uses roughly the same bandwidth as X's "network transparent" windowing, but happens much quicker due to latency -- the X client is issuing multiple requests to the X server then *waiting for the response* before continuing on. Furthermore, RDP is transferring ONLY THE CHANGED BYTES, *not* the whole screen, so the notion that RDP transfers the entire screen every time the screen updates on Windows is just plain nonsense. Meanwhile, X is not only transferring the changed bytes, but only doing so after a series of *synchronous* commands. The net result is that the 500ms total turnaround time between my house and my work ends up very painful with "X", while is virtually unnoticeable with RDP.
From a theoretical point of view, it all makes sense. There is a theoretical minimum number of bytes which must be sent to update a window from its old state to its new state. This occurs whether the detection of which bytes need sending is via screen scraping or via the application directly telling the graphics library "these are the bytes that have changed". Recent revisions of RDP have gotten *very* efficient at approaching this theoretical minimum. Standard "X" doesn't even try -- if an application draws a new graphic and tells "X" to display it, X sends the entire new graphic to the remote end, *even if only a few pixels have changed*. (And yes, I know there is such a thing as FreeNX etc., but that's add-ons that are not part of X proper, attempting to work around these performance limits of X).
I guess what I'm saying is that if Wayland chooses to use an RDP-like screen scraping protocol for remote display rather than doing "network-transparent" windows like X, there's no theoretical reason why it cannot be efficient. Pixels are pixels, in the end, and the minimum number of pixels needed to refresh a window are identical whether the pixels are being derived via screen scraping, via screen scraping with hints based on GUI library calls (what RDP does), or via the application telling the display protocol "these are the pixels that have changed". The only difference is that the last requires every application to be written to efficiently tell the display protocol "these are the pixels that have changed" -- and we already know that this isn't so for many major "X" applications, which are far from efficient in that regard.
Send mail here if you want to reach me.