Slashdot Mirror

There actually are plans for X12.

- As to overwriting. This occurs because the update events follow behind the UI. The problem is resolved by the composite extension, or by enabling backing store -OR- by increasing network bandwidth. Some old X Servers didn't have backing store (and certainly no compositing), AND ran over constrained pipes. It hasn't been a problem with desktop X for years.

- X is extensible by design. Multiple display support, accelerated 3D, video playback and compositing do work. For $DEITY sake, I use these features on my stinky little Acer Aspire One using Linpus! No particular problems -- "it just works" (tm). I don't like transparent windows, so I just don't bother, but it does work. Why the hell would a user want to know about the alphabet soup? Just use a packaged OS. The alphabet soup comes about because the development of X is an open process.

- And, in comparison with the Mac, you do notice that Apple packages an X Server with OS X? When running in a heterogeneous environment, it's necessary.

- Finally, you bring up the Unix Hater's Handbook. Ok, let's break it down:

1 - xload, xterm and xclock are possibly among the LEAST used programs under modern X based systems. They weren't
even installed on my Acer when I got it.

2 - Motif isn't used anymore.

3 - Cut and Paste really isn't an issue anymore, either.

4 - ssh -Y is usually used to remote X servers - authentication isn't an issue anymore either.

5 - Gnome and KDE provide the "customization methods"; since xterm isn't used anymore (or xcalc, or xedit),
the xresources issues are also gone.

6 - imake has been deprecated for YEARS.

7 - Pretty much nobody uses raw X protocol or XLib anymore either.

8 - NeWS was "killed" because IBM and DEC didn't want a repeat of NFS - they didn't want to send SUN any more money. So, they marketroids forced the issue. I agree the superior technology didn't win, but X is still around. Sucks to be the customer when they get what they have been told to ask for.

The UGH was relevant in the early '90s. No longer.

The "MAC UI Experience" could be planted on top of X. I am disappointed that Apple isn't driving that. It would involve developing several extensions that would be useful to X users. But, if Apple doesn't want to do it, others will:

http://www.freedesktop.org/wiki/Software/CompositeExt
http://en.wikipedia.org/wiki/XRender
http://keithp.com/~keithp/talks/randr/randr/
http://en.wikipedia.org/wiki/X_video_extension
http://docs.sun.com/app/docs/doc/801-6662/6i1196cd6?l=ja&a=view

