Kristian H. Kristensen
2,173 followers -
Casually defiant, inadvertently pretentious.
Casually defiant, inadvertently pretentious.
2,173 followers
Posts
Post has shared content
Got a fully sandboxed game running under xdg-app in a wayland session!
Add a comment...
Post has shared content
A general overview of libinput and why it is needed
http://who-t.blogspot.com.au/2014/09/libinput-common-input-stack-for-wayland.html
http://who-t.blogspot.com.au/2014/09/libinput-common-input-stack-for-wayland.html
Add a comment...
Post has shared content
'There is also "a long list of kluges" that make X work for SteamOS, [keithp] said.'
Reinforcing the point I made about X11 a while ago: it's entirely possible to (eventually) ship products with it, but out-of-the-box? Good luck. That kind of work can be super-profitable for consulting houses like ourselves, but really doesn't bring much joy.
Reinforcing the point I made about X11 a while ago: it's entirely possible to (eventually) ship products with it, but out-of-the-box? Good luck. That kind of work can be super-profitable for consulting houses like ourselves, but really doesn't bring much joy.
Add a comment...
Post has shared content
The potential here is off the chart...
Add a comment...
Post has shared content
Had to cancel my trip to XDC and LPC last minute 😞
Add a comment...
Post has shared content
Originally shared by ****
Announcing the addition of #Wayland support with the release of +Qt Project's 5.4 release. It's going to be in rough shape to start with, but it's something. Come help make it more awesome? :-)
Thanks to a very large cast of folks for helping this happen!
Thanks to a very large cast of folks for helping this happen!
Add a comment...
Post has shared content
Dear browser developers,
I know you wish our graphics drivers were less buggy.. I have a proposal: help us help you. A few tools to help graphics dev's debug driver problems would, I think, go a long way. A couple things that I think would help:
1) Standalone webgl runner. Ideally it would be nice to have this for both chromium and firefox, since somehow I see different behaviour in both. (Maybe just chromium re-writing shaders to add bounds checking?)
2) Easier way to get apitrace of gpu process (perhaps more chromium specific, but..). It seems like when gpu process crashes and is restarted, something has enough knowledge of gl state to replay things for the incoming gpu process. Seems like it wouldn't be too hard to invent some mechanism to kill gpu process, relaunch it for one frame w/ apitrace, then kill it again. Having an apitrace for a single frame is going to be much easier than having a trace from the time you launched the browser.
On the chromium side of things, I eventually managed to figure out a few useful tidbits, like --disable-gpu-watchdog, and how to launch gpu process under gdb.. but it certainly could be easier to find info about how to debug graphics drivers under $browser.. remember, we are not all browser experts too.
Probably other mesa devs have other suggestions (or even closed src driver dev's, if they are allowed to speak in public). Possibly some of this exists already and I just didn't google for the right things. But graphics drivers are complicated.. web browsers are complicated.. debugging the combination is not currently so great as far as I can tell.
I know you wish our graphics drivers were less buggy.. I have a proposal: help us help you. A few tools to help graphics dev's debug driver problems would, I think, go a long way. A couple things that I think would help:
1) Standalone webgl runner. Ideally it would be nice to have this for both chromium and firefox, since somehow I see different behaviour in both. (Maybe just chromium re-writing shaders to add bounds checking?)
2) Easier way to get apitrace of gpu process (perhaps more chromium specific, but..). It seems like when gpu process crashes and is restarted, something has enough knowledge of gl state to replay things for the incoming gpu process. Seems like it wouldn't be too hard to invent some mechanism to kill gpu process, relaunch it for one frame w/ apitrace, then kill it again. Having an apitrace for a single frame is going to be much easier than having a trace from the time you launched the browser.
On the chromium side of things, I eventually managed to figure out a few useful tidbits, like --disable-gpu-watchdog, and how to launch gpu process under gdb.. but it certainly could be easier to find info about how to debug graphics drivers under $browser.. remember, we are not all browser experts too.
Probably other mesa devs have other suggestions (or even closed src driver dev's, if they are allowed to speak in public). Possibly some of this exists already and I just didn't google for the right things. But graphics drivers are complicated.. web browsers are complicated.. debugging the combination is not currently so great as far as I can tell.
Add a comment...
Post has shared content
+Daniel Stone explains why the Weston windows rotate. And many other good points about Wayland. Very well written, do read this.
A longer reply to +Siarhei Siamashka (have been travelling / on leave with awful internet). The point of the demonstration is not that it's possible to watch periodically-rotating videos, as I'd hoped you'd gathered: obviously that's a terrible user experience.
I take it as axiomatic that a composited desktop is a hard requirement in 2014, as the alternative (especially in classic X11) looks abysmal and performs about as well. So, given that, and the design of the Composite extension, how do you go about running video from an X11 client, through an X11 compositing manager, and then to the screen, choosing at each repaint whether to run the video through GLES, or whether to offload to an overlay? And even better, all this without the client being involved (since roundtrips are hell, and the client dependency adds one additional point of interdependency / failure / variable capability)?
The point is what it brings relative to X11: a composited environment where zerocopy media can be opportunistically offloaded to overlays, or take one copy in a traditional GLES compositing pass if required. You can argue about the choice of driver if you want and suggest the sunxi-specific driver (which doesn't work on Exynos anyway, no?), but I refuse to take fbdev seriously in 2014. It's been deprecated for years, is unusable for any serious needs (no pageflipping? overlays and multihead require separate devices? yeesh), unless they are 'solved' by elaborate per-vendor hacks leaving you at the mercy of not just every individual driver, but every kernel driver / X11 driver combination.
Not only that, but if you want to upstream anything (which you should: our kernel was ~150 quite well-split patches on top of mainline, of which I believe the majority are already merged/queued for 3.17), you cannot do it with fbdev. So if you want to escape forked-vendor-tree hell, it has to be KMS.
We actually went through about all of these fbdev/X11 driver combinations for a client project a few months ago, finding many that could do part of what we wanted, but none of which fulfilled both our functional and performance requirements.
The two-minute video obviously didn't provide a lot of nuance, but one of the great things about Wayland isn't even Wayland itself, but the work that has gone into KMS, GBM, EGL/Mesa, and so on, and so forth, over the past few years, that makes our driver situation so much less of a joke. All - literally all - of the feature development for this demo was done on Intel hardware (whatever laptops Pekka, George, et al had to hand), and only brought to Exynos very late in the game. The first time I ran Weston on these devices, everything worked instantly out of the box, including overlay offload.
There was no specific tuning done: not on Weston (which is why you can see the latency graph doesn't actually flatline; the lower-spec Sintel video had the graph almost completely flat, but we changed to HD Blender Foundation videos at the last minute), and not on X11 either. We took the ChromeOS driver as it has seen extensive work on both performance and stability, particularly on Mali 6xx, and is the only X11 driver I trust.
We tried as hard as possible to make this an apples-to-apples comparison, though for reasons I'll get into later (short version: X11 drives the internal panel thus increasing power consumption; however big.LITTLE cpufreq is very incomplete and can't actually do voltage scaling of either the core CPU or the Mali, so Wayland gets absolutely hammered by not being able to pull down the power), the power numbers are not representative of the final result. I honestly had no idea the CPU load and frame latency (which is actually deviation between GStreamer-predicted presentation time and the actual final presentation time) would be so very high.
I've been arguing the benefits of Wayland for years, but not through deception. I believe it should and can win a clean fight on its merits alone, and has.
I take it as axiomatic that a composited desktop is a hard requirement in 2014, as the alternative (especially in classic X11) looks abysmal and performs about as well. So, given that, and the design of the Composite extension, how do you go about running video from an X11 client, through an X11 compositing manager, and then to the screen, choosing at each repaint whether to run the video through GLES, or whether to offload to an overlay? And even better, all this without the client being involved (since roundtrips are hell, and the client dependency adds one additional point of interdependency / failure / variable capability)?
The point is what it brings relative to X11: a composited environment where zerocopy media can be opportunistically offloaded to overlays, or take one copy in a traditional GLES compositing pass if required. You can argue about the choice of driver if you want and suggest the sunxi-specific driver (which doesn't work on Exynos anyway, no?), but I refuse to take fbdev seriously in 2014. It's been deprecated for years, is unusable for any serious needs (no pageflipping? overlays and multihead require separate devices? yeesh), unless they are 'solved' by elaborate per-vendor hacks leaving you at the mercy of not just every individual driver, but every kernel driver / X11 driver combination.
Not only that, but if you want to upstream anything (which you should: our kernel was ~150 quite well-split patches on top of mainline, of which I believe the majority are already merged/queued for 3.17), you cannot do it with fbdev. So if you want to escape forked-vendor-tree hell, it has to be KMS.
We actually went through about all of these fbdev/X11 driver combinations for a client project a few months ago, finding many that could do part of what we wanted, but none of which fulfilled both our functional and performance requirements.
The two-minute video obviously didn't provide a lot of nuance, but one of the great things about Wayland isn't even Wayland itself, but the work that has gone into KMS, GBM, EGL/Mesa, and so on, and so forth, over the past few years, that makes our driver situation so much less of a joke. All - literally all - of the feature development for this demo was done on Intel hardware (whatever laptops Pekka, George, et al had to hand), and only brought to Exynos very late in the game. The first time I ran Weston on these devices, everything worked instantly out of the box, including overlay offload.
There was no specific tuning done: not on Weston (which is why you can see the latency graph doesn't actually flatline; the lower-spec Sintel video had the graph almost completely flat, but we changed to HD Blender Foundation videos at the last minute), and not on X11 either. We took the ChromeOS driver as it has seen extensive work on both performance and stability, particularly on Mali 6xx, and is the only X11 driver I trust.
We tried as hard as possible to make this an apples-to-apples comparison, though for reasons I'll get into later (short version: X11 drives the internal panel thus increasing power consumption; however big.LITTLE cpufreq is very incomplete and can't actually do voltage scaling of either the core CPU or the Mali, so Wayland gets absolutely hammered by not being able to pull down the power), the power numbers are not representative of the final result. I honestly had no idea the CPU load and frame latency (which is actually deviation between GStreamer-predicted presentation time and the actual final presentation time) would be so very high.
I've been arguing the benefits of Wayland for years, but not through deception. I believe it should and can win a clean fight on its merits alone, and has.
Add a comment...
Post has attachment
Wait while more posts are being loaded