An Update On The OpenGL 3 Support In Mesa

[dfx.]

uh, correction: even though there are some fluctuations and uncertainty in "zaphod" support in X, it looks like that bits are in place, at least for Ati/AMD. the bigger culprit are DEs, with KDE in particular which since 4.0 becomes all garbled up and unusable with "zaphod" configured. and promptly dies or worse, drawing horrible stuff. can't say about Gnome.

and here i'm offender too. being so pissed i can't even write straight to their bugtracker. they have broken so much intentionally, for "greater good" and shit. but it's even bigger off topic.

[dfx.]

And once again, you and others are confusing an implementation with a technological approach.

and you want to say that it has better approach but same shitty implementation ?
while i can't see how approach is better, shit still is shit, even if in theory it supposed to be awesome.

I can't even put into words how ****ing frustrating Linux is with a multi-monitor setup, for instance. I've about thrown my second monitor out a window about 10 times a day since I got it.

I want multi-monitor setup that actually behaves properly and stops popping up random windows on either monitor, because my second monitor is _secondary_ and isn't even on all the time because I use it for specific things only.

this is legitimate complain and originates in X devs somehow thinking that multi-screen configuration with completely separated screen ("zaphod" mode, implemented via hack by running several concurrent xf86-video-<X> driver instances per screen on same card) is "not needed enough". so, they removed the hack but didn't reimplemented that any other clean way, hopping that o one notices since "it's not used". i have written them in bugzilla, some few other guys written in mailing list but since majority of people, like _you_ here, complain in forums that don't give a shit about, they say "almost no one needs it" and fused-as-one-screen abominations xrandr does is sufficient.

yes, same people who support ~20 years old protocol which not used and being reimplemented in every toolkit, better but by hacks, and not want to fucking update, already removed proper multi-screen support because xrandr bullshit is sufficient for them to show presentation from laptop at conferences no one even bothers to record...
yes, they are OUT OF THEIR FUCKING MINDS. and now they even abuse substances, so it makes them twice as crazy.

Let's not get into other stupid things like how an app changing resolutions screws up the whole desktop because X can't intelligently reset the resolution after the app closes/minimizes.

and in Windows? i presume they just put hack that "watches" if fullscreen app being in fullscreen and changes resolution to "desktop resolution" and back accordingly (achieving that effect globally, even with old as mammoth shit applications).
which stumbles one on thought that same could be implemented by X Extension. X lives on crutches, so why fucking not to do it.

Client-side decorations are not a huge problem. They can cause issues at times, but so does the alternatives. Ever had your WM crash on Linux? You can't do shit. You can't open a terminal to fix it because the key-bindings that let you run apps were managed by the WM.

well, it's fucked up but personally i still can call yakuake in KDE somehow and while it may come not in foreground, it's focused (in KDE stuff may be focused even if in background alright, i fucking love its inentrusive focus changes. you have like 4 level aggressiveness option for those). it maybe uses some hack to watch for its main hot-button combination not via WM.

If you're a hardcore nerd with no life you probably know how to ctrl-alt-f2, log in, and run "DISPLAY=:0 mywm" to get things running again...

and since you know that, it makes _you_ a "hardcore nerd with no life". cool.

and by the way, ever got explorer? in Windows? crash and not being relaunched automatically ? what do you do ? press ctrl+shift+escape of course and in build in console("run it" or something in english version) write "explorer". not much better.
watching for WM process in GNU/Linux and "explorer.exe" in Windows? looks like being made through same fucking stupid hackish way.

systemd being made to create some order in managing processes. maybe they can implement some dbus signal on process sudden crash or something.
and wayland should avoid that problem altogether.

What I want? A desktop graphics stack that works out of the box. One that doesn't force me to manually make choices between "feature set A with bug set B" or "feature set C with bug set D" but instead just gives me "feature set A and C and some damn effort put into getting rid of bug sets B and D."

cool but i don't see you coming up with the solution (not programming, conceptual at least) or even addressing the right crowd.
maybe you should say developers, maintainers and council asses that, huh ?

i wish some day like hundred of people who spam launchpad would spam in someplace like "https://bugs.freedesktop.org/show_bug.cgi?id=2589" and surprise the shit out of those before they start to remove everything that they themselves don't actively use.

something like "http://swik.net/Debian/Planet+Debian/Julien+Danjou:+Thoughts+and+rambling+on+the+X+prot ocol/d619l" almost makes you cry with thoughts of how it's fucked up and there is no way out. again, maybe if we just do a clean cut, since we sit on pile of crutches anyway, wayland will come and save the day, one day.
X/freedesktop devs should really ponder about X12 and xcb future, like right now, before something less crutchy comes.

but still, with all that crap, it's not much fucked up in comparison to those pesky "alternative" OSs. admit it.

