User: Password:
|
|
Subscribe / Log in / New account

Wayland in GNOME: two progress reports

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Nathan Willis
July 30, 2014
GUADEC 2014

The X11 replacement protocol Wayland has been in development since 2010. Compared to X11 itself, it is still a relatively new project, but the enthusiasm with which distributions and large software projects announced their intent to support Wayland makes it at least understandable that users would ask how much longer they need to wait before Wayland is made available to them. At GUADEC 2014 in Strasbourg, France, a pair of talks presented the latest status of Wayland support in various GNOME desktop components.

The desktop and GTK+

Jasper St. Pierre presented an overview of GNOME's Wayland support on July 28. St. Pierre's talk started off with an atypical question-and-answer session as he debugged some last-minute problems with his current Wayland session in GNOME's Mutter. One audience member asked when Wayland would be available by default in a Linux distribution; in reply St. Pierre joked "I'll tell you at the end of this talk when it has run without crashing the whole session." More seriously, another audience member asked whether Wayland would support multiple copy/paste buffers; St. Pierre responded that nothing explicitly forbids it, but that in some places the protocol assumes it. Adding multiple buffers would require changing the protocol in ways that the Wayland developers "really don't want to do."

[Jasper St. Pierre]

Although many in attendance were already familiar with X11's security problems, St. Pierre illustrated them at the top of his talk by showing a quick-and-dirty GTK+ program he had written that would exploit X11's lack of application isolation—by, among other things, logging keystrokes and drawing into another application's window. These insecurities are at the heart of GNOME's interest in switching to Wayland, he said. His keylogger could record passwords typed even when the GNOME screen-lock was active, he noted. There have been attempts to improve X security through extensions, he said, but they were "so complex to configure that even the SELinux people said 'we're not going to try implementing that.'"

But in addition to improving security by isolating each process's connection to the display server, Wayland offers GNOME real feature benefits, he said, such as automatic scaling of content on high-DPI monitors and real synchronization of redraws. The most common demos of Wayland, he explained, show off oddities like tilting windows to an angle. That understandably means little to users, he said, but to display developers it shows instantaneously that there are important things possible in Wayland that were impossible in X. Wayland will enable smoother redrawing when dragging and resizing windows. The current tearing and lag that users see is really a shortcoming in X, he said, but users often just blame GNOME or Linux in a generic sense.

The current state of GNOME support for Wayland is a mixed affair. The demonstration apps run quite well under GNOME's Mutter window manager, he said, but support for the GTK+ toolkit comes from the Wayland backend for the lower-level GIMP Drawing Kit (GDK) library, which he called "very, very iffy." Most noticeably, he said, is that GDK's Wayland backend is missing clipboard and drag-and-drop support.

Mutter support is also incomplete, as things are still stabilizing. "I just fixed screen recording support last week," he said. The stability of the Wayland version of Mutter also depends on which GPU driver is used, he explained. The Intel drivers are the most complete; the open-source drivers for NVIDIA chips are in between, while the closed-source NVIDIA drivers do not work with Wayland at all. The reason is that NVIDIA does not offer all of the functions that the open drivers require for Wayland; the company's binary X.org drivers are tied directly into X, so only the company can implement Wayland support for them.

Outstanding questions

In response to an audience question, St. Pierre further explained that supporting a new GPU, generally speaking, is not any harder under Wayland than under X. Supporting a new GPU on Linux essentially boils down to supporting mode setting and supporting direct rendering. Wayland support hinges on the direct-rendering aspect, but most of the work required to support a new GPU is the same for Wayland as it is for X.

There is also ongoing work to figure out how best to support taking screenshots of the whole desktop. Users expect the feature, but it has major security implications. If an application can take a screenshot unattended, it can also use that capability to record username/password combinations and other sensitive data. The straightforward solution is to force screenshot capture to require a user to verify the action; that would at least allow the user to detect if an unauthorized screenshot attempt is made.