The first four are generally implemented. The last is not (X/DPS). But, MAC OS X only implements a subset of X/DPS anyway (and, of course, it isn't compatible).

Compiz is cute and all, but Windows & OS X both provide GPU accelerated frameworks to applications in addition to a compositing system wheres compiz does GPU accelerated window dressings. API? Wot API?

With the indirect rendering architecture in X11 right now

Using compiz to say X11 has an 'indirect rendering architecture' is just a tad extreme. Oh, but hey, this is /. of course, and it's the year of Linux on the desktop or something..

Unfortunately, the Beagle Board has a PowerVR SGX530 GPU, and there is no X.org video driver for it. So, open source operating systems cannot use 2D or 3D acceleration. See http://dri.freedesktop.org/wiki/PowerVR.

A few links to follow:
Main page
Features
Programs (not performance just wine style if it works)
A developers blog
I think the performance will always lag behind nvidia, however I'd guess that in about 9 months time the radeon drivers do most 3d rendering at a decent speed (It could be sooner, but i doubt it will be longer unless there is a major change)

A few links to follow:
Main page
Features
Programs (not performance just wine style if it works)
A developers blog
I think the performance will always lag behind nvidia, however I'd guess that in about 9 months time the radeon drivers do most 3d rendering at a decent speed (It could be sooner, but i doubt it will be longer unless there is a major change)

A few links to follow:
Main page
Features
Programs (not performance just wine style if it works)
A developers blog
I think the performance will always lag behind nvidia, however I'd guess that in about 9 months time the radeon drivers do most 3d rendering at a decent speed (It could be sooner, but i doubt it will be longer unless there is a major change)

ZorbaTHut's experiences notwithstanding, I found that some old DX9 ATI cards (think 9600 or so) work fine for compiz.

The newer ATIs (onboard or otherwise) have very spotty 3D support. This page gives you a nice rundown of what cards do good 3D and which ones don't.

And not that you asked, but my onboard Intel graphics so Compiz fine. The Intel drivers are FOSS and constantly being improved by people who actually work for Intel.

Sure the radeon/radeonhd drivers are in need of help, but most radeon developement is being done by two non-ATI guys.
Sure the 3D rendering is behind the blobs, but not that far behind [1]
And the 2D drivers are faster
And in my experience way more stable (outside of KMS issues i have had 0 crashes under radeon, the same could not be said for catalyst or nvidia drivers)

The reality is that for everyday use*, ATI cards now work out of the box on linux with rock solid stability this is not the case for nvidia, and it's just a matter of time till the 3D support catches up with nvidia's and firmly place ATI cards as #1 choice for Linux users (if its not already)

*call me old fashioned, but i don't consider compositing part of that.

Or is it ATI and nVidia still going with binary-only drivers [t]hat hurts Linux on the desktop?

Yes, let's see if we can blame it on someone else rather than try to fix it.

Someone is fixing it. For ATI hardware anyways, since they're the ones who have published hardware specs without NDA. Maybe if this works out NVidia will be convinced to follow suit. I'll probably try switching back to the OSS drivers soon since the fglrx drivers don't seem to play nice with KVM server kernels on my Ubuntu-based setup. I'm not getting a lot of benefit out of the fglrx drivers right now anyways - the 16bit display emulation overlay necessary for their 32-bit only drivers keeps crashing when I try it - so pretty soon I'll have more of the functionality I want from the OSS radeon drivers than from fglrx. It's why I bought an ATI card nearly 2 years ago, so I'm glad to see it's finally paying off, for me and for them.

Hopefully this will be successful enough to also convince them to release the still outstanding specs for the video-acceleration pipeline portion of their GPUs.

Or is it ATI and nVidia still going with binary-only drivers [t]hat hurts Linux on the desktop?

Yes, let's see if we can blame it on someone else rather than try to fix it.

Someone is fixing it. For ATI hardware anyways, since they're the ones who have published hardware specs without NDA. Maybe if this works out NVidia will be convinced to follow suit. I'll probably try switching back to the OSS drivers soon since the fglrx drivers don't seem to play nice with KVM server kernels on my Ubuntu-based setup. I'm not getting a lot of benefit out of the fglrx drivers right now anyways - the 16bit display emulation overlay necessary for their 32-bit only drivers keeps crashing when I try it - so pretty soon I'll have more of the functionality I want from the OSS radeon drivers than from fglrx. It's why I bought an ATI card nearly 2 years ago, so I'm glad to see it's finally paying off, for me and for them.

Hopefully this will be successful enough to also convince them to release the still outstanding specs for the video-acceleration pipeline portion of their GPUs.

There are some new external video cards that don't require anything but drivers and a USB port, such as the EVGA UV Plus. AFAIK, all USB video cards use a DisplayLink chipset, and there are rudimentary drivers here. It's not a very elegant solution, but if you want to use any sort of GUI, this should work.

It doesn't support a complete server-side 2D vector rendering interface, so that rasterizing didn't have to happen on clients and be sent over the wire.

XRender

It doesn't support forwarding audio or devices. When it's handled by separate apps, like pulseaudio, it requires setting up separate connections. It doesn't integrate dbus, so if you wanted remote apps to connect to a local bus, you need to setup a separate connection.

That's a legitimate criticism of the system as a whole, but it's not the job of X11 to handle audio. In other words, how is this an argument for throwing out X? If anything, it's an argument for An X11 extension for audio, which, IMHO, is a good idea in principle.

Maemo 5 includes the Telepathy framework, which seems to either be working on or has SIP integration.

The phone includes Skype that works over WiFi or 3G, so there is no inherent restriction on VoIP. I'd expect to see Google Voice for it fairly quickly as well.

My XO-1 was sitting unused, until I installed debXO. I used the xfce version. I'm very happy with its performance as an on the road machine. I also use it as a mobile graphical X terminal, to display a desktop from my desktop machine, using Xephyr over an SSH tunnel. Very nice. With a bit of compression applied by SSH, over my LAN it's almost as responsive and as pleasant to use as the console of my desktop.

It certainly sounds like a software limitation to me... It's a limitation of the software implementation.

It is both a hardware and software issue. See here and here. The multi-display implementation used by the driver is limited by the hardware's maximum supported framebuffer size for 3D rendering, which is 2048x2048 on the 945GM.

also (1280 * 800 ) + ( 1280x1024 ) < ( 2048 * 2048 )

I apologize; 1280x800 and 1280x1024 will work, but only if the screens are arranged on top of each other.

It certainly sounds like a software limitation to me... It's a limitation of the software implementation.

It is both a hardware and software issue. See here and here. The multi-display implementation used by the driver is limited by the hardware's maximum supported framebuffer size for 3D rendering, which is 2048x2048 on the 945GM.

also (1280 * 800 ) + ( 1280x1024 ) < ( 2048 * 2048 )

I apologize; 1280x800 and 1280x1024 will work, but only if the screens are arranged on top of each other.

We do have a unified video acceleration API, it's called VAAPI.
Of course applications have to be recompiled to support it, users shouldn’t do it themselves, distributors will do it for them.

A pleasant audio / video experience requires flawless drivers on any application / operating system / hardware combination. No o/s can work with crappy drivers and that's the same for Linux, Windows or whatever else. The difference is that, when drivers suck on Windows, you blame the drivers, while when it happens on Linux, you blame Linux.

There's something seriously wrong when I can watch, say, YouTube content or a simple video file on an Intel Atom-based netbook running Windows and it plays more smoothly than on a Xeon 5520-equipped workstation running Linux.

Indeed! Because on my computer, for instance, I manage to watch DVB TV much smoother on Linux than I can do on Windows. Are you using VESAFB on the Xeon? :)

P.S. Vista, too, disables compositing when an application uses an overlay-based video API (yes, even Windows has many different video APIs with varying degrees of functionality). This cannot be solved, overlays are crappy by design.

The driver quality has improved noticeably since they were purchased by AMD.
Also, the open source drivers are progressing nicely. http://xorg.freedesktop.org/wiki/RadeonFeature

You sir need to do more research. There are numerous standards in Linux/GNU software.

Please see the header for the X.org SI DGA protocol. The parts that say "THIS IS THE OLD DGA API AND IS OBSOLETE. PLEASE DO NOT USE IT ANYMORE," I think, are really the best part.

DGA1, that header, is the one with mouse handling. DGA2 does not include it (check here if you're in an untrusting mood.)

Please see the header for the X.org SI DGA protocol. The parts that say "THIS IS THE OLD DGA API AND IS OBSOLETE. PLEASE DO NOT USE IT ANYMORE," I think, are really the best part.

DGA1, that header, is the one with mouse handling. DGA2 does not include it (check here if you're in an untrusting mood.)

... and they already addresses all of those concerns on the first post to their mailing list.

The Tango Project does just that. At the simplest level they have a standard set of icons which any application developer can use - the icons are public domain.

Actually both of them suck, but sudo sucks less.

IMHO, not the way Ubuntu sets it up by default. Blanket sudo is almost as much as a risk as running shells as root.

sudo should be used to give access to commands you trust yourself with. I don't see that Ubuntu has actually supported this idea at all, on Mandriva, rurpmi is available as a restricted version of urpmi, where no dangerous options are allowed (you can't accept unsigned packages, install local packages, force package installation without dependency checking etc.), specifically so it can be used relatively safely via sudo.

The other method Mandriva uses for provided access as root (natively, as evidenced by the password prompts when running Mandriva Control Center) is console_helper (which is what Fedora/Red Hat have traditionally used).

Apparently, nobody understands the big difference between temporarily elevating own privileges versus becoming another user (with everything that comes with that).

That's a bit of a rash statement.

I am sure somewhere in Linux world the same technique exists, but I am not aware of it. Nor does my Ubuntu use it as far as I can see. As soon as I sudo, I become root. I dont want to become root, I just want to have root's power for a while.

It's called PolicyKit, and is the replacement for console_helper. It is shipped in Ubuntu, Fedora, OpenSUSE, Mandriva, but not necessarily well integrated into all the applications (yet).

Actually both of them suck, but sudo sucks less.

IMHO, not the way Ubuntu sets it up by default. Blanket sudo is almost as much as a risk as running shells as root.

sudo should be used to give access to commands you trust yourself with. I don't see that Ubuntu has actually supported this idea at all, on Mandriva, rurpmi is available as a restricted version of urpmi, where no dangerous options are allowed (you can't accept unsigned packages, install local packages, force package installation without dependency checking etc.), specifically so it can be used relatively safely via sudo.

The other method Mandriva uses for provided access as root (natively, as evidenced by the password prompts when running Mandriva Control Center) is console_helper (which is what Fedora/Red Hat have traditionally used).

Apparently, nobody understands the big difference between temporarily elevating own privileges versus becoming another user (with everything that comes with that).

That's a bit of a rash statement.

I am sure somewhere in Linux world the same technique exists, but I am not aware of it. Nor does my Ubuntu use it as far as I can see. As soon as I sudo, I become root. I dont want to become root, I just want to have root's power for a while.

It's called PolicyKit, and is the replacement for console_helper. It is shipped in Ubuntu, Fedora, OpenSUSE, Mandriva, but not necessarily well integrated into all the applications (yet).

"Other thing I love is how the 3G support is amazing. No more messing around with ppp or weird vodafone apps, just plug the dongle in, pick your network and go. Really smooth."

Brought to you mostly by the fine Dan Williams of Red Hat: http://blogs.gnome.org/dcbw/ , http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/ .

(disclaimer: I work at RH too).

You can manually setup a Screen for each display adaptor in your xorg.conf. If your video card driver supports Xinerama, enable that as well, and you're good to go.

I know. The problem is that distros like Ubuntu are deprecating Xinerama in favor of RandR. Last time I tried, it wasn't possible to get Xinerama working in 8.10 - and everyone's solution is "use RandR."

About the multiple CRTCs thing, I believe that's different than multiple GPUs. I specifically asked on the RandR mailing list if 1.3 would have support for multiple video cards and was told no.

My then-current solution was to set use RandR on one card (two monitors), where all worked as it should, and to have a separate X session for the second card (third monitor). This "works" but it's pretty useless because of a bunch of bugs in how windows are handled (e.g., you open a window on one screen, and it ends up in the other X session). The whole process was so frustrating, it drove me back to Windows, and I've swore off Linux on this desktop until the multi-monitor support is better.

X.org has posted some project ideas for Google Summer of Code projects, including "VDPAU state tracker for Gallium. Admit it, it would be pretty cool."

Yep, thats not so far away from what I have in mind with my inputdrv app and for most part such a thing would be quite doable. There are however a few practical problems, one important one is that I don't think there is currently a clean way to reassign joystick ids, so if you plug in another joysticks or load a virtual driver for the remapping it will always be /dev/input/js2, while the game is using just js1, other then messing around with mv/ln/rm I don't know any way to actually get the device in the right place. Its not a unsolvable problem, but the workarounds are all rather ugly.

Another issue is the loading of the configurable driver must happen before the game itself, since each game needs its own configuration and because you can't change the configuration after the game is loaded. Their might be ways to accomplish this, but I haven' really looked into it. A little wrapper script done by the user would of course fix the problem, but again, that would be more a workaround then a solution.

Last problem of course is that you need to collect lots of data, you need to know what games make use of what buttons and such. Currently games do not announce those in any way, so one would have to collect them manually. On the joystick side its easier, since via USB/HID you can already get a good enough idea of what a joystick looks like, you would just need to cleanup for exotic cases.

The input issue aside there is of course other basic gaming stuff that is wrong, fullscreen switching for example is handled pretty differently in many applications, not only is the key different (F11, Alt-Enter, Ctrl-f, ...), but also the behavior of fullscreen itself is different. Wine for example allows you to freely move the fullscreen window around and switch workspaces, while many games grab your mouse and keyboard input completly and don't allow you to switch to a different workspace.

I just noticed that freedesktop.org actually has a mailing list for gaming related issues probably time to move things there.

This is the gospel truth, because Linux does not accelerate as much as they do.

[Citation needed]

Xegl is where we are going, we are not there yet, Xgl is what we have now, it has major pieces missing and only runs properly on a small subset of hardware (not as small as what Xegl runs on, though.)

HTH, HAND. Next time do some searching around, if you had just looked up "Xgl" you could have found all of this out. I won't do your research for you again. If you can't use google, don't use slashdot.

This is the gospel truth, because Linux does not accelerate as much as they do.

[Citation needed]

Xegl is where we are going, we are not there yet, Xgl is what we have now, it has major pieces missing and only runs properly on a small subset of hardware (not as small as what Xegl runs on, though.)

HTH, HAND. Next time do some searching around, if you had just looked up "Xgl" you could have found all of this out. I won't do your research for you again. If you can't use google, don't use slashdot.

I filed a bug warning of this security problem on March, 2005. Final answer of the developers after taking it to the freedesktop lists: WONTFIX. So, what's the point of reporting bugs?...

The fix is easy, only interpret .desktop files IFF they have the +x bit set (IOW, apply the regular UNIX semantics). It shouldn't take more than a few lines in Gnome and KDE to fix it, and distros can easily modify the scripts to make all the .desktop files +x-

We already have an organization dedicated to this, it's called Freedesktop. Check out their software and specs, which cover all the things you mentioned and many more.

We already have an organization dedicated to this, it's called Freedesktop. Check out their software and specs, which cover all the things you mentioned and many more.

links to Free Software PDF readers

Any of them can verify cryptographic signatures?

Good reputation with regards to supporting the hardware?
You mean the drivers that crash and burn and lock your system with anything that has to do with 3D, suspend, switching from X to VTs, video output to a second screen/projector ?
Take a look at the bug tracker:
https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=intel
See the stuff in red? :) Some of those things have been reported and rereported since 2006 and they still happen.
_Everyone_ I know that bought a laptop during 2007 that has the GMA950 chipset had frequent lockups with GL acceleration until about Q2 2008.
And you talk about the best supported hardware in Linux?
What a joke.

...Linux and OSX which run on several different and totally alien architectures.

Linux and OS X run on x86 just like MS Windows. I doubt Google will be releasing a PPC build for Mac or any of a number of other architectures available on Linux.

I agree with you about IPC not being the easiest cross platform thing to do. However, it is not terribly hard if you follow POSIX and wrap for Win32. As pointed out there are already cross platform IPC libraries like Boost and D-Bus, etc.

Take a page out of Freedesktop.org's process. Any user can create and maintain user repositories in their own space. For example, http://cgit.freedesktop.org/~csimpson/mesa is my personal Mesa repo. Then, anybody that wants can pull from there. Very rarely do FD.O people pull and push directly to each other, and I doubt that it happens that way in larger organizations, either.

whatever happened to noveau anyway?
 
It's still being worked on, apparently. http://nouveau.freedesktop.org/wiki/ The last update was on November 16, so it's not being worked on really fast....

I'll respond to my own post. It turns out that the Gnome Keyring and the KDE Wallet don't integrate, after all, so if you have both KDE and Gnome applications on your system you are effectively without a single centralized password manager, as previously feared. There are plans to integrate the two managers, but they're "at a very early stage".

Like everything else in the open-source world, we move in increments. Don't expect breakthroughs, expect progress. :3

http://nouveau.freedesktop.org/wiki/FeatureMatrix
http://wiki.x.org/wiki/RadeonFeature

~ C.

And http://dri.freedesktop.org/wiki/DRM as well.

Windows hit 1.0 in 1984. Windows NT 3.1 (It's initial rlease, or real 1.0) came out in 1993, but had been in development as OS/2 3.0 for some time and kept the same basic Windows API from Windows 3.0. Nextstep (now OS X) 1.0 was released in 1989. Linux (the kernel) 1.0 was released in 1994, but the desktop environments (KDE/GNOME) were almost five years later (98 and 99, respectively).

So when people come down hard on the Linux desktop, they need to remember that it's really only about ten years old, compared to almost 25 for Mac/Windows. FD.o is not very old and is the desktop specification machine for the Linux (and other Unix-alike) desktops.

If we graphed the desktop capabilities for each OS over time, I think it would be obvious that Linux-based OSes are moving much faster than the others. Even if distance is not on our side now, velocity and acceleration are. The distance is only a matter of time (*velocity ;))
Source

the kernel application binary interfaces are a moving target.

That's why we have glibc, which abstracts that ABI from applications.

Kernel driver interface - the horse was already beaten to death many times ( see here ).

a consistent configuration system, to enable distribution;

Windows tried that with Registry - and it didn't worked. And it will never work since "one size never fits all" requirements of all applications.

native file versioning;

Was tried many times before and failed miserably. As long as majority of files are blobs, versioning on level of file system makes no sense. Versioning on level of applications is implemented already more or less everywhere it was needed and SVN/git is there for the rest of applications.

audio APIs;

See ALSA and its user-space libraries.

See SDL.

and the integration of X11 with apps.

As was shown by FreeDesktop initiative not really needed nor X folks want to be bothered by all the end user bells and whistles.

Finally, he argues that Linux needs a committee to insure that all GUIs work consistently and integrate better on the back-end with the kernel.

Committee?? Buahahhahahaha!!!1!!cos(0)!!!!!!!

All what he says was tried before (see (11)) and generally can be described as "failed".

http://www.freedesktop.org/ is the link. Was that really so hard?

Their drivers are stunning and they are completely open.
2.6.28 and 2.6.29 have some really neat stuff for Intel cards.

I've had a Thinkpad with i915 in it now for three years.

Not ONCE during that time I've gotten properly accelerated 3D without any issues.

Very simple test subject, Google Earth.

Back at Xorg 6.8 it was simply unaccelerated and didn't work at all (had to set some environment variable so it would work).
Upgrade: When zooming in, the screen would go all foggy (bug in Mesa versions before 7.1).

Upgraded now to Xorg 7.4. Intel driver 2.4.x. Cloud bug went away, but suffering from this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=17397

Beside these, throughout the whole time there's been a bunch of window issues. For example, if you drag any window (any popup that gearth generates) over the main window, there's horrible flicker.

So my experience with Intel stuff has been pure crap so far.

I'm looking forward to those 2.6.28 and the GEM stuff, maybe they'd finally make my GFX work.

I have installed the Fedora 10 on a relatively new intel box with 2gig ram and 128mb Nvidia. Compared to WinXP and Leopard, its UI still feels sluggish and slow to mouse clicks and user actions in general. but I hear this is problem of X.org, and improvement is on the way. Let's hope this finally brings us the 'YOLD'. the Year Of Linux Desktop.

Exactly, can't they just instead use an open standard (pleonasm, if it ain't open it doesn't deserve the name standard) like VAAPI ? And eventually submit extensions to it... That's what standards are for!

http://www.freedesktop.org/wiki/Software/vaapi - http://en.wikipedia.org/wiki/Video_Acceleration_API

To quote Kristian Hogsberg's blog:

They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.

and

The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.