I will note that I probably would have about 30 holes punched in walls from using MSVC and the Windows shared library system if it wasn't for my ability to reboot into Linux and find my sanity again -- I am so tempted to walk across the street and start beating MSVC developers with a 2x4 on a daily basis

erhm, i guess you did. even though it looks like an understatement

PS: is it just me or no X driver support scaling with preserving aspect (actually, have no scaling options at all) yet ? this is pretty crazy.

[etnlWings]

Too bad you seemingly can't upscale full-screen windows to your desktop resolution, either. That at least fixes some of those issues with Windows - while fixing yet more issues with HDTVs not properly supporting some resolutions.

[BlackStar]

Should point out that there's similar issues even with Win 7. Full-screen apps are a nightmare even before they do any modesetting.

So true. Even in 2010, apps manage to get this wrong somehow.

Then again, things are much uglier on the Linux side, simply because X is not designed with that kind of flexibility in mind. You cannot specify that a resolution change is temporary (like you can on Windows) and if your app crashes the user is left to pick the pieces.

The only solution is to avoid changing resolutions entirely. Too bad you cannot retroactively fix legacy applications.

[etnlWings]

Let's not get into other stupid things like how an app changing resolutions screws up the whole desktop because X can't intelligently reset the resolution after the app closes/minimizes.

Should point out that there's similar issues even with Win 7. Full-screen apps are a nightmare even before they do any modesetting.

Client-side decorations are not a huge problem. They can cause issues at times, but so does the alternatives.

...

Ever had your WM crash on Linux? You can't do shit. You can't open a terminal to fix it because the key-bindings that let you run apps were managed by the WM. You can't get to your existing terminal window under your browser window because the app that dealt with moving windows around crashed. You can click on your panel to open a terminal but it pops up without focus because the WM is dead. You can't click on it give it focus because the WM is dead. You can't do anything other than click buttons or interact with the currently focused window, because the WM is dead, and none of the applications are smart enough to do anything remotely useful on their own. Your whole damn desktop is enslaved by a single app that has only gotten more and more complex over the years. If you're a hardcore nerd with no life you probably know how to ctrl-alt-f2, log in, and run "DISPLAY=:0 mywm" to get things running again... if not, you're just stuck wondering why people keep saying Windows is so buggy and Linux is not when clearly that isn't the case. Actually, even if you do know how to do that, you should still be wondering that same thing if you're not too busy pretending that being a Linux user means you have a bigger dick than everyone else.

This is a huge non sequitur. Serve-side decorator =/= wm. Regardless of who's drawing the window decorations, you've almost certainly still got a WM. Never mind that your WM should be less prone to crashing than your average desktop app, should provide an elegant fallback (when compiz crashes, it can be easily configured to launch another WM), or should automatically be relaunched by your session manager and even if it isn't, X still provides some basic WM faculties so that you can make your way to a run dialogue. If your keyboard shortcuts for non-WM tasks are handled by your WM, ur doin it wrong.

And if you want to change that WM to get better behavior in one way, you probably end up with a totally different theme, different button behaviors, different title bar menues, and broken totally broken behavior in other ways. I mean, sure, I could switch from Metacity to Compiz which has marginally better multi-monitor behavior, but then all kinds of goofy shit happens with the workspace switcher applet in the gnome-panel, or I have to make choices like using the "desktop panel switcher" or the "cube switcher" which for some incredibly stupid reason not only changes the way desktop switching _looks_ but also gives you two totally different feature sets... and lo, I'm forced to use cube switcher to get close to (but not exactly) what I want behavior-wise, even though the cube is slightly annoying after two days of using it.

The moral of the story: you don't like having choices. Egad, different WMs provide different functionality? The outrage! Perhaps you'd be happier with a Mac.

Also, lern2 Compiz Wall Plugin.

If Wayland gets me closer to that dream desktop where I stop being pissed at my computer half the time I'm using it because it's too damn buggy, inconsistent, slow, or just flat out broken, then I'm all for Wayland.

I hate to break this to you...

[elanthis]

with all the crashes, freezes, resets on false lockup detection, inability to make use of new "clean" API, and wide usage of DX9 D3D variants with incompatible ABI (hello, d3d9_*.dlls) you should be out of your fucking mind to suggest that it's done better in Windows? and it's good example for imitation. those people really should make better use of their time and port ttm/kms on *BSD.

And once again, you and others are confusing an implementation with a technological approach.

Windows makes a lot of dumb choices. A LOT of them. So does Linux/X. I can't even put into words how ****ing frustrating Linux is with a multi-monitor setup, for instance. I've about thrown my second monitor out a window about 10 times a day since I got it. Let's not get into other stupid things like how an app changing resolutions screws up the whole desktop because X can't intelligently reset the resolution after the app closes/minimizes.

Client-side decorations are not a huge problem. They can cause issues at times, but so does the alternatives. Ever had your WM crash on Linux? You can't do shit. You can't open a terminal to fix it because the key-bindings that let you run apps were managed by the WM. You can't get to your existing terminal window under your browser window because the app that dealt with moving windows around crashed. You can click on your panel to open a terminal but it pops up without focus because the WM is dead. You can't click on it give it focus because the WM is dead. You can't do anything other than click buttons or interact with the currently focused window, because the WM is dead, and none of the applications are smart enough to do anything remotely useful on their own. Your whole damn desktop is enslaved by a single app that has only gotten more and more complex over the years. If you're a hardcore nerd with no life you probably know how to ctrl-alt-f2, log in, and run "DISPLAY=:0 mywm" to get things running again... if not, you're just stuck wondering why people keep saying Windows is so buggy and Linux is not when clearly that isn't the case. Actually, even if you do know how to do that, you should still be wondering that same thing if you're not too busy pretending that being a Linux user means you have a bigger dick than everyone else.

And if you want to change that WM to get better behavior in one way, you probably end up with a totally different theme, different button behaviors, different title bar menues, and broken totally broken behavior in other ways. I mean, sure, I could switch from Metacity to Compiz which has marginally better multi-monitor behavior, but then all kinds of goofy shit happens with the workspace switcher applet in the gnome-panel, or I have to make choices like using the "desktop panel switcher" or the "cube switcher" which for some incredibly stupid reason not only changes the way desktop switching _looks_ but also gives you two totally different feature sets... and lo, I'm forced to use cube switcher to get close to (but not exactly) what I want behavior-wise, even though the cube is slightly annoying after two days of using it.

What I want? A desktop graphics stack that works out of the box. One that doesn't force me to manually make choices between "feature set A with bug set B" or "feature set C with bug set D" but instead just gives me "feature set A and C and some damn effort put into getting rid of bug sets B and D." I want multi-monitor setup that actually behaves properly and stops popping up random windows on either monitor, because my second monitor is _secondary_ and isn't even on all the time because I use it for specific things only. I want proper compositing that doesn't cause my desktop to slow to a crawl when I drag windows around because it's telling the app to repaint itself 200 times a second (especially since the monitor only does 60hz), or slow to a crawl because the compositor is just inefficient as crap because X is adding 20 context switches and X roundtrips just to blit some buffers to my screen. I want apps that can continue to function and be usable even if the whole desktop shell crashes, which happens on both Linux and Windows at times. I want resolution switching to not be a joke, and do what just happend about 30 minutes ago (app went full-screen, monitor decided to turn itself off, GNOME decides to rearrange my desktop layout and shove both panels and my desktop icons onto my secondary monitors, and then SAVED THE FUCKING LAYOUT so it stayed that way after logging out and back in!!).

I want all those things on an Open Source graphics stack, on Linux, that doesn't make me settle for all the other stupid shit Windows does (I will note that I probably would have about 30 holes punched in walls from using MSVC and the Windows shared library system if it wasn't for my ability to reboot into Linux and find my sanity again -- I am so tempted to walk across the street and start beating MSVC developers with a 2x4 on a daily basis).

If Wayland gets me closer to that dream desktop where I stop being pissed at my computer half the time I'm using it because it's too damn buggy, inconsistent, slow, or just flat out broken, then I'm all for Wayland.

[dfx.]

heh, i have ssh server installed on my Windows™ 7? just for sole purpose of killing stupid apps which messed up screen and blocked switching. i sshing on it from nearby laptop with Gentoo to clean this shit up. it GUI issue however and not driver one (if you not count that almost all GUI stuff is build in kernel which makes it "a driver" of its own).

with all the crashes, freezes, resets on false lockup detection, inability to make use of new "clean" API, and wide usage of DX9 D3D variants with incompatible ABI (hello, d3d9_*.dlls) you should be out of your fucking mind to suggest that it's done better in Windows™ and it's good example for imitation. those people really should make better use of their time and port ttm/kms on *BSD.

[crazycheese]

It is true. Starting with Vista GPU driver updates no longer require a restart (the screen blanks out for a few milliseconds, the new kernel module is inserted, driver installation complete).

Starting with Win7, you can even hotplug the GPUs themselves while the system is running (I hope noone is crazy enough to try this, though. Fire hazard and all that). The WDDM v1.1 also supports heterogenous hardware and can switch drivers on the fly (Intel & Nvidia and Ati & Ati are the most common combos).

This is nigh impossible to emulate on the current Linux DRI stack but it is said that Wayland might provide a solution. It's very very likely that this will come to the OSS drivers first, before the blobs support it (if ever).

Thanks for the answer! I think it should be easy to implement with Gallium, KMS and udev. Detect gpu change via udev, set output to null, shutdown the driver, wait for new hw. Im not kernel hacker, but I think the technology is present. There is hotswap cpu and memory ability, whats the problem.

See:

http://en.wikipedia.org/wiki/Windows_Display_Driver_Model

"If a WDDM driver hangs or encounters a fault(kernel watchdog, pinging grapic stack), the graphics stack will restart the driver(sending Xorg a message to switch output to null, force rmmod & modprobe, send Xorg a message again to switch).[1] A graphics hardware fault will be intercepted and if necessary the driver will be reset.

Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user will be notified by a popup(libnotify lol); this unifies the behavior across vendors.

Previous drivers were fully implemented in kernel mode, whereas WDDM is implemented partly in user mode. If the user mode area fails with an unrecoverable error, it will, at the most, cause the application to quit unexpectedly instead of producing a blue screen error as it would in previous driver models.

WDDM also allows the graphic hardware to be reset or unplugged without a proper reboot. In practice, a driver update should not necessitate a reboot."
From what I see vital part of gfx stack is still running in 0 ring, hardfreezes very possible.


Wayland is just a FB, personally I care about X12 more than about Wayland because to me, its just making a bicycle from scratch because automobile engine is not sometimes required. I think Wayland is designed for low capable hw, like consoles or pdas, not for desktop where additional functionality using a bit of resources is a problem.

It's documented fact. Why is it someone else's burden to produce a video because you're too lazy to hit Google and spend a few minutes reading on WDDM?

I cannot find it thats why I'm asking. You told me something new, Im asking for confirmation, you fail to deliver it. It is my fault? I cannot find a video of successful driver update till this point.

Ksplice is a crazy-ass insane technique for replacing running kernel code in a _monolithic_ kernel. The NT kernel system is a (hybrid) microkernel, and the video driver subsystem makes full use of that fact.

Linux is as monolithic, as NT is micro. They are both hybrid to large degree.

Windows applications are also written a bit differently than Linux ones, which helps out. Windows apps can lose their graphics context at any time and are expected to deal with this fact. Linux apps do not, because the current X protocol does not separate window and event management from rendering context management particularly well.

I have seriously much much more positive experience switching to tty and back on linux than alt-tabing in windows, especially under heavy system load, not mentioning crashes where reboot was the only option. I think the only problem(bug) in X is managing fullscreen apps efficiently. I.e. something in fullscreen hangs, cannot alt-tab, user has to switch to tty and kill the app. Which at least works 99,9% of time, where in windows it is 50/50 bet.

ABIs are directly derived from the APIs. They go hand in hand. If you have a stable API, you get a stable ABI almost for free. Many Open Source projects do this already, including Linux for its userspace API, as well as glibc, GTK+, Mesa, and most other libraries.

They go hand in hand only if the developer designs it so or if compiler/linker is very conservative. Glibc update is almost never easy on gentoo. "If you stable API" thing will introduce DLL hell(.o'hell). Other method is pinning and mapping new to old, which is an overhead. So the "best" method is some kind of "standard ABI" which will spawn in multitude of binaries, extra mess, several drivers going closed-source.

It seem that make is able to determine itself what part of kernel should be recompiled, which means it is not a problem to make a binary package provided the package manager supports it; which again means binary-based distros are perfectly capable to provide multi-version driver packages for same kernel, they should just package it.

[smitty3268]

Many Open Source projects do this already, including Linux for its userspace API, as well as glibc, GTK+, Mesa, and most other libraries.

In other words, APIs that external apps are supposed to use. Unlike an internal kernel API that no one should really be interfacing with at all.

The problem is that the Linux driver interface doesn't even have a stable API.

And why should it? What's the benefit? The benefit's of not having one are very clear to everyone involved, so what is worth giving that up? Clearly the benefits can't be that great or BSD would have taken off and left Linux behind - or someone would have forked linux to keep a stable API around, and that would have taken off. This wouldn't be that difficult to do - the fact that it hasn't should tell you something, and it's not that you just happen to be smarter than everyone who is involved with creating linux.

[BlackStar]

Can you please show me some proof of it? Video would be good. Should not necessary be AMD->Nvidia, but normal driver upgrade (ie catalyst 10.1->10.2 without reboot and without GDI shutdown).

It is true. Starting with Vista GPU driver updates no longer require a restart (the screen blanks out for a few milliseconds, the new kernel module is inserted, driver installation complete).

Starting with Win7, you can even hotplug the GPUs themselves while the system is running (I hope noone is crazy enough to try this, though. Fire hazard and all that). The WDDM v1.1 also supports heterogenous hardware and can switch drivers on the fly (Intel & Nvidia and Ati & Ati are the most common combos).

This is nigh impossible to emulate on the current Linux DRI stack but it is said that Wayland might provide a solution. It's very very likely that this will come to the OSS drivers first, before the blobs support it (if ever).