St. Pierre spent a large portion of the session slot responding to questions. One question dealt with whether Wayland will be faster or more efficient than X11. It will certainly not be faster in the first few releases, St. Pierre said, but the potential is there for a lot of optimization work. For example, he said, a lot of video content is encoded in YUV color and has to be converted to RGB color for X. But many modern graphics chips support YUV natively; skipping that color-space conversion would be a big time-saver. In addition, he said, "performance" is sort of a generic term. A user might not see a noticeable frame-rate increase in Wayland, but would benefit from other performance improvements like lower CPU and memory overhead.

Another audience member asked whether Wayland would require applications to use client-side window decorations (which GNOME 3 implements but other desktops do not). St. Pierre responded that it would not; the subject is a longstanding debate, and no position has been written into the Wayland protocol. Making both options work was mostly a social problem to solve, not an engineering one, he said. If KWin decides it needs specific changes for its server-side window decorations, St. Pierre said, it is far better for him to sit down with maintainer Martin Gräßlin and come up with a handshake protocol than to try and work around the issue in Mutter.

Two other questions raised more difficult application-compatibility concerns. One person asked how Wayland's isolation of a process's window contents would affect graphics applications like GIMP and Pitivi, which often have a color-picker tool that lets the user copy a pixel's RGB value. St. Pierre replied that Wayland would not currently allow that feature. Similarly, in response to another question, he noted that Wayland will cause a lot of trouble for supporting (and reassigning) global keybindings.

When another audience member asked "how do we sell users on this change, if the fact is that GIMP doesn't work anymore but you can drag windows without tearing?" St. Pierre joked that "I installed Wayland and all I got was new bugs" t-shirts would become popular. The truth, he said, was that a lot of bugs will appear because of the switch, and that if that fact is not handled properly, there is a real risk that the most noticeable outcome will be people getting unhappy about the change.

WebKit

[Žan Doberšek]

St. Pierre covered GNOME's Wayland support at the desktop environment and toolkit level, but Žan Doberšek followed up with a session specifically about Wayland support in the GTK+ version of WebKit, which GNOME uses for its Web browser and as the HTML renderer in several other applications.

In large part, he said, the WebKitGTK+ support for Wayland relies on the same GDK backend support as other applications. But there are also several factors unique to the WebKit case. First, GDK does not support hardware-accelerated video compositing, which WebKit needs for video playback. The solution the project has taken is "inventive," he said. Only specific HTML and CSS features trigger the need for the feature, so they can be treated as a special case. Under X, these compositing operations can be handed off to OpenGL.

But, under Wayland, that same technique is not allowed because it involves handing graphics to a separate process—a major security risk. Instead, WebKitGTK+ has its own nested Wayland compositor that runs inside the main UI process. Making this work required writing an extension to Wayland, but only a small one. It currently works on Intel graphics, but is less well supported elsewhere, because it relies on several specific OpenGL extensions.

The other troublesome factor confronting WebKitGTK+ is how to handle plugins. Opinion is divided, he said. "Personally, I don't want to tackle it because I want plugins to die," he added. The only solution that looks plausible, he said, is if there is reusable work from Mozilla's JavaScript-based, open-source Flash renderer.

The hardware-accelerated compositing work, though, is on track for a future release already. It could land in the WebKitGTK+ 2.6 version, he added, although there has not been a stable candidate released yet. Performance issues still have to be addressed, as does WebGL support.

Overall, there may not be a clear answer to the question of "when will GNOME have Wayland support?" But it is still helpful to see an update on the project's process. The WebKitGTK+ engine is one of the few special cases—most applications will rely on Mutter and GTK+ for their Wayland support—but, on the other hand, accessing the web is one of the most important uses of a modern desktop.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2014.]


(Log in to post comments)

Wayland in GNOME: two progress reports

Posted Jul 30, 2014 19:07 UTC (Wed) by intgr (subscriber, #39733) [Link]

> But, under Wayland, that same technique is not allowed because it involves handing graphics to a separate process—a major security risk. Instead, WebKitGTK+ has its own nested Wayland compositor that runs inside the main UI process

That sounds like a pretty significant omission. To the contrary, the ability to delegate rendering part of some window to another, more restricted process, should be a security-enhancing feature.

Hopefully the developers realize this and just haven't got around to it yet?

Wayland in GNOME: two progress reports

Posted Jul 30, 2014 20:36 UTC (Wed) by iabervon (subscriber, #722) [Link]

On the other hand, the solution of "the browser is the video player's window system" is pretty elegant, assuming that Wayland actually gets the window system process out of the rendering pipeline for the processes it manages. If Weston isn't a problem for accelerating games, then WebKitGTK+ wouldn't be a problem for accelerating embedded video, and being a Wayland compositor should be trivial if you're already planning to do WebGL yourself anyway.

And, actually, the ideal that a web page shouldn't be able to take over the browser UI matches the ideal that an application shouldn't be able to take over the window system UI, so it makes sense that the browser would use the same mechanism, down to being a Wayland compositor.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 6:04 UTC (Thu) by daniels (subscriber, #16193) [Link]

Yep, we have realised it, fleshed out all the options, and ultimately decided that the nested-compositor approach was best. It's very lightweight (requires very little code), and can even be made zero-copy.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 5:41 UTC (Thu) by eru (subscriber, #2753) [Link]

One person asked how Wayland's isolation of a process's window contents would affect graphics applications like GIMP and Pitivi, which often have a color-picker tool that lets the user copy a pixel's RGB value.

I don't get this. Doesn't the colour to be picked normally come from an image window that belongs to the same GIMP process as the colour picker tool?

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 7:26 UTC (Thu) by peregrin (guest, #56601) [Link]

The color-picker tool in GIMP allows you to press a button and then click anywhere on the screen to select that color. I guess it basically is the same Wayland security issue than with making whole desktop screen-shots.

Wayland in GNOME: two progress reports

Posted Aug 17, 2014 11:47 UTC (Sun) by eru (subscriber, #2753) [Link]

If so, then also screen-sharing tools like Webex also become impossible to implement on top of Wayland. That would be a major loss, such tools are vital for teleconferencing. (Where I work, Webex is used so extensively that any OS that does not support it would be basically useless as the only desktop operating system.)

Wayland in GNOME: two progress reports

Posted Aug 17, 2014 13:11 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

It's very possible to implement such tools. They just require privileged access to the display, mediated by the composer.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 7:48 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

Perhaps the "video capturing/screenshot making/remote viewing/colour picking" overrides could be modelled after what OS X does?

There an application is also prohibited from interacting with another's content, but specific programs can be activated as "Accessibility Tools".

That's a bit of a hack, but some sort of "privileged access request" could be made and (optionally) cached by the compositor (preserved in it's global config or just for one session), but that would be up to the compositor to deal with).

Wayland in GNOME: two progress reports

Posted Aug 4, 2014 12:37 UTC (Mon) by salimma (subscriber, #34460) [Link]

Ah, similar to the way Android supports apps such as RescueTime (logs what apps you use), Pushbullet (routes your notifications across devices) and LastPass then.

Would be great if in the future such access can be further limited -- right now once an app registers as an accessibility tool you pretty much have to trust them not to abuse the privilege.

Wayland in GNOME: two progress reports

Posted Aug 6, 2014 8:54 UTC (Wed) by moltonel (subscriber, #45207) [Link]

That would work for a screenshot application (give the required privileges to a small tool), but it seems to defeat the purpose if you give those privileges to an app like GIMP, which supports plugins and is complex enough to be a realistic attack vector.

Delegating the color-picking rights to a service app is prone to abuse as well : unless that service add a UI and some constraints, a client app could color-pick all the screen's pixels to get a screenshot. Such a service (as an app or as a Wayland extension) sounds like the way to go though.

Wayland in GNOME: two progress reports

Posted Aug 13, 2014 0:31 UTC (Wed) by zlynx (subscriber, #2285) [Link]

For a program like GIMP you wouldn't want to read the screen to get the color value anyway. Because the color displayed on screen is merely an approximation of the real value.

For example, the display may be 8 bit per channel and the image 16 or 32 bits per channel.

That said, I know you probably picked GIMP just as an example.

Wayland in GNOME: two progress reports

Posted Aug 13, 2014 21:18 UTC (Wed) by ABCD (subscriber, #53650) [Link]

The issue with GIMP is that you do need to read the screen, as the GIMP color picker allows you to choose any pixel anywhere on the screen, not just one elsewhere in the same image (or even just another image loaded in the same editor).

Wayland in GNOME: two progress reports

Posted Aug 13, 2014 21:47 UTC (Wed) by zlynx (subscriber, #2285) [Link]

Yes, well, this design is silly and will need to change.

If you need the color of a screen object, take a screen shot and load that as an image.

If GIMP is still using screen color when picking colors from a GIMP image, that is a problem in my opinion, since as I said, it cannot be reading the real color.

Wayland in GNOME: two progress reports

Posted Aug 14, 2014 16:30 UTC (Thu) by nye (guest, #51576) [Link]

>Yes, well, this design is silly and will need to change.

"I don't use that feature, therefore you shouldn't have it either."

Personally, I've never actually needed to use colour profile support. I presume you'd be happy if I suggested removing that then?

(Also, it seems that people here are forgetting that GIMP, in common with most image editors, is capable of taking screenshots itself, so that's another feature that would have to be axed in the name of 'security'.)

Wayland in GNOME: two progress reports

Posted Aug 14, 2014 17:17 UTC (Thu) by zlynx (subscriber, #2285) [Link]

You can make fun, but you haven't addressed the problem of getting the real color vs. the display color.

Wayland in GNOME: two progress reports

Posted Aug 15, 2014 6:59 UTC (Fri) by iq-0 (subscriber, #36655) [Link]

Many people are happy with what they see vs. what it is.

For screengrabbing (and thus screencapture) what you see is probably also what you want (you want to record/capture what is being presented), so with possible loss of color depth.

For the color-picker you probably don't want to emulate that through screen capture and than afterward looking at the picture, but it could be done by grabbing/capturing just that surface (or what the term is in Wayland).
As I understand it, wayland allows for surfaces to be embedded/passed along to make better use of hardware rendering. If you can just grab/capture that surface and then look at that, than you would have your color value. The burden of handling all color schemes would than be a problem for the capturer, but it would prevent loss of information.

Wayland in GNOME: two progress reports

Posted Aug 15, 2014 8:06 UTC (Fri) by iq-0 (subscriber, #36655) [Link]

The actual grabbing/capturing should probably be handled by the compositor and should be a normal wayland protocol (you need internal information of the compositor and the compositor is in the possition to efficiently replicate updates to multiple targets).

But the (relatively) simple question about "should application X be allowed to capture/grab the screen" is one that the compositor would ideally not handle itself. That question can be delegated to an external process that checks the policy (by prompting for each use (with a possible "always" option) or by considering certain programs to be generic "accessibility tools" and should thus always be allowed to do that (screen readers, print screen handlers, etc.).
The details of implementation of the policy check is up to the compositor. It could well be desktop environment specific (or a Freedesktop standards proposal could be made, but that is outside of the Wayland scope). The only thing that the wayland protocol should specify is that such a policy might be in place and how a compositor should react if a policy is denied. (Should it be transparent to the requestor (empty buffer) or should it return a "access denied")

Wayland in GNOME: two progress reports

Posted Aug 25, 2014 0:43 UTC (Mon) by gmaxwell (guest, #30048) [Link]

Giving all of gimp the ability to grab the screen when only the very confined screenshot and color picker functionality need it seems foolish. Some local attack will just load gimp in the background and make it load a plugin that lets it sniff your screen; totally defeating the security feature of wayland.

Instead, there should be some split-out, highly confined programs that run as separate processes and can sniff the color of one pixel (or the average of some local area, based on switches) under the mouse; and another that grabs the screen or another window but only after providing a dialog. Then gimp can just invoke these programs— preserving the functionality for the user but not totally bypassing the very useful security improvement.

The same thing should be done for file access in the SELinux environments for the vast majority of desktop applications which need to only access their own data plus a few files specified by the user which are always accessed via a file chooser.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 7:57 UTC (Thu) by ncm (subscriber, #165) [Link]

Color picking seems important enough to be a top-level feature. There is no security problem if a user action is required for each pick.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 13:37 UTC (Thu) by sebas (subscriber, #51660) [Link]

That user action is within the application's domain, but the access control is not. That means that GIMP can be sure that it's a result of a user action, but the compositor (who ultimately reveals the color of the pixel in question) will have to trust GIMP. The latter is the concern, how much can we trust GIMP (or any other application that says it wants to pick a color, or make a screenshot (which is mostly the same thing)? Wayland says that we don't, and that's a secure default. Apps cannot override it just like that, the compositor has to allow access.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 16:45 UTC (Thu) by magcius (guest, #85280) [Link]

It's possible to delegate picking a color from the screen to a higher level component privileged component. The GIMP asks "hey, compositor, please pick me a screen color", and then the compositor asks the user to pick a color, and doesn't return until it has picked one.

That doesn't have any security issues, because it can't use that interface to steal the screen contents.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 18:48 UTC (Thu) by robclark (subscriber, #74945) [Link]

> That doesn't have any security issues, because it can't use that interface to steal the screen contents.

except you could one by one request the color of every pixel..

possibly rate-limiting requests is a reasonable compromise for someone who has desktop configured in a more permissive mode?

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 20:31 UTC (Thu) by Karellen (subscriber, #67644) [Link]

Except that the app does not get to pick which pixel to get the color of, it just asks the compositor to ask the user to pick a color from somewhere.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 20:45 UTC (Thu) by drago01 (subscriber, #50715) [Link]

Yeah you'd get the color of the pixel the user selects ... so you ask for a color and get a color back (or nothing it the user cancels the operation) without even knowing where the user clicked. You don't say "please give me the color of pixel [x, y]" ... that would be indeed pointless.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 20:47 UTC (Thu) by robclark (subscriber, #74945) [Link]

oh, yeah, ofc.. then screen-picker proto similar to screenshots..

Wayland in GNOME: two progress reports

Posted Aug 7, 2014 21:33 UTC (Thu) by ssokolow (guest, #94568) [Link]

Given the utility of an Inkscape-style "average this circular zone of JPEG'd color" picker, why not just use the same protocol for screenshots and color picking and allow the application to request screenshotting of "an X-by-Y region centered on the user's cursor"?

Wayland in GNOME: two progress reports

Posted Aug 4, 2014 18:36 UTC (Mon) by drag (guest, #31333) [Link]

> except you could one by one request the color of every pixel..

That's a awful lot of click on the part of guy choosing the pixel.

Having the compositor carry out privileged tasks on behalf of applications seems like a acceptable solution.

It's quite easy to imagine a situation were a application has a legit reason to grab a screen capture. Gnome-shell has the desktop record feature built-in so you can encode images of your desktop activity into video files.

To have in secure seems simple enough:

Application requests image/video/pixel capture, sends requests to compositor, compositor communicates with user to initiate the capture, and then compositor provides path to the data back to the application when it is finished writing it out to the file system (or whatever)

Wayland in GNOME: two progress reports

Posted Aug 10, 2014 7:54 UTC (Sun) by jkhanlar (guest, #98262) [Link]

What about an implementation in which users can customize/configure secure access (or restriction) to particular functionalities per application or pid such that once an application is granted access to, for example, retrieving color of a particular pixel, a user is no longer prompted unless atick/check does not exist to preserve or remember the setting?

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 15:42 UTC (Thu) by iabervon (subscriber, #722) [Link]

It seems to me that color-picking (and screenshots) should be a compositor feature. Rather than being something that Wayland would let GIMP do, the compositor would simply include, among the window system interaction features, drag-and-drop individual pixels and screenshots.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 18:25 UTC (Thu) by gioele (subscriber, #61675) [Link]

> the compositor would simply include, among the window system interaction features, drag-and-drop individual pixels and screenshots.

It is reasonable to have the compositor handle the screenshotting mechanism, but I think it should be the role of a 3rd-party application to trigger that mechanism, or at least to receive the output of that mechanism.

Maybe a solution could be to have the compositor waiting for "take a screenshot" actions (key combinations, gestures, etc.) and then launch a user-specified application to handle the results. Applications like gimp could configure themselves as temporary screenshot receivers while gnome-screenshot, for example, would be the default receiver.

Wayland in GNOME: two progress reports

Posted Jul 31, 2014 18:49 UTC (Thu) by iabervon (subscriber, #722) [Link]

My idea was that the receiver of the output would be chosen like the receiver of any other cross-application drag-and-drop operation. Of course, the application would have to accept drag-and-drop image data (rather than just filenames of images), but that's an independently-desirable feature anyway. Probably the right thing for saving screenshots would be for the file manager to simply accept drag-and-drop to create a new file.

screenshot-like needs

Posted Aug 4, 2014 0:09 UTC (Mon) by pjm (subscriber, #2080) [Link]

Two other use cases to consider are recording of desktop or a single app (continuous screenshots), and screen magnification tools (xmag etc.).

screenshot-like needs

Posted Aug 17, 2014 11:49 UTC (Sun) by eru (subscriber, #2753) [Link]

Also collaboration tools that do screen sharing, like Webex.

Wayland in GNOME: two progress reports

Posted Aug 2, 2014 23:21 UTC (Sat) by meyert (subscriber, #32097) [Link]

Will mutter get RDP or VNC support, so I can use gnome via network from a Systemd-nspawn or uml container? Weston seems to already have RDP support.

Wayland in GNOME: two progress reports

Posted Aug 3, 2014 15:20 UTC (Sun) by magcius (guest, #85280) [Link]

We'll eventually support wl_fullscreen_shell which will allow us to get RDP and VNC support.

Wayland in GNOME: two progress reports

Posted Aug 3, 2014 7:53 UTC (Sun) by job (guest, #670) [Link]

I am a bit wary about the state of OpenGL on Linux and how it affects Wayland. I believe Wayland applications, like earlier X-replacements, use GL to blit stuff to the screen?

This sounds like what we want in theory, and will probably make it easier to write graphic drivers, but for now it is almost unusable in the Linux world. The only driver that is reasonably feature complete and only somewhat unstable is Intel, the other is absolute crap and does not seem to get better.

Is it going to get better, or will everyone have to switch to Intel? Where does that leave the professional 3D workstations?

Wayland in GNOME: two progress reports

Posted Aug 3, 2014 11:48 UTC (Sun) by tao (subscriber, #17563) [Link]

What does those "professional 3D" workstations use if they don't use OpenGL for 3D?

Wayland in GNOME: two progress reports

Posted Aug 12, 2014 12:22 UTC (Tue) by nye (guest, #51576) [Link]

>What does those "professional 3D" workstations use if they don't use OpenGL for 3D?

They do use OpenGL, but with Nvidia's binary Xorg driver.

Wayland in GNOME: two progress reports

Posted Aug 12, 2014 12:49 UTC (Tue) by tao (subscriber, #17563) [Link]

Well, then I guess you should direct your question towards NVidia.

Wayland in GNOME: two progress reports

Posted Aug 13, 2014 12:15 UTC (Wed) by nye (guest, #51576) [Link]

That comment seems like a non-sequitur to me?

Wayland in GNOME: two progress reports

Posted Aug 13, 2014 17:57 UTC (Wed) by tao (subscriber, #17563) [Link]

The open drivers can only ever be expected to be as good as the documentation allows them to be. Hence the open drivers for NVidia (and until recently ATI) are/have been crippled, since there's hardly any information available.

The closed drivers are at the mercy of NVidia, ATI, etc.

If you expect to do things that requires getting the most out of the hardware, you'll need a drivers written will full specs available. That means either through NVidia/ATI releasing said specs, or writing the driver themselves.

It's reasonable to expect that Wayland/Xorg uses opengl in a sensible manner, it's reasonable to expect that the kernel provides a vendor neutral way to handle direct rendering, framebuffers, etc., but anything beyond that requires either extreme amounts of reverse engineering or vendor support. The former is a serious waste of time and is unlikely to happen except in situations when no options are supported. Since one vendor has fully working drivers (Intel) and one vendor is trying to catch up (ATI) it doesn't take a genius to realise that developers, when poked about NVidia issues, will tell you to buy other hardware or ask your vendor to provide docs or an updated driver.

So. If the open drivers are under-performing on your hardware, and it's hardware for which little or no documentation exists, either ask for an updated closed driver, or documentation to help the open driver along.

Wayland in GNOME: two progress reports

Posted Aug 14, 2014 9:07 UTC (Thu) by etienne (guest, #25256) [Link]

> either ask for an updated closed driver, or documentation to help the open driver along.

And if none is given by the company you gave money to, then stop giving them money, and tell it competitors you have cash available for the features you need.
Basically vote with your wallet, and be consistent.

Wayland in GNOME: two progress reports

Posted Aug 14, 2014 16:25 UTC (Thu) by nye (guest, #51576) [Link]

All this is fair enough, but I think what job was asking was really more of a directly practical question: 'is it realistic in this world to expect that the situation WRT using OpenGL for Wayland will improve to a reasonably good state within a reasonable timeframe?'

It's likely the case that the people most able to actually *alter* the answer to that question are Nvidia, because so much of the time it will hinge upon their drivers, but simply answering the question itself is a different matter, and it looks like the Wayland developers are probably in the best position to know - and based on magcius's comment, it appears that they do indeed know something.

Wayland in GNOME: two progress reports

Posted Aug 15, 2014 19:14 UTC (Fri) by ThinkRob (subscriber, #64513) [Link]

> Hence the open drivers for NVidia (and until recently ATI) are/have been crippled, since there's hardly any information available.

I'm not so sure you can use that excuse. AMD opened their card documentation seven years ago. The open drivers still suck. In that time, Intel's drivers have gone from complete crap to being the top of the open-source heap.

Wayland in GNOME: two progress reports

Posted Aug 17, 2014 11:14 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Suck in which way? I haven't had nearly as many issues with the radeon driver compared to catalyst (completely broken) and nvidia (crashy and quirky for my use cases).

Wayland in GNOME: two progress reports

Posted Aug 24, 2014 21:41 UTC (Sun) by ThinkRob (subscriber, #64513) [Link]

> Suck in which way?

Suck compared to the closed-source drivers on every other platform.

Wayland in GNOME: two progress reports

Posted Aug 24, 2014 21:50 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

I find that the free driver for AMD parts renders the games I want to play both slowly and incorrectly, while the proprietary driver renders them correctly and at an acceptable frame rate.

Wayland in GNOME: two progress reports

Posted Aug 25, 2014 19:54 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Ah. I don't play games on my Radeon machine (it does do scientific visualization and triple monitor though just fine). Nouveau and Intel have been adequate for me though.

Wayland in GNOME: two progress reports

Posted Aug 3, 2014 15:23 UTC (Sun) by magcius (guest, #85280) [Link]

Wayland applications can use OpenGL or wl_shm_buffer to present their buffers to the compositor. Most toolkits like Qt, EFL and GTK+ actually use wl_shm_buffer right now.

As for OpenGL support, nouveau and radeon are actually quite good now; they've improved somewhat considerably in the past year after power management aren't pegging the drivers at the lowest possible speed.

NVIDIA is working on Wayland support in their proprietary driver. I don't have anything I can share publicly yet, unfortunately.

Wayland in GNOME: two progress reports

Posted Aug 5, 2014 23:41 UTC (Tue) by nix (subscriber, #2304) [Link]

Actually in radeon's case it was pegged at the default speed, which for a lot of desktops was the highest speed, or at least a reasonably usable not-lowest one. Still, PM is a huge improvement (it cut my desktop's power budget by 30W :) ).

Clipboard as a window system feature ?

Posted Aug 6, 2014 9:06 UTC (Wed) by moltonel (subscriber, #45207) [Link]

I tought that clipboard support would be one of X's features that Wayland would drop, because it really doesn't have anything to do with the window system and you could implement it as a system service instead.

Am I missing something here, does copy-paste depend on the window system for some feature or performance ? Or does Wayland handle clipboards just out of habit, or because it took less time to implement ?

Clipboard as a window system feature ?

Posted Aug 6, 2014 9:25 UTC (Wed) by moltonel (subscriber, #45207) [Link]

Just spoted https://lwn.net/Articles/604421/ discussing this.

Clipboard as a window system feature ?

Posted Aug 6, 2014 20:04 UTC (Wed) by magcius (guest, #85280) [Link]

All Wayland is used for in the case of clipboard is to provide negotiation between the two clients.

The linked comment doesn't make any sense, and we won't support a model like that. Copying a giant image file should not dump it out to disk when the application already has it in memory, and certainly not in every format that can be transferred up-front. That would completely sacrifice performance, especially because applications re-take the clipboard when selecting text.


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds