Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
http://wayland.freedesktop.org/
Regards, Dennis
On 11/05/2010 06:41 AM, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
Considering that it was started by a Red Hat employee, I would say there has already been some involvement
Rahul
On Fri, Nov 5, 2010 at 2:10 AM, Rahul Sundaram metherid@gmail.com wrote:
Considering that it was started by a Red Hat employee, I would say there has already been some involvement
a cursory look at who has private branches of it on git.freedesktop.org is also good indication as to where the involvement has been and where it hasn't. All I'll say is talk is cheap.
A cursory look tells me things are still coming together and that the _right_ people have a roadmap in place...well ahead of any announcement of Unity.
I'm more than happy to give Shuttleworth the benefit of the doubt about the sincerity of his interest and I will be watching the Wayland commit logs closely looking for Canonical sponsored contributions to _start_ trickling in.
-jef
2010/11/5 Jeff Spaleta jspaleta@gmail.com
[...] I'm more than happy to give Shuttleworth the benefit of the doubt about the sincerity of his interest and I will be watching the Wayland commit logs closely looking for Canonical sponsored contributions to _start_ trickling in. [...]
What does this mean, wait until Canoncial provides patches before taking a look at interresting technologies? Or even better, don't use applications where Canoncial don't provide patches? That means that a lot of application can't be used in the future and I don't think that this is an useful approach.
Kind regards, Thomas
On Fri, Nov 5, 2010 at 12:23 PM, Thomas Bendler ml@bendler-net.de wrote:
What does this mean, wait until Canoncial provides patches before taking a look at interresting technologies? Or even better, don't use applications where Canoncial don't provide patches? That means that a lot of application can't be used in the future and I don't think that this is an useful approach.
Wait for Canonical? No of course not. I'm saying that for anyone who cares the history of the actual Wayland development tells a certain story of existing involvement in bringing the technology forward by a number of individuals, some of them active members of other upstream communities (and who just happen to be members of Fedora's development community as well). Work to make Wayland an integral part of the standard plumbing stack is already underway as part of substantiate upstream work with input from developers from this community. Anyone under the impression that somehow Shuttleworth's announcement is in any way significant outside the scope of Unity as a new and differentiated interface offering hasn't been watching what has already been going on. The head-down, nose-to-the-grindstone development work that has been going on as part of upstream interactions around Wayland and X and Qt and gtk has been going on and will continue to go on regardless of what Canonical does or does not do moving forward.
The final packaging at the distribution level as a binary blob is literally the last 0.1% of the work going on to make it a usable piece of the technology plumbing. Once you look at the history, its obvious that things need a little more work, and its just as obvious that there is a real intention to see support for Wayland deeply integrated into upstream stacks suck as GNOME. It means that people associated with our development community are already working on it..well before the human hype machine decided to blog about it and bring up the visibility of the already ongoing effort.
-jef
Le 05/11/2010 03:10, Rahul Sundaram a écrit :
On 11/05/2010 06:41 AM, Dennis Jacobfeuerborn wrote:
Considering that it was started by a Red Hat employee, I would say there has already been some involvement
Rahul
Kristian does not work for Red Hat anymore but at Intel OSTC. Will Ubuntu really move towards Wayland and furthermore start working upstream on it ? let's wait and see. By the way, is Wayland really usable and since Kristian's departure, is Red Hat still involved in the project ?
H.
On Friday, November 05, 2010 08:17:17 am Haïkel Guémar wrote:
Le 05/11/2010 03:10, Rahul Sundaram a écrit :
On 11/05/2010 06:41 AM, Dennis Jacobfeuerborn wrote:
Considering that it was started by a Red Hat employee, I would say there has already been some involvement
Rahul
Kristian does not work for Red Hat anymore but at Intel OSTC. Will Ubuntu really move towards Wayland and furthermore start working upstream on it ? let's wait and see. By the way, is Wayland really usable and since Kristian's departure, is Red Hat still involved in the project ?
Intel and Nokia seems to be very interested in this project for MeeGo stuff and embedded systems (like smartphones etc.). So I think it has a quite good backing to be further developed. Even Qt is now ported to Wayland, I expected just another graphics system port but they are working on complete own architecture - next to win, x11, macosx (not only gfx, but events etc.)
Jaroslav
H.
On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Rich.
On Fri, Nov 05, 2010 at 11:57:56AM +0000, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
You can run an X server as a client of Wayland, so you should get full compat with any existing X app usage. Similar to how you can run an X server under OS-X or Win32.
Regards, Daniel
On Fri, Nov 05, 2010 at 12:07:30PM +0000, Daniel P. Berrange wrote:
On Fri, Nov 05, 2010 at 11:57:56AM +0000, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
You can run an X server as a client of Wayland, so you should get full compat with any existing X app usage. Similar to how you can run an X server under OS-X or Win32.
The situation on OS X is pretty sucky (and Win32 as well, but for many more reasons).
Native OS X apps aren't network transparent. You just can't run them remotely at all without some horrible thing like VNC.
X11 apps are second-class citizens, requiring longer start-up times, incompatible menus, poor cut and paste and poor font rendering.
If we're advocating that situation, then this is a huge step backwards. Network transparency in particular is absolutely essential to me as a user. Stepping to a pre-Internet non-network-aware single user model is simply crazy.
Nevertheless, no one has actually answered the question as to whether Wayland native apps are network transparent or not. Do they use the X protocol at all? $DISPLAY? (And I admit I ain't looked at the code to try to answer these questions either).
Rich.
On Friday, November 05, 2010 12:57:56 pm Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
You can run standard X server on top of Wayland. See Wayland architecture link [1]. For native Wayland apps you have to use different approach.
[1] http://wayland.freedesktop.org/architecture.html
Jaroslav
Rich.
On Fri, Nov 5, 2010 at 11:57 AM, Richard W.M. Jones rjones@redhat.com wrote:
What's the implication for people who absolutely need to use X applications remotely?
I believe the idea for the overall plan is that the traditional X server grows the ability to be a Wayland client and that any normal distribution would be shipping and X server as Wayland client.
Now if you aren't a traditional distribution and plan to build something like a mobileOS with its own walled garden...the X server as Wayland client isn't so necessary. -jef
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
Bill
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
Rich.
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
On the net I read that Ubuntu wants to "ditch X" in favor of Wayland but that's not what I read in Marks post. As I understand it the plan is to introduce Wayland but not get rid of X for years to come. Sounds like a reasonable plan if it can be implemented in a technically feasible way.
Regards, Dennis
On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote:
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
Rich.
If I wanted to step back to the pre-net era, I'd run Windows.
I wonder if there will be someone saying (when all the apps are native Wayland apps) "If I wanted to step back to the pre-stetic* era, I'd run X"
I get the impression that comparing current Fedora and Linux in general running on varied hardware to the latest Windows and MacOS examples reveals a lack of slickness that is easy for Linux fans to make excuses for. I frequently see low frame rates, tearing and high CPU usage (and put up with them). But it shows that current X based desktops are hitting a barrier that there isn't sufficient development effort to overcome. I have a rough idea of the hoops that software has to jump through to provide a smooth scrolling browser window (for example). Something that improves this can only be good for the desktop.
I don't think that there is a realistic threat that GUI based tools etc will ever need tight media integration or be balkanised so that they are not usable over the net. And I don't think it's a valid reason to shun technologies that might bring the desktop experience up to modern standards.
-Cam
* I nearly wrote haptic but it's really more than that.
On Sat, Nov 06, 2010 at 09:20:08AM +0000, Camilo Mesias wrote:
If I wanted to step back to the pre-net era, I'd run Windows.
I wonder if there will be someone saying (when all the apps are native Wayland apps) "If I wanted to step back to the pre-stetic* era, I'd run X"
I get the impression that comparing current Fedora and Linux in general running on varied hardware to the latest Windows and MacOS examples reveals a lack of slickness that is easy for Linux fans to make excuses for. I frequently see low frame rates, tearing and high CPU usage (and put up with them). But it shows that current X based desktops are hitting a barrier that there isn't sufficient development effort to overcome. I have a rough idea of the hoops that software has to jump through to provide a smooth scrolling browser window (for example). Something that improves this can only be good for the desktop.
I don't think that there is a realistic threat that GUI based tools etc will ever need tight media integration or be balkanised so that they are not usable over the net. And I don't think it's a valid reason to shun technologies that might bring the desktop experience up to modern standards.
Is Fedora for developers or what?
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window? [I do *not* see any of those issues incidentally -- maybe you want to check your set-up and make sure you're not using non-free drivers]
You have no evidence anyway that this tearing and high CPU load that you are seeing is caused by network transparency.
It's pretty unlikely since X messages are passed from application to server using shared memory in the local case, and how exactly did you expect the app to communicate with a Wayland server except using the precise same mechanisms? There are only a limited number of ways that two processes on a Unix machine can talk to each other.
Rich.
Is Fedora for developers or what?
If it is exclusively for developers with the exclusion of general purpose features such as web browsing, photo management, and multimedia consumption then I'll have to find a more general purpose OS. I count myself as a developer but concede that I have a life too and a general purpose computer has to fit into that as a whole.
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window? [I do *not* see any of those issues incidentally -- maybe you want to check your set-up and make sure you're not using non-free drivers]
Historically there have been plenty of problems like the Firefox smooth scrolling under compiz bugs (at the time I understood the bugs to be caused by the difficulties of providing compiz features within the framework of X, I could be wrong). I last noticed tearing in fullscreen video on radeon HW... on other hardware I use the nvidia driver as it's generally better performing than the free one, really there is no argument here regarding free drivers as a platform for a multimedia desktop. As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
You have no evidence anyway that this tearing and high CPU load that you are seeing is caused by network transparency.
No, but I can guess that something in the architecture as a whole is causing it to underperform, exploring an alternative might provide that evidence. I don't want to throw X away per se, but I would like comparable performance to other OSs.
It's pretty unlikely since X messages are passed from application to server using shared memory in the local case, and how exactly did you expect the app to communicate with a Wayland server except using the precise same mechanisms? There are only a limited number of ways that two processes on a Unix machine can talk to each other.
I can hope that an architecture with the lofty aims of "every frame perfect" would make a more usable desktop. It looks like the alternative is to stick with X and see other OSs lead the way in slickness.
Maybe I'm biased because I overwhelmingly tend to use a command line for remote machines. What is the use case for remote X applications? The only thing I can think of that I've personally used this way is gparted, and I probably could have used fdisk without much effort.
-Cam
On Sat, Nov 06, 2010 at 11:51:37AM +0000, Camilo Mesias wrote:
Is Fedora for developers or what?
If it is exclusively for developers with the exclusion of general purpose features such as web browsing, photo management, and multimedia consumption then I'll have to find a more general purpose OS. I count myself as a developer but concede that I have a life too and a general purpose computer has to fit into that as a whole.
I believe it is possible to do photo management, web browsing and watching video, even on the current version of Fedora.
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window? [I do *not* see any of those issues incidentally -- maybe you want to check your set-up and make sure you're not using non-free drivers]
Historically there have been plenty of problems like the Firefox smooth scrolling under compiz bugs (at the time I understood the bugs to be caused by the difficulties of providing compiz features within the framework of X, I could be wrong). I last noticed tearing in fullscreen video on radeon HW... on other hardware I use the nvidia driver as it's generally better performing than the free one, really there is no argument here regarding free drivers as a platform for a multimedia desktop. As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
So in fact you are running non-free drivers. I have none of these problems with the free (Intel) drivers, and the performance is great, certainly more than adequate for web browsing, watching DVDs and video, and a little gaming.
Maybe I'm biased because I overwhelmingly tend to use a command line for remote machines. What is the use case for remote X applications? The only thing I can think of that I've personally used this way is gparted, and I probably could have used fdisk without much effort.
With virtualization I have more Linux machines than ever (about 50 in active use at last count). All on my local 1GB network. Consequently I use X to them and to other physical machines _all the time_.
Rich.
I believe it is possible to do photo management, web browsing and watching video, even on the current version of Fedora.
Indeed. It's not the point that it's possible or not. I could do much of that on a Windows 3.11 machine... Be honest with yourself, is it every bit as good as the experience on a non-free OS and software stack? I don't think it is.
So in fact you are running non-free drivers. I have none of these problems with the free (Intel) drivers, and the performance is great, certainly more than adequate for web browsing, watching DVDs and video, and a little gaming.
I am running several machines, including Intel based, low end radeon and Nvidia, like a lot of users... I also use, shock horror, non free software, because I am pragmatic about getting the most out of the machine rather than living in a free software hairshirt. I think that if the infrastructure was more geared towards performance then maybe the free apps would provide a more Mac-like experience instead of being also-rans. But I don't want to beat up free software or X, I just want the best possible experience from the desktop.
With virtualization I have more Linux machines than ever (about 50 in active use at last count). All on my local 1GB network. Consequently I use X to them and to other physical machines _all the time_.
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience? I have to use a Windows laptop for work, and use many Linux VM servers, often set up for specific tasks or with specific networking. The way our organisation works (having tried lots of different approaches) is using NoMachines (which is X in a way). My point is that although X is involved at some point there are significant parts of the solution that aren't X - it still works.
If there is no way to provide remote access for Weyland based systems (and I hope there will be a way that is "more than adequate") then I can see the day when desktop users wanting a high quality experience and server users part company...
-Cam
On Sat, Nov 06, 2010 at 01:51:32PM +0000, Camilo Mesias wrote:
I believe it is possible to do photo management, web browsing and watching video, even on the current version of Fedora.
Indeed. It's not the point that it's possible or not. I could do much of that on a Windows 3.11 machine... Be honest with yourself, is it every bit as good as the experience on a non-free OS and software stack? I don't think it is.
Perfectly honestly, yes, it's much better than OS X now.
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience?
I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC.
Rich.
On Sat, Nov 6, 2010 at 1:56 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Nov 06, 2010 at 01:51:32PM +0000, Camilo Mesias wrote:
I believe it is possible to do photo management, web browsing and watching video, even on the current version of Fedora.
Indeed. It's not the point that it's possible or not. I could do much of that on a Windows 3.11 machine... Be honest with yourself, is it every bit as good as the experience on a non-free OS and software stack? I don't think it is.
Perfectly honestly, yes, it's much better than OS X now.
I really can't see this, so I will be keen to vote with my desktop and test Wayland as soon as possible.
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience?
I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC.
We use both approaches, I suppose both have their merits, and we shouldn't rule out either method of working.
-Cam
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience?
I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC.
We use both approaches, I suppose both have their merits, and we shouldn't rule out either method of working.
-Cam
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
One of the many concerns I have with Wayland involves VNC. Right now VNC on X uses some of the multiuser functions to enable multiple VNC consoles. Will Wayland still allow for this or will we be back to Windows with only one VNC session per computer. Linux/Unix is designed around multiuser/multisession, I believe we would be amiss to remove those capabilities from the OS.
On 11/06/2010 04:16 PM, Mark Bidewell wrote:
Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience?
I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC.
We use both approaches, I suppose both have their merits, and we shouldn't rule out either method of working.
-Cam
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
One of the many concerns I have with Wayland involves VNC. Right now VNC on X uses some of the multiuser functions to enable multiple VNC consoles. Will Wayland still allow for this or will we be back to Windows with only one VNC session per computer. Linux/Unix is designed around multiuser/multisession, I believe we would be amiss to remove those capabilities from the OS.
First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there. That's the reason I brought the topic up in here so people can have a discussion over what the requirements are to make this work well with Fedora as a project and then push for inclusions of these requirements in Wayland.
Second I am a bit surprised by the "unless feature X is implemented 1:1 we shouldn't allow progess" sort of argument that is going on here. The main reason I'm excited about Wayland is the fact that it creates competition. I agree with Camilo that X doesn't seem to cope with the requirements of modern desktops well and I believe the reason for that is the fact that in the absence of a competitor it's very easy to settle for "good enough". Yes X is good enough for basic desktop especially after the great improvements that happened after the Xorg split but being good enough doesn't really jive well with Fedoras claim of being a showcase for technical innovation. I've lurked on the Xorg mailing list long enough to see the various attempts of improving X being stomped by the fact that compatibility with decade old protocols that no one really cares about on a modern desktop must be maintained.
The fact that X can be run as a client on Wayland makes for a pretty perfect situation in my eyes. Wayland can make design decision unhampered by the past while people who rely on specific X features can keep using these applications without change. If the advantages of Wayland weigh so heavily then X will at some point be obsoleted. I these advantages don't materialize then Wayland will disappear and we will return to X. But a third possible outcome - and one that in my opinion is pretty likely to occur - could be that a lot of the features of X (like remote applications) will actually be implemented in Wayland precisely because they have enough merit to survive and that looks like a great future to me: a modern implementation of all the features we love and care about.
As for the "if all apps are ported to Wayland I will not be able to use them remotely anymore" I think this is bogus. Nowadays virtually all application aren't X application but gtk/qt applications and the toolkits tend to support different backends. So you will be able to use your apps as long as the toolkits support X and I think that's going to be a long time unless Wayland is dramatically successfull.
Regards, Dennis
On Sat, Nov 06, 2010 at 05:28:08PM +0100, Dennis Jacobfeuerborn wrote:
First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there.
It's already been done, and the developers have been busily rejecting them out of hand, eg:
http://lists.freedesktop.org/archives/wayland-devel/2010-November/000028.htm... [1]
http://lists.freedesktop.org/archives/wayland-devel/2010-November/000031.htm...
https://groups.google.com/group/wayland-display-server/browse_thread/thread/...
Rich.
[1] As an aside, the point the original poster in that thread makes about client-side decorations is very valid. If you've used Windows or OS X at all, you'll have seen how a buggy application can monopolize the display so nothing can be moved or killed or switched.
On 11/06/2010 07:39 PM, Richard W.M. Jones wrote:
On Sat, Nov 06, 2010 at 05:28:08PM +0100, Dennis Jacobfeuerborn wrote:
First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there.
It's already been done, and the developers have been busily rejecting them out of hand, eg:
http://lists.freedesktop.org/archives/wayland-devel/2010-November/000028.htm... [1]
http://lists.freedesktop.org/archives/wayland-devel/2010-November/000031.htm...
https://groups.google.com/group/wayland-display-server/browse_thread/thread/...
Rich.
[1] As an aside, the point the original poster in that thread makes about client-side decorations is very valid. If you've used Windows or OS X at all, you'll have seen how a buggy application can monopolize the display so nothing can be moved or killed or switched.
So they consider this a layering violation which makes sense given that Wayland has a much smaller scope than X. That doesn't mean you cannot implement remote applications at all it just means you have to implemented in a different way.
Regards, Dennis
On 11/6/2010 11:28, Dennis Jacobfeuerborn wrote:
As for the "if all apps are ported to Wayland I will not be able to use them remotely anymore" I think this is bogus. Nowadays virtually all application aren't X application but gtk/qt applications and the toolkits tend to support different backends. So you will be able to use your apps as long as the toolkits support X and I think that's going to be a long time unless Wayland is dramatically successfull.
Does this sort of portability make any difference in a distribution where package maintainers make that decision at compilation time?
Camilo Mesias camilo@mesias.co.uk wrote:
[..] As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
I was doing that back in November[1].
--Ben
[1]http://blipper.dev.benboeckel.net/one-soap-box/2009/11/03/gnome-day-2-gnome-...
Hi,
On Sat, Nov 6, 2010 at 3:48 PM, Ben Boeckel mathstuf@gmail.com wrote:
Camilo Mesias camilo@mesias.co.uk wrote:
[..] As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
I was doing that back in November[1].
--Ben
[1]http://blipper.dev.benboeckel.net/one-soap-box/2009/11/03/gnome-day-2-gnome-...
You mention gnome shell but not nouveau, how do you enable the missing 3d support for Nouveau? And does it only work for a subset of hardware? I'd be interested to try it. Lately I just get:
Accelerated 3D graphics is not available Desktop effects require hardware 3D support.
I have switched between nvidia and nouveau in testing F14, I prefer gnome shell but using it can lead to fragility (eg. install nvidia, configure gnome shell, update; temporarily disabling nvidia -> broken desktop)
-Cam
Camilo Mesias camilo@mesias.co.uk wrote:
Hi,
On Sat, Nov 6, 2010 at 3:48 PM, Ben Boeckel mathstuf@gmail.com wrote:
Camilo Mesias camilo@mesias.co.uk wrote:
[..] As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
I was doing that back in November[1].
--Ben
[1]http://blipper.dev.benboeckel.net/one-soap-box/2009/11/03/gnome-day-2-gnome-...
You mention gnome shell but not nouveau,
Ah. true. Once nouveau came out, I pretty much dropped nvidia at that point since I'm not much of a "gamer" anymore (transparency in KWin was about the most taxing thing I used around that time).
how do you enable the missing 3d support for Nouveau?
It came with mesa-dri-drivers-experimental. I remember playing Neverball with full acceleration during the F13 Beta on nouveau (though Kobo Deluxe was not). My nvidia machine has since been shipped back home to be the main laptop there (the 256MB XP laptop wasn't cutting it anymore and I've been bad about updating the desktop which is still on F10 yet).
And does it only work for a subset of hardware?
It was a Quadro NVS 140M.
I'd be interested to try it. Lately I just get:
Accelerated 3D graphics is not available Desktop effects require hardware 3D support.
Don't know. Maybe Shell needs more things since then? The experimental driver package may also be missing.
I have switched between nvidia and nouveau in testing F14, I prefer gnome shell but using it can lead to fragility (eg. install nvidia, configure gnome shell, update; temporarily disabling nvidia -> broken desktop)
Switching between the two has always been an absolute nightmare. If I need to go nvidia -> nouveau, a reinstall was the easiest and most reliable way to nuke the blob driver.
--Ben
On Sat, 2010-11-06 at 16:00 +0000, Camilo Mesias wrote:
You mention gnome shell but not nouveau, how do you enable the missing 3d support for Nouveau? And does it only work for a subset of hardware? I'd be interested to try it. Lately I just get:
Accelerated 3D graphics is not available Desktop effects require hardware 3D support.
yum install mesa-dri-drivers-experimental
On Sat, 2010-11-06 at 16:00 +0000, Camilo Mesias wrote:
You mention gnome shell but not nouveau, how do you enable the missing 3d support for Nouveau?
There's an Mesa package labelled "experimental" you need to install.
I don't know what the subset of hardware it works for is, but my Quadro NVS 135M has been running smoothly so far: it's not fast, and the frame rate is not great, but it's out of the box and usable.
I blogged about this yesterday, but nouveau has taken serious strides in F14 - I've been using it the past couple of releases, and the progress has been stark.
Cheers
Alex.
-- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures).
-Cam
On Tue, 2010-11-09 at 21:05 +0000, Camilo Mesias wrote:
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures).
You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet).
On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote:
On Tue, 2010-11-09 at 21:05 +0000, Camilo Mesias wrote:
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures).
You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet).
Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor.
Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver?
On Wed, Nov 10, 2010 at 09:03:25AM -0500, Darryl L. Pierce wrote:
On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote:
On Tue, 2010-11-09 at 21:05 +0000, Camilo Mesias wrote:
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures).
You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet).
Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor.
Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver?
xrandr / system-config-display. I use nouveau with two monitors all the time.
--CJD
Casey Dahlin cdahlin@redhat.com wrote:
xrandr / system-config-display. I use nouveau with two monitors all the time.
I use xrandr myself (though usually intel or ATi drivers). I find it much less hassle to deal with versus any of the graphical tools that have been made. In addition, the options read very well.
xrandr --output LVDS0 --primary --output LVDS1 --right-of LVDS0
as an example.
--Ben
On Wed, 2010-11-10 at 09:03 -0500, Darryl L. Pierce wrote:
On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote:
On Tue, 2010-11-09 at 21:05 +0000, Camilo Mesias wrote:
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures).
You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet).
Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor.
Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver?
gnome-display-properties. nouveau fully supports RandR 1.2, which is a rather better interface than NVIDIA's.
On Sat, 2010-11-06 at 15:48 +0000, Ben Boeckel wrote:
Camilo Mesias camilo@mesias.co.uk wrote:
[..] As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it.
I was doing that back in November[1].
It depends on your hardware. Works on some cards, doesn't on others.
Le samedi 06 novembre 2010 à 10:57 +0000, Richard W.M. Jones a écrit :
Is Fedora for developers or what?
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window?
Well it would be mightily nice to have an infrastructure that can handle keyboard extended keys (almost every new keyboard sold in the last decade has one or more of those) without barfing because the original x11 protocol designers thought 8 bits would be enough for everyone.
The ground breaking parts can come afterwards. Input on X is so bad this is becoming ridiculous (another example being X has no notion of language, just layouts, so there's no way for apps to know the language being typed and auto-select the correct spellchecker)
On Sat, Nov 06, 2010 at 03:07:04PM +0100, Nicolas Mailhot wrote:
Le samedi 06 novembre 2010 à 10:57 +0000, Richard W.M. Jones a écrit :
Is Fedora for developers or what?
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window?
Well it would be mightily nice to have an infrastructure that can handle keyboard extended keys (almost every new keyboard sold in the last decade has one or more of those) without barfing because the original x11 protocol designers thought 8 bits would be enough for everyone.
The ground breaking parts can come afterwards. Input on X is so bad this is becoming ridiculous (another example being X has no notion of language, just layouts, so there's no way for apps to know the language being typed and auto-select the correct spellchecker)
Why throw away everything just so we can make input better?
(And in any case wasn't evdev supposed to fix this?)
Rich.
Le samedi 06 novembre 2010 à 14:21 +0000, Richard W.M. Jones a écrit :
Why throw away everything just so we can make input better?
Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others.
(And in any case wasn't evdev supposed to fix this?)
The kernel knows all the keys. They are broken at the X11 layer (because modern keys can not be represented via the original X11 protocol, and no one dares touching it)
If you want to know why wayland needs to happen, search the freedesktop bugzilla for "x12". It's a synonym for "we really need to do this, but it's not possible in x11, so > /dev/null"
On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote:
Le samedi 06 novembre 2010 à 14:21 +0000, Richard W.M. Jones a écrit :
Why throw away everything just so we can make input better?
Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others.
And yet despite all this, it's working fine. Really, I have no problem using my keyboard, managing photographs, scrolling through web pages, or anything else people have been talking about. The proposed solution [possibly] omits a vital feature which sets X apart from being just another windowing system, and for me at least it will be far less useful.
Rich.
On Sat, Nov 6, 2010 at 12:41 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote:
Le samedi 06 novembre 2010 à 14:21 +0000, Richard W.M. Jones a écrit :
Why throw away everything just so we can make input better?
Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others.
And yet despite all this, it's working fine. Really, I have no problem using my keyboard, managing photographs, scrolling through web pages, or anything else people have been talking about. The proposed solution [possibly] omits a vital feature which sets X apart from being just another windowing system, and for me at least it will be far less useful.
I find the fact that there is this much argumentation against something that:
1) isn't even proposed for Fedora at the moment 2) isn't even complete (or close to) in the distro it _is_ proposed for and 3) none of this discussion is taking place on any list relevant to the actual subject
a bit hilarious.
I think I'll just start new threads with subjects like "Arch Linux moving towards KDE as default" or "Gentoo moving towards razor package management" just to see how much time this community is capable of wasting. It should be lolz.
josh
Le samedi 06 novembre 2010 à 16:41 +0000, Richard W.M. Jones a écrit :
On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote:
Le samedi 06 novembre 2010 à 14:21 +0000, Richard W.M. Jones a écrit :
Why throw away everything just so we can make input better?
Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others.
And yet despite all this, it's working fine.
It is working fine for a "don't look there it is broken" definition of fine. You don't notice it because you've been formatted not to use the bits where it falls over.
On Sat, 2010-11-06 at 16:41 +0000, Richard W.M. Jones wrote:
Really, I have no problem using my keyboard,
Given your location and native language, I suspect your keyboard layout is en_US, in which case this isn't much of a surprise - it's one of the simplest cases (it requires one of the fewest numbers of characters of any layout) and it's also the one which gets most attention, development and testing.
If you spoke Chinese - or, even better, something Indic - you may have a different perspective. =)
On Mon, Nov 08, 2010 at 02:50:15PM -0800, Adam Williamson wrote:
On Sat, 2010-11-06 at 16:41 +0000, Richard W.M. Jones wrote:
Really, I have no problem using my keyboard,
Given your location and native language, I suspect your keyboard layout is en_US, in which case this isn't much of a surprise - it's one of the simplest cases (it requires one of the fewest numbers of characters of any layout) and it's also the one which gets most attention, development and testing.
If you spoke Chinese - or, even better, something Indic - you may have a different perspective. =)
Just to clear this up, I'm using a UK keyboard and switch between English and Japanese input (Anthy).
Rich.
On Tue, 2010-11-09 at 12:29 +0000, Richard W.M. Jones wrote:
On Mon, Nov 08, 2010 at 02:50:15PM -0800, Adam Williamson wrote:
On Sat, 2010-11-06 at 16:41 +0000, Richard W.M. Jones wrote:
Really, I have no problem using my keyboard,
Given your location and native language, I suspect your keyboard layout is en_US, in which case this isn't much of a surprise - it's one of the simplest cases (it requires one of the fewest numbers of characters of any layout) and it's also the one which gets most attention, development and testing.
If you spoke Chinese - or, even better, something Indic - you may have a different perspective. =)
Just to clear this up, I'm using a UK keyboard and switch between English and Japanese input (Anthy).
d'oh, right, too many Joneses around, I forgot you were the one who uses Japanese too. =)
well, I imagine you know more about this than me, but I run with Japanese input support at least occasionally, and my impression is that a lot of it is a fragile tower necessitated by the fact that the deep underlying stuff was coded with the assumption that all anyone ever wanted to type was ASCII. It feels to me like CJK input breaks a lot more than it really *should*, if you step back and look at it from first principles - it's just an input method, and we'd feel pretty dumb if we shipped a release where you can't type the letter Q, yet this sort of thing seems to happen all the time with non-en_US input. From a QA perspective, I know keyboard layout selection and complex character input is one of the things that breaks so often we had to stick an explicit validation test in for it. I don't know how much of this is related to X specifically, but I know it's certainly one of the things involved which makes the whole process of providing switchable input methods so icky.
On Tue, Nov 09, 2010 at 08:53:36AM -0800, Adam Williamson wrote:
well, I imagine you know more about this than me, but I run with Japanese input support at least occasionally, and my impression is that a lot of it is a fragile tower necessitated by the fact that the deep underlying stuff was coded with the assumption that all anyone ever wanted to type was ASCII. It feels to me like CJK input breaks a lot more than it really *should*, if you step back and look at it from first principles - it's just an input method, and we'd feel pretty dumb if we shipped a release where you can't type the letter Q, yet this sort of thing seems to happen all the time with non-en_US input. From a QA perspective, I know keyboard layout selection and complex character input is one of the things that breaks so often we had to stick an explicit validation test in for it. I don't know how much of this is related to X specifically, but I know it's certainly one of the things involved which makes the whole process of providing switchable input methods so icky.
I've yet to reliably compose a Japanese email through my non-Red Hat email address, but that's going over gnome-terminal -> ssh -> Debian -> mutt, and to be honest absolutely anything could be the problem there. I wouldn't blame X for that one ... It generally works for gtk2 apps. The actual implementation of the input mode switching is pretty horrible, but I sort of assume that's the usual open-source- developers-can't-do UI issue.
Rich.
Nicolas Mailhot wrote:
Well it would be mightily nice to have an infrastructure that can handle keyboard extended keys (almost every new keyboard sold in the last decade has one or more of those) without barfing because the original x11 protocol designers thought 8 bits would be enough for everyone.
This complaint is obsolete, XI2 supports 32-bit keycodes. http://www.x.org/wiki/XI2
Kevin Kofler
On Wed, Nov 17, 2010 at 10:08:10PM +0100, Kevin Kofler wrote:
Nicolas Mailhot wrote:
Well it would be mightily nice to have an infrastructure that can handle keyboard extended keys (almost every new keyboard sold in the last decade has one or more of those) without barfing because the original x11 protocol designers thought 8 bits would be enough for everyone.
This complaint is obsolete, XI2 supports 32-bit keycodes. http://www.x.org/wiki/XI2
...but xkb doesn't, so you can't actually do anything with them.
On Sat, Nov 06, 2010 at 10:57:27AM +0000, Richard W.M. Jones wrote:
We want to ditch extremely useful, ground-breaking features because of "tearing" when scrolling in a browser window? [I do *not* see any of
I actually read it as we want to ditch features that were groundbreaking in 1975 since the limits on technology from back then no longer mandate them and the advances in technology today are not as easily taken advantage of with those considerations.
Not saying you're wrong, just offering another viewpoint.
--CJD
On Sat, Nov 6, 2010 at 02:43, Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote:
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
Well when the X people say there is a limit to what X can do over a network reasonably and that a different approach is needed then maybe just maybe they know what they are talking about. Jeez. its not like people are taking X away tomorrow. Nor are they saying X is going away just that the monolithic nature it was designed around does not make sense anymore and changes need to be done.
But hey.. it is fun to be the guy who yells "They will take X away from me when they can pry it from my cold dead hand!" I wonder if "X doesn't kill people, I do." sounds as good.. nah..
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, 2010-11-06 at 08:43 +0000, Richard W.M. Jones wrote:
On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote:
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
Jon.
On 11/09/2010 10:05 AM, Jon Masters wrote:
On Sat, 2010-11-06 at 08:43 +0000, Richard W.M. Jones wrote:
On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote:
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said:
> Has anyone looked into bringing Wayland to Fedora? If not this might be the > right time getting involved in the discussion. > > http://wayland.freedesktop.org/
What's the implication for people who absolutely need to use X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
Looks more like a case of crying wolf to me. It's probably going to take a year before Wayland can be turned on as the default desktop and it's probably going to take several years before X can possibly go away so to use this kind of hyperbole is really just flamebait.
It's fine to bring your concerns up but please postpone this "we are all going to die" routine until we *actually* have something to complain about.
Regards, Dennis
On Tue, 2010-11-09 at 16:09 +0100, Dennis Jacobfeuerborn wrote:
On 11/09/2010 10:05 AM, Jon Masters wrote:
On Sat, 2010-11-06 at 08:43 +0000, Richard W.M. Jones wrote:
On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote:
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote:
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjones@redhat.com) said: >> Has anyone looked into bringing Wayland to Fedora? If not this might be the >> right time getting involved in the discussion. >> >> http://wayland.freedesktop.org/ > > What's the implication for people who absolutely need to use > X applications remotely?
Use VNC. (Or your similar protocol of choice.)
That's not a serious alternative.
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
Looks more like a case of crying wolf to me. It's probably going to take a year before Wayland can be turned on as the default desktop and it's probably going to take several years before X can possibly go away so to use this kind of hyperbole is really just flamebait.
It's fine to bring your concerns up but please postpone this "we are all going to die" routine until we *actually* have something to complain about.
At which point, it's too late. Unless Server-y people point out that things like network apps actually matter, the default path may be to do what will look nice on a local desktop (for the record, I can see full screen tearing-free graphics both using upstream Intel and upstream ATI drivers - one on a laptop, one dual headed desktop - just fine already).
Like Rich, I enjoy being able to start e.g. rawhide apps running on a virtual machine and have them render to my local X server, or start a second X and have an entire gnome-session running from a rawhide "box" sitting on my virt server. Also, although there are other ways to do it, my typical use of virt-manager these days is by forwarded X over ssh.
Jon.
On 11/9/10 7:23 AM, Jon Masters wrote:
At which point, it's too late. Unless Server-y people point out that things like network apps actually matter, the default path may be to do what will look nice on a local desktop (for the record, I can see full screen tearing-free graphics both using upstream Intel and upstream ATI drivers - one on a laptop, one dual headed desktop - just fine already).
Like Rich, I enjoy being able to start e.g. rawhide apps running on a virtual machine and have them render to my local X server, or start a second X and have an entire gnome-session running from a rawhide "box" sitting on my virt server. Also, although there are other ways to do it, my typical use of virt-manager these days is by forwarded X over ssh.
Perhaps you should take your concerns to a mailing list the Wayland developers actually read and participate on. Banging on about it here, when nobody in Fedora has actually suggested we make use of Wayland, seems like a big waste of everybody's time.
On 11/09/2010 03:57 PM, Jesse Keating wrote:
On 11/9/10 7:23 AM, Jon Masters wrote:
At which point, it's too late. Unless Server-y people point out that things like network apps actually matter, the default path may be to do what will look nice on a local desktop (for the record, I can see full screen tearing-free graphics both using upstream Intel and upstream ATI drivers - one on a laptop, one dual headed desktop - just fine already).
Like Rich, I enjoy being able to start e.g. rawhide apps running on a virtual machine and have them render to my local X server, or start a second X and have an entire gnome-session running from a rawhide "box" sitting on my virt server. Also, although there are other ways to do it, my typical use of virt-manager these days is by forwarded X over ssh.
Perhaps you should take your concerns to a mailing list the Wayland developers actually read and participate on. Banging on about it here, when nobody in Fedora has actually suggested we make use of Wayland, seems like a big waste of everybody's time.
I've seen the responses on the Wayland list, and it's always "Wayland isn't intended to do that." So, there's no point raising objections there.
The risk is that Wayland gets developed and a bunch of key applications in Fedora get broken. The Wayland guys are not the people to talk to, since network transparency isn't on their radar, from what I can see.
Andrew.
On 11/9/10 8:23 AM, Andrew Haley wrote:
I've seen the responses on the Wayland list, and it's always "Wayland isn't intended to do that." So, there's no point raising objections there.
The risk is that Wayland gets developed and a bunch of key applications in Fedora get broken. The Wayland guys are not the people to talk to, since network transparency isn't on their radar, from what I can see.
What makes you think that carping about it here will have any effect, particularly because NOBODY HAS PROPOSED WE USE WAYLAND yet.
On Tue, Nov 9, 2010 at 11:35 AM, Jesse Keating jkeating@redhat.com wrote:
On 11/9/10 8:23 AM, Andrew Haley wrote:
I've seen the responses on the Wayland list, and it's always "Wayland isn't intended to do that." So, there's no point raising objections there.
The risk is that Wayland gets developed and a bunch of key applications in Fedora get broken. The Wayland guys are not the people to talk to, since network transparency isn't on their radar, from what I can see.
What makes you think that carping about it here will have any effect, particularly because NOBODY HAS PROPOSED WE USE WAYLAND yet.
I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers "If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install".
If that is indeed the position of the Fedora community then it would carry a lot more weight in someone's planning than individual people whining on the wayland list.
On Tue, 2010-11-09 at 11:44 -0500, Gregory Maxwell wrote:
I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers "If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install".
Well, the Fedora graphics cabal is basically me, Kevin Martin, and Dave Airlie, and since we were hanging out at Plumbers last week and talked about this, here's the rough consensus I think we reached:
Wayland's not a usable default yet. It'll probably be packaged in F15 as something you can play with. We don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default. But it's likely to happen eventually because it's a serious win for a lot of things, and the downsides are pretty negligible despite the fear from the peanut gallery.
Feel free to quote me.
- ajax
On 11/09/2010 05:13 PM, Adam Jackson wrote:
On Tue, 2010-11-09 at 11:44 -0500, Gregory Maxwell wrote:
I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers "If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install".
Well, the Fedora graphics cabal is basically me, Kevin Martin, and Dave Airlie, and since we were hanging out at Plumbers last week and talked about this, here's the rough consensus I think we reached:
Wayland's not a usable default yet. It'll probably be packaged in F15 as something you can play with. We don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default. But it's likely to happen eventually because it's a serious win for a lot of things, and the downsides are pretty negligible despite the fear from the peanut gallery.
I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something.
Andrew.
On Tue, 2010-11-09 at 17:40 +0000, Andrew Haley wrote:
I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something.
The downsides that have been described include:
- We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.)
- We lose support for older hardware! Yep. Here's a nickel. We have sufficient kernel support for this for the big three hardware vendors, and we're probably going to see more ports to the marginal hardware in the next year or two. Losing <1% of the hardware support isn't keeping me up at night. (But, we can't switch yet, because there's not a good fallback design to classic X on that kind of hardware, and it includes things enterprisey people run on; so we're not switching yet.)
- All my X apps have to be ported! Yes, if they want to be native wayland clients, they do. If they don't, you can run a nested X server like on OSX. They'll still work as well as they ever did, and you even get to keep ssh forwarding of them. You can run a wayland server that does nothing but run a nested X server and you wouldn't ever know the difference. Except of course that your shell and your screensaver can be wayland apps, which means your screen locker will still work even if an app has a menu open, and you can actually do secure password input, and and and. (But, we really don't have _any_ good native wayland apps yet, thus the benefit of native apps are at the moment theoretical; so we're not switching yet.)
Anything I'm missing?
- ajax
On Tue, 2010-11-09 at 13:43 -0500, Adam Jackson wrote:
- All my X apps have to be ported! Yes, if they want to be native
wayland clients, they do.
Minor correction (I think?) - the apps don't really need to be ported, the toolkits do. Once GTK+ is ported to Wayland, fr'instance, all GTK+ apps are ported, right? It's not like we need to go in and poke all ten zillion apps we ship separately.
On Tue, 2010-11-09 at 10:54 -0800, Adam Williamson wrote:
On Tue, 2010-11-09 at 13:43 -0500, Adam Jackson wrote:
- All my X apps have to be ported! Yes, if they want to be native
wayland clients, they do.
Minor correction (I think?) - the apps don't really need to be ported, the toolkits do. Once GTK+ is ported to Wayland, fr'instance, all GTK+ apps are ported, right? It's not like we need to go in and poke all ten zillion apps we ship separately.
To the extent that those apps call (and link) only against the toolkit and not against an assumed backend, sure. The strict linking changes in F12 or F13 or whichever it was helped a lot with this, and gtk3 will help more, but to pick an arbitrary example:
% ldd `which gcalctool` | grep libX libX11.so.6 => /usr/lib/libX11.so.6 (0x05f1a000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x001c1000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d42000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x001c6000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x001cf000) libXi.so.6 => /usr/lib/libXi.so.6 (0x0094e000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x0095d000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x009c8000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x001d2000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x001d5000) libXau.so.6 => /usr/lib/libXau.so.6 (0x006f8000)
- ajax
Adam Jackson wrote:
% ldd `which gcalctool` | grep libX libX11.so.6 => /usr/lib/libX11.so.6 (0x05f1a000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x001c1000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d42000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x001c6000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x001cf000) libXi.so.6 => /usr/lib/libXi.so.6 (0x0094e000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x0095d000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x009c8000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x001d2000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x001d5000) libXau.so.6 => /usr/lib/libXau.so.6 (0x006f8000)
ldd appears to resolve dependencies recursively. I typically use readelf to see what a program links to.
$ readelf --dynamic `which gcalctool` | grep 'Shared library' 0x0000000000000001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libatk-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpangocairo-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED) Shared library: [libgconf-2.so.4] 0x0000000000000001 (NEEDED) Shared library: [libgio-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgthread-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libxml2.so.2] 0x0000000000000001 (NEEDED) Shared library: [libgmodule-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Björn Persson
On Tuesday, November 09, 2010 14:23:54 Björn Persson wrote:
Adam Jackson wrote:
% ldd `which gcalctool` | grep libX libX11.so.6 => /usr/lib/libX11.so.6 (0x05f1a000)
[snip]
ldd appears to resolve dependencies recursively. I typically use readelf to see what a program links to.
Then I guess the point is made by examining gvim.
On Tue, 2010-11-09 at 14:12 -0500, Adam Jackson wrote:
To the extent that those apps call (and link) only against the toolkit and not against an assumed backend, sure. The strict linking changes in F12 or F13 or whichever it was helped a lot with this, and gtk3 will help more, but to pick an arbitrary example:
% ldd `which gcalctool` | grep libX libX11.so.6 => /usr/lib/libX11.so.6 (0x05f1a000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x001c1000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d42000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x001c6000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x001cf000) libXi.so.6 => /usr/lib/libXi.so.6 (0x0094e000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x0095d000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x009c8000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x001d2000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x001d5000) libXau.so.6 => /usr/lib/libXau.so.6 (0x006f8000)
GTK+ backends are linked in at this time. One of the things that we will need to address before switching to wayland-with-X-fallback-for-remote-or-poor-hw becomes a realistic possibility.
Matthias Clasen wrote:
GTK+ backends are linked in at this time. One of the things that we will need to address before switching to wayland-with-X-fallback-for-remote-or-poor-hw becomes a realistic possibility.
Well, I don't think that will ever be feasible for Qt apps (which, like it or not, exist!): not only does Qt have to be recompiled for such a backend change, all apps using Qt have to as well! E.g. Qt/Embedded is not binary- compatible with Qt/X11 and I strongly doubt Qt/Wayland magically will be. And in addition, there are also preprocessor defines such as Q_WS_X11 being defined, which some apps rely on to use X11-specific functionality.
Kevin Kofler
On 11/09/2010 06:43 PM, Adam Jackson wrote:
On Tue, 2010-11-09 at 17:40 +0000, Andrew Haley wrote:
I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something.
The downsides that have been described include:
- We lose network transparency! Well, sure, the protocol doesn't have
that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.)
OK, so it's likely that everything will just continue to work remotely, and people won't experience any problems. And they won't have to run VNC just to get their favourite app to display remotely.
If this had been explained clearly to begin with, we could have avoided all this pain.
- All my X apps have to be ported! Yes, if they want to be native
wayland clients, they do. If they don't, you can run a nested X server like on OSX. They'll still work as well as they ever did, and you even get to keep ssh forwarding of them. You can run a wayland server that does nothing but run a nested X server and you wouldn't ever know the difference. Except of course that your shell and your screensaver can be wayland apps, which means your screen locker will still work even if an app has a menu open, and you can actually do secure password input, and and and. (But, we really don't have _any_ good native wayland apps yet, thus the benefit of native apps are at the moment theoretical; so we're not switching yet.)
Anything I'm missing?
It looked like a bunch of kiddies who had never used remote X applications had decided we didn't need to do that anymore, and it was more important to get kewl features like smooth scrolling and rotating 3D whatnots. It seems that isn't true, and we don't need to worry. The lunatics have not, in fact, taken over the asylum.
Andrew.
On Tue, Nov 9, 2010 at 7:09 PM, Andrew Haley aph@redhat.com wrote:
OK, so it's likely that everything will just continue to work remotely, and people won't experience any problems. And they won't have to run VNC just to get their favourite app to display remotely.
If this had been explained clearly to begin with, we could have avoided all this pain.
All participants need to take responsibility for being situationally aware to keep things from spiralling out of control.
The person starting this conversation is not involved in the work. Because of that there is no initial clarity or statement of purpose..no expert opinion to rely on at the outset. The people involved in the work are bravely walking into a discussion they didn't expect to be having at this point in time to pour water on reactions that have already grown somewhat overheated by the lack of clarity which was created through no fault of their own.
It looked like a bunch of kiddies who had never used remote X applications had decided we didn't need to do that anymore, and it was more important to get kewl features like smooth scrolling and rotating 3D whatnots. It seems that isn't true, and we don't need to worry. The lunatics have not, in fact, taken over the asylum.
If you thought that, if anyone thought that, they are bringing a huge amount of mental baggage into the discussion with them and are setting everyone up for a passionate overheated argument instead of a dispassionate informative discussion. A quick look over at freedesktop's git at the people who have had personal wayland branches in recent history would eradicate this particular characterization.
-jef
Once upon a time, Adam Jackson ajax@redhat.com said:
- We lose network transparency! Well, sure, the protocol doesn't have
that directly. You can still do vnc-like things trivially and with a
VNC-like remoting is a significant loss for server environments compared to X-like remoting.
With an X-based GUI management tool on a server, you fire up an SSH (or if you are old style you can even "xhost +foo", or manually copy magic cookies) and run just the app on the server, exporting the display of the app to your local system. All the "heavy-lifting" runs on your local system, not the server. When you close the app, there's nothing left running on the server.
If you have to use a VNC-like remoting, you have to run a desktop environment on the server (at least some minimal thing). You either have to have it running all the time, or start it up on demand. Then you can log in to start your app. When you shut down the app, you have to remember to shut down the desktop environment as well. This is much more overhead on the server for an occasional use GUI app.
None of my servers even have any desktop-environment type stuff install. In virtualized environments, making the servers run desktop stuff could greatly increase the overhead.
On Tue, 2010-11-09 at 13:34 -0600, Chris Adams wrote:
Once upon a time, Adam Jackson ajax@redhat.com said:
- We lose network transparency! Well, sure, the protocol doesn't have
that directly. You can still do vnc-like things trivially and with a
VNC-like remoting is a significant loss for server environments compared to X-like remoting.
See that other email where I say that "VNC-like" means "pixel scraping" and not "full-desktop".
- ajax
On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote:
- We lose network transparency! Well, sure, the protocol doesn't have
that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.)
Just so we don't lose the point: VNC-style remoting is *not* a suitable alternative.
Rich.
On Tue, Nov 09, 2010 at 09:03:38PM +0000, Richard W.M. Jones wrote:
On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote:
- We lose network transparency! Well, sure, the protocol doesn't have
that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.)
Just so we don't lose the point: VNC-style remoting is *not* a suitable alternative.
Ajax is using VNC-style remoting to refer to a pixel-scraping remoting mechanism which would not necessarily include a root window and would in most cases function the same way as X forwarding. Seems to be a repeated confusion in this branch of the thread.
--CJD
Rich.
On Tue, Nov 09, 2010 at 10:23:22AM -0500, Jon Masters wrote:
At which point, it's too late. Unless Server-y people
I object strongly to this perception that nobody involved in developing desktop technologies has any idea what server admins want. What we're seeing is the development of technologies that bear little resemblance to the Unix way of doing things, but which will in many cases make life better for server admins. systemd is a wonderful example, and Wayland has the potential to be used in such a way that it will work much better for what you want than X currently does.
To put it plainly: we know that people use X remoting. We're not going to change the default to something that makes that use-case impossible. Nobody who has any understanding of any of this is suggesting that we do so. It would be *stupid* to do so. But if you're asking for something that's identical to what we currently have (a reliance on a protocol that has an irritating number of round trips for something as simple as a keypress) then you're not going to get it, any more than us still providing support for a.out applications.
On Tue, 2010-11-09 at 17:25 +0000, Matthew Garrett wrote:
On Tue, Nov 09, 2010 at 10:23:22AM -0500, Jon Masters wrote:
At which point, it's too late. Unless Server-y people
I object strongly to this perception that nobody involved in developing desktop technologies has any idea what server admins want. What we're seeing is the development of technologies that bear little resemblance to the Unix way of doing things, but which will in many cases make life better for server admins. systemd is a wonderful example, and Wayland has the potential to be used in such a way that it will work much better for what you want than X currently does.
I can agree with that.
I'd like for something in return - could the folks working on desktop technologies acknowledge that those of us who are more server-oriented have an idea of what users want?
B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not.
I think that's in error, too.
-sv
On Tue, Nov 09, 2010 at 12:37:34PM -0500, seth vidal wrote:
B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not. I think that's in error, too.
In fact, us server-oriented folks are often blessed with working directly with actual users every day.
Matthew Miller (mattdm@mattdm.org) said:
B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not. I think that's in error, too.
In fact, us server-oriented folks are often blessed with working directly with actual users every day.
Right, but that just leads to informing people that what users desparately need is a beating.
Bill
On Tue, 2010-11-09 at 13:27 -0500, Bill Nottingham wrote:
Matthew Miller (mattdm@mattdm.org) said:
B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not. I think that's in error, too.
In fact, us server-oriented folks are often blessed with working directly with actual users every day.
Right, but that just leads to informing people that what users desparately need is a beating.
Or it leads to the development of an expertise or an intuition about the complaints and issues a user actually runs into or about how the systems are actually being used.
For example - talking to my former co-workers at a .edu I've determined that a LARGE number of users are no longer using local mail tools at all. They've transitioned exclusively to using gmail for all their accounts.
The younger users in particular are expecting access to their information from all their devices independently - which gmail provides.
-sv
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
AIUI the Grand Plan is for everyone to write apps in GTK+ and Qt (which is more or less the case already), and for GTK+ and Qt to be compatible with *both* Wayland and X. Again AIUI, there's no impediment to this in the design of Wayland and it's actually what Wayland's designers expect to happen, in order to make sure things still work on platforms where Wayland isn't available, and to deal with exactly this kind of case.
So I think the future vision is that if you're running on your system you get a shiny Wayland-y version, and if you run something via ssh -x you get a slightly less pretty X version. And all the Hard Stuff happens in the background and you don't really have to care about it. If I'm wrong, someone correct me, but I think I'm right and people are getting a rather misleading vision of a glorious future where everything only runs on Wayland, which I don't think is the idea at all.
(presumably if you're one of the few apps which don't use a toolkit, you should yourself make sure you support both Wayland and X. Or make sure no-one wants to run your apps over a network, or there's another way to do it.)
On 11/09/2010 04:49 PM, Adam Williamson wrote:
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
AIUI the Grand Plan is for everyone to write apps in GTK+ and Qt (which is more or less the case already), and for GTK+ and Qt to be compatible with *both* Wayland and X. Again AIUI, there's no impediment to this in the design of Wayland and it's actually what Wayland's designers expect to happen, in order to make sure things still work on platforms where Wayland isn't available, and to deal with exactly this kind of case.
So I think the future vision is that if you're running on your system you get a shiny Wayland-y version, and if you run something via ssh -x you get a slightly less pretty X version. And all the Hard Stuff happens in the background and you don't really have to care about it.
Well, that would be an excellent result.
All it takes is someone who is a member of the cabal (TINC) to confirm this, and everyone will be happy.
Andrew.
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing.
You are, in short, scared.
It's well established by now that the problems of "window system", "rendering system", "input system", and "application remoting" are in fact pretty dang separate, and that the more you conflate them the worse your solution ends up being. You can thank X for being ~24 years of research into just how badly you can conflate them and get away with it, but it's just about reached the limits of what it can do. I'm sad to see it go too, but I've been working to knock X out of hegemony for the last six years, and I'm quite sure that the sooner that happens the better for all concerned.
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
- ajax
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jackson ajax@redhat.com wrote:
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing.
I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based.
So,
You are, in short, scared.
... I think this is a rather unfair characterization.
Perhaps the concerns that people have are misplaced—— perhaps a switch to somehow wayland doesn't imply a loss of reasonably functioning network transparency. If so, then clarifying it beyond your "gtk/qt" will offer both X and wayland would be helpful. Especially since providing both TUI and GUI administrative tools hasn't really panned out in practice.
In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect.
[snip]
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue.
On 11/09/2010 06:12 PM, Gregory Maxwell wrote:
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jacksonajax@redhat.com wrote:
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing.
I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based.
You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends.
You are, in short, scared.
... I think this is a rather unfair characterization.
Given the fact that people are heading for their nuclear vaults for reasons that only exist in their fantasies I'd say that's an accurate description.
Perhaps the concerns that people have are misplaced—— perhaps a switch to somehow wayland doesn't imply a loss of reasonably functioning network transparency. If so, then clarifying it beyond your "gtk/qt" will offer both X and wayland would be helpful. Especially since providing both TUI and GUI administrative tools hasn't really panned out in practice.
In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect.
Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet.
raising concerns != screaming the sky is falling
[snip]
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue.
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this.
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
What's puzzling is why people are willing to form hardened opinions on things they apparently don't understand. It's baffling.
Regards, Dennis
On Tue, Nov 9, 2010 at 6:12 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet.
raising concerns != screaming the sky is falling
Actually, if we go back to the first post in the thread... it was the premature suggestion by a by stander of bringing a "still far from being finished technology" into Fedora because another entity has prematurely decided to announce to the world that its going to be their default. That triggered a certain amount of bloodletting. If the original poster had come to the conclusion that it was "far from being finished" before writing the first post do you think that the original poster would have written that post in exactly the say way? Something the original poster should probably ruminate on.
Generally speaking, if you aren't prepared to talk in detail about the suitability of a technology, you shouldn't bring it up for discussion like that. If you are personally interested in it, you should inquire as to whether there are people in our development community who are currently working on it and ask them questions about it. To come out of the gate suggesting its time to discuss it for inclusion is putting the card before the horse.
What the original post is, is a classic enthusiast blunder. The active developers working on the problem space are more than capable of proposing wayland for inclusion and answer questions about wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech.
-jef
On Tue, Nov 9, 2010 at 6:33 PM, Jeff Spaleta jspaleta@gmail.com wrote:
wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech.
I have been watching this growing thread with some bewilderment - is it possible for someone who knows by direct experience how Wayland has been moving, but who is also a Fedora developer, to give a more detailed description of where the project has been heading in terms of both what it *may* be able to provide in functionality beyond the discussion in this thread, as well as how it is envisaged it may yet satisfy the needs of the critics concerning the loss of essential functionality - I guess that if the project is still being defined then it is important to understand its potential for the future, and not just what has been planned at this point in time?
Jeff makes a good point here - it sounds like this is still nascent at a level where *we* don't really know the extent of its capabilities, but has the potential to be developed in directions that have not yet been clarified in the developer's minds - and a considered discussion between the experts could say what its limitations might be? However there must be many unknowns and until the development gets to the stage where some code can be tested as part of a rawhide level system then it is perfectly possible that the developers could make the system work in a way that the critics are currently implying cannot happen - or am I being naive?
On 11/09/2010 07:33 PM, Jeff Spaleta wrote:
On Tue, Nov 9, 2010 at 6:12 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet.
raising concerns != screaming the sky is falling
Actually, if we go back to the first post in the thread... it was the premature suggestion by a by stander of bringing a "still far from being finished technology" into Fedora because another entity has prematurely decided to announce to the world that its going to be their default. That triggered a certain amount of bloodletting. If the original poster had come to the conclusion that it was "far from being finished" before writing the first post do you think that the original poster would have written that post in exactly the say way? Something the original poster should probably ruminate on.
Generally speaking, if you aren't prepared to talk in detail about the suitability of a technology, you shouldn't bring it up for discussion like that. If you are personally interested in it, you should inquire as to whether there are people in our development community who are currently working on it and ask them questions about it. To come out of the gate suggesting its time to discuss it for inclusion is putting the card before the horse.
What the original post is, is a classic enthusiast blunder. The active developers working on the problem space are more than capable of proposing wayland for inclusion and answer questions about wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech.
No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine.
As for the "the developers will come forward when it's done" you apparently seem to know know about the behind the scenes connections between Wayland and Fedora than others. I was aware of the initial anouncement of Wayland when the project was started at long time ago and wouldn't have dreamed of bringing it up precisely because it would have been premature. However now Ubuntu is apparently going to introduce its influence so I thought it to be fair to make Fedora aware of the project.
Regards, Dennis
On Tue, Nov 9, 2010 at 9:09 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine.
Am I holding you responsible for others? No. I'm saying very specifically that you started a topic about inclusion instead of simply inquiring as to whether people in our community are already involved. The inquiry would have been perfectly appropriate. A suggestion we talk about inclusion when we don't have a clearly defined technical expert to make the case for it is not. We have a featuring process for some very good reasons. One of those reasons is to allow the person make the propose to provide adequate amount of information as a starting point for a constructive discussion about technical pros and cons.
That's like me suggesting we have a discussion about moving over to the hurd kernel as a default when I know absolutely nothing about kernel implementation details and watching concerns over the issue spiral out of control.
I am saying very specifically that noone should propose a discussion for technology inclusion on this list unless they feel comfortable addressing questions of a technical nature about the technology or failing that they bring someone along at the start of the conversation who is able to be the technical expert when the quite expected questions about technical issues come up. The discussion spirals when questions go unanswered by a technical expert and the void in the discussion is instead filled up with meatheads like myself.
As for the "the developers will come forward when it's done" you apparently seem to know know about the behind the scenes connections between Wayland and Fedora than others. I was aware of the initial anouncement of Wayland when the project was started at long time ago and wouldn't have dreamed of bringing it up precisely because it would have been premature. However now Ubuntu is apparently going to introduce its influence so I thought it to be fair to make Fedora aware of the project.
You yourself have stated as part of this discussion that its still as a long way to go as a technology. Appearently you came to that conclusion later in the discussion. It appears that Shuttleworth's sincere enthusiasm for what is achievable with Wayland has mislead you into thinking the project is futher along than it is. Just to save yourself some heartbreak down the road, assuming a technology that Shuttleworth is personally excited about is not what I would call due diligence in gaining enough of an understanding of the subject matter to competently lead a discussion on the topic.
-jef
On 11/09/2010 10:33 PM, Jeff Spaleta wrote:
On Tue, Nov 9, 2010 at 9:09 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine.
Am I holding you responsible for others? No. I'm saying very specifically that you started a topic about inclusion instead of simply inquiring as to whether people in our community are already involved. The inquiry would have been perfectly appropriate. A suggestion we talk about inclusion when we don't have a clearly defined technical expert to make the case for it is not. We have a featuring process for some very good reasons. One of those reasons is to allow the person make the propose to provide adequate amount of information as a starting point for a constructive discussion about technical pros and cons.
That's like me suggesting we have a discussion about moving over to the hurd kernel as a default when I know absolutely nothing about kernel implementation details and watching concerns over the issue spiral out of control.
I am saying very specifically that noone should propose a discussion for technology inclusion on this list unless they feel comfortable addressing questions of a technical nature about the technology or failing that they bring someone along at the start of the conversation who is able to be the technical expert when the quite expected questions about technical issues come up. The discussion spirals when questions go unanswered by a technical expert and the void in the discussion is instead filled up with meatheads like myself.
Point taken.
Regards, Dennis
On Tue, 2010-11-09 at 19:12 +0100, Dennis Jacobfeuerborn wrote:
On 11/09/2010 06:12 PM, Gregory Maxwell wrote:
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jacksonajax@redhat.com wrote:
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing.
I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based.
You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends.
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Answering that you can still use X on top of Wayland doesn't do anything: it is the native Wayland clients that are the issue. If they are not network transparent then it cannot be a suitable replacement for X because native clients _will_ appear and we end up with the situation of OSX and Windows where some clients are more equal than others.
[snip]
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue.
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
Are the native wayland clients network transparent? If they are not, then it isn't a suitable replacement for X for my usage (or my 2 dozen users) and it means that either the native wayland clients or X clients will be second class citizens as time goes on.
That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this.
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
Which should be considered now. VNC screen scraping sucks. If the native clients cannot be networked from the beginning, then they will never be able to be networked in a suitable fashon. Its not something you can bolt on later "if [it] is really successful"
I like the concept of the project and I like the energy, but the bottom line is: if you want to make a replacement for X it needs to offer at least the same feature set. That includes network transparency.
Brian
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out.
--CJD
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out.
--CJD
That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY).
Brian
On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out.
--CJD
That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY).
When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor.
Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both.
--CJD
On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out.
--CJD
That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY).
When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor.
Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both.
I assume there would be a fallback method for older ssh clients?
In any case, combined with the stuff that ajax has said in the last couple of emails it sounds like it could be a workable solution.
Brian
--CJD
On Tue, Nov 09, 2010 at 02:28:10PM -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote:
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote:
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way.
Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out.
--CJD
That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY).
When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor.
Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both.
I assume there would be a fallback method for older ssh clients?
It would involve a bit more effort on the user's part (most of which could be rolled into a script) but you could set up the final scenario using present-day ssh assuming you had the wayland bits on both ends.
--CJD
On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
On 11/09/2010 06:12 PM, Gregory Maxwell wrote:
I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based.
You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends.
Nice way to assume. Its pretty likely that you use software I wrote every day.
So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated.
What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications.
If is so clear-cut for wayland then why can't a clear message be provided?
Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement.
Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent.
I'm perfectly capable of understanding a statement like "Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you."
[snip]
In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect.
Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet.
raising concerns != screaming the sky is falling
Well _I_ certainly didn't intend to call for a rejection of wayland— it seems to be far too immature to even talk about rejecting it at this point. But I think Fedora ought to make clear that network transparency is requirement. It seems that at least a few people in this thread don't believe that it is, and I think that ought to be cleared up sooner rather than later because I'd hate to hear that a lot of effort was put in building a system that won't really meet the needs.
If the need for network transparency is already well understood then I don't think there is much more to discuss.
[snip]
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
This is exactly the sort of non-comforting communication that I was complaining about above.
The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions.
You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality.
That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this.
Keep your windowing system out of my network transparency!!!! ;)
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
I think it's needed on the first day that wayland desktop applications are widely deployed— someone shouldn't have to choose between the "wayland ui" and network transparency.
I suppose there is plenty of room to disagree with this but I would point out that other operating systems have not had a lot of luck with after-the-fact network transparency.
Remote X is actually pretty terrible from a protocol perspective. It's very chatty. But at least on a reasonable network (and by reasonable I should note that doesn't just mean a local network) it's quite usable. It would be sad not to make an _improvement_ on this, but I really can't see how something could even match it without having it as a design consideration at the start.
I don't mean this as an insult or a lack of faith against the people working on the system— the same pattern of treating network transparency as an afterthought has not worked where anywhere as far as I can tell.
What's puzzling is why people are willing to form hardened opinions on things they apparently don't understand. It's baffling.
The only hardened opinion I have is that network transparency is an essential opinion. Beyond that I have no clue. I'm waiting to be educated. If only Adam Jackson were responding I would have walked away satisfied by now. Perhaps I should ignore everyone else. :)
On 11/09/2010 08:04 PM, Gregory Maxwell wrote:
On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
On 11/09/2010 06:12 PM, Gregory Maxwell wrote:
I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based.
You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends.
Nice way to assume. Its pretty likely that you use software I wrote every day.
So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated.
What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications.
If is so clear-cut for wayland then why can't a clear message be provided?
Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement.
Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent.
I'm perfectly capable of understanding a statement like "Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you."
From what you wrote it sounded like you were specifically insisting that the network transparency bits were supposed to go into Wayland proper and that would make some sense if said but someone who has never developed software and doesn't understand the layering of subsystems.
It was an honest mistake and not an attempt to get cute. My apologies.
What I was trying to get at is that even if the Wayland developers completely ignore network transparency that has no bearing on an independent implementation of that feature (see Casey Dahlins example elsewhere in this thread).
[snip]
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
This is exactly the sort of non-comforting communication that I was complaining about above.
The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions.
You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality.
The reason for the confusion is that two cases are conflated here: Wayland + X and Wayland without X.
As long as X is present as a client on top of Wayland all apps will just continue to work as usual. That is the initial state of affairs and "native" network transparency for Wayland is not going to be that important.
Once Wayland is established and successfull people will eventually want to get rid of X altogether. At this we'll need an X-less way of doing network transparency. This point lies 2-3 Years in the future though so it's not necessary to get worked up about the details just yet.
That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this.
Keep your windowing system out of my network transparency!!!! ;)
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
I think it's needed on the first day that wayland desktop applications are widely deployed— someone shouldn't have to choose between the "wayland ui" and network transparency.
I suppose there is plenty of room to disagree with this but I would point out that other operating systems have not had a lot of luck with after-the-fact network transparency.
For me it's not a case of disagreeing since I also would like to see a remote apps feature but the first release of Wayland in a mainstream capacity lies probably a year in the future so there is plenty of time to talk this through yet some in the thread have already decided to paint the future pitch black and that's a bit surprising to me.
Remote X is actually pretty terrible from a protocol perspective. It's very chatty. But at least on a reasonable network (and by reasonable I should note that doesn't just mean a local network) it's quite usable. It would be sad not to make an _improvement_ on this, but I really can't see how something could even match it without having it as a design consideration at the start.
What I think makes this case a little different is the fact that the introduction of a compositor makes the drawing of an app window and the drawing of the desktop two distinct operation.
Traditionally all windows were rendered directly on the desktop so either you'd have to redirect that (which is basically what X does) or you'd have to redirect the entire desktop (which is the VNC way). In the "new world" the app draws into it's window and the compositor is invoked to put the desktop together. This gives you the ability redirect the drawing of the window to a remote desktop where the compositor will then render it onto the desktop.
What I specifically like about this is that it allows for a better separation of concerns and allows both the core display code and the "remoting" code to progress idependently. New methods for the network part don't have to worry about specifics of the display part and vice versa.
X seems to be a giant wool ball where all parts are so interdependent that it is difficult to advance one part without breaking another. That is why I think that not wedging the networking bit directly into Wayland is a good thing.
I don't mean this as an insult or a lack of faith against the people working on the system— the same pattern of treating network transparency as an afterthought has not worked where anywhere as far as I can tell.
What's puzzling is why people are willing to form hardened opinions on things they apparently don't understand. It's baffling.
The only hardened opinion I have is that network transparency is an essential opinion. Beyond that I have no clue. I'm waiting to be educated. If only Adam Jackson were responding I would have walked away satisfied by now. Perhaps I should ignore everyone else. :)
Well he seems to be quite happy that Wayland is coming which gives me even more confidence that the future is more positive than some make it out to be. :)
Regards, Dennis
On 11/09/2010 01:12 PM, Dennis Jacobfeuerborn wrote:
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
...
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
The argument seems to be that toolkit libs like Qt and GTK+ will shield us from major rewriting of apps. However, this implies that toolkits at some point will switch from the X mode to Wayland mode, with the resulting sudden loss of network transparency.
I suppose one could imagine toolkits offering a dual backend: native Wayland, and X that would be invoked by e..g. a commandline switch if remoting was required. This seems a little heavyweight and awkward in both deployment and maintenance.
You seem to imply that there's an alternative design involving some sort of shim between Wayland and the kernel that could capture and remote the GUI inputs and outputs. Can you point to any discussion of how it'd work?
Finally I found it ironic that Wayland was designed to decrease the number of layers and roundtrips in X, but at least initially in the important use case of user app->toolkit->X API->Wayland it actually increases the number of layers. All the same, it's probably the only workable approach, so my observation above is more of a cheap shot than a serious anti-Wayland argument, but still it is a little funny, reminding me of the observation that oftentimes when people try to heal a religious schism, they end up creating a third sect :)
Of course if it turned out that remoting can be provided by a Wayland-Kernel shim, this would not be an issue.
What's puzzling is why people are willing to form hardened opinions on things they apparently don't understand. It's baffling.
Unfortunately this seems to be the popular attitude: c.f. attitudes in politics and other things like economy, climate science etc etc.
On Wednesday 10 November 2010 09:21:24 Przemek Klosowski wrote:
On 11/09/2010 01:12 PM, Dennis Jacobfeuerborn wrote:
X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years.
...
Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop.
The argument seems to be that toolkit libs like Qt and GTK+ will shield us from major rewriting of apps. However, this implies that toolkits at some point will switch from the X mode to Wayland mode, with the resulting sudden loss of network transparency.
This is precisely the situation we have when Qt/GTK+ programs are compiled for Windows: the programs work, they look right, but network transparency is lost. Of course, Windows was never really designed to support network transparency, so nobody is surprised by that.
I suppose one could imagine toolkits offering a dual backend: native Wayland, and X that would be invoked by e..g. a commandline switch if remoting was required. This seems a little heavyweight and awkward in both deployment and maintenance.
I do not think that a command line switch would even be necessary; the toolkit could just look for DISPLAY, and if that variable is set, it would automatically use X11. Of course, this means that we have to trust the toolkit developers to pay attention to both X11 and Wayland and provide equal levels of support for both, which is not something I really think would happen, at least not in the long run.
-- Ben
Gregory Maxwell (gmaxwell@gmail.com) said:
So,
You are, in short, scared.
... I think this is a rather unfair characterization.
I don't know about that. Something new is discussed, and not everyone understands it, and they have concerns about how it may handle some particular cases.
Now, people can go about the discussion in multiple ways.
People can ask questions... get more info... try and understand the architecture... work on ways to fit into it, or move it, or discover better ways to accomplish that usage case.
Or people can start posting how WE agree that THOSE people are coming into OUR space and I see how they're moving towards THEIR way doing things that are against OUR way of life, and how this is going to be a DISASTER and THOSE people must be STOPPED because THEY can't be reasoned with. (Paid for by the committee to elect blah blah fishcakes send your donations now so we can stop THOSE people and their AGENDA today.)
And that's argumentation that's based on fear and instilling fear, and the more that an argument tends down those lines, the more I'd expect a response with condescension.
Bill
On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote:
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors.
And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work.
- ajax
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote:
On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote:
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors.
Also, those two things are not at all incompatible (though ajax, please do correct me if I was wrong in what I wrote, or if I'm wrong in this). It's perfectly possible (and I think likely) both for Wayland to be implemented in such a way that you can use X remoting more or less transparently, *and* for there to be some kind of native remoting protocol for Wayland.
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote:
On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote:
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency?
I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors.
And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work.
So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always "kept in sync".
The truth is, I think this could be an interesting project, and I think most people are raising their concerns now to make sure that should it become a successful project we're not stuck with either VNC or local-only.
Brian
- ajax
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2010-11-09 at 14:01 -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote:
And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work.
So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always "kept in sync".
Sorry, I assumed a bit much domain knowledge here.
When I say "vnc-like" I mean "let's scrape the pixels out of the rendering buffer and shove them over the wire". VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick.
When I say "rdp-like" I mean "instill enough awareness of the possibility of remoting in the rendering system that remoting can send a rendering command stream instead of raw pixels if that seems to be a win". Wordy, I admit. And, obviously, much more work than just vnc-like scraping. But it's a serious win for WAN links, and is the only viable way to remote 3D, etc.
And, of course, you can have both at once. rdp-like remoting probably requires toolkit awareness (in this bizarro world, the nested X server counts as a toolkit!), so if you end up remoting an app that lacks that level of toolkit support, you can fall back to vnc-like.
- ajax
On Tue, 2010-11-09 at 14:19 -0500, Adam Jackson wrote:
On Tue, 2010-11-09 at 14:01 -0500, Brian Wheeler wrote:
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote:
And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work.
So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always "kept in sync".
Sorry, I assumed a bit much domain knowledge here.
No worries
When I say "vnc-like" I mean "let's scrape the pixels out of the rendering buffer and shove them over the wire". VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick.
I was hoping that window-level scraping was possible but I wasn't sure how to phrase it.
When I say "rdp-like" I mean "instill enough awareness of the possibility of remoting in the rendering system that remoting can send a rendering command stream instead of raw pixels if that seems to be a win". Wordy, I admit. And, obviously, much more work than just vnc-like scraping. But it's a serious win for WAN links, and is the only viable way to remote 3D, etc.
Wordy, true, but I think its the kind of detail necessary to calm a lot of the fears that people have.
And, of course, you can have both at once. rdp-like remoting probably requires toolkit awareness (in this bizarro world, the nested X server counts as a toolkit!), so if you end up remoting an app that lacks that level of toolkit support, you can fall back to vnc-like.
Sounds reasonable enough
Brian
Le mardi 09 novembre 2010 à 14:19 -0500, Adam Jackson a écrit :
When I say "vnc-like" I mean "let's scrape the pixels out of the rendering buffer and shove them over the wire". VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick.
I hope no one is assuming there the pixels remote-side have the same properties as the pixels local-side (size, form factor, alignment, color-correction, etc) and we'll not get yet another display tech that only works as long as there is a single screen model everyone uses.
On Tue, Nov 9, 2010 at 4:55 PM, Adam Jackson ajax@redhat.com wrote:
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
I think what's missing is a concrete demonstration to point to of remoting of a Wayland native client window to wrap our heads around how different (easy or hard) it is. When the time comes to introduce initial wayland packages into Fedora having the ability to demonstrate a native toy Wayland client rendered remotely (and securely from say a virtualized host) is probably something to shoot for.
-jef
On Tue, 2010-11-09 at 17:55 +0000, Jeff Spaleta wrote:
On Tue, Nov 9, 2010 at 4:55 PM, Adam Jackson ajax@redhat.com wrote:
Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for "screen for X" almost for free.
I think what's missing is a concrete demonstration to point to of remoting of a Wayland native client window to wrap our heads around how different (easy or hard) it is. When the time comes to introduce initial wayland packages into Fedora having the ability to demonstrate a native toy Wayland client rendered remotely (and securely from say a virtualized host) is probably something to shoot for.
The UX will probably be somewhere between ssh -Y, vncserver(1), and:
https://bugzilla.redhat.com/show_bug.cgi?id=651591
- ajax
On Tue, Nov 09, 2010 at 04:17:25PM -0500, Adam Jackson wrote:
The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591
Hopefully with a better security model than 'ssh -Y'?
If this has Xpra-like functionality (i.e. "screen for X") standard, and it works and is managed well, suddenly there's a pretty compelling advantage.
On Tue, 2010-11-09 at 16:26 -0500, Matthew Miller wrote:
On Tue, Nov 09, 2010 at 04:17:25PM -0500, Adam Jackson wrote:
The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591
Hopefully with a better security model than 'ssh -Y'?
What kind of attack are you trying to prevent, and how do you envision that interacting with the window system?
- ajax
On Tue, Nov 09, 2010 at 04:35:33PM -0500, Adam Jackson wrote:
The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591
Hopefully with a better security model than 'ssh -Y'?
What kind of attack are you trying to prevent, and how do you envision that interacting with the window system?
The classic is a hostile remote binary which secretly maps a full-screen transparent window and captures everything you do in your other windows.
On Tue, 2010-11-09 at 16:59 -0500, Matthew Miller wrote:
On Tue, Nov 09, 2010 at 04:35:33PM -0500, Adam Jackson wrote:
What kind of attack are you trying to prevent, and how do you envision that interacting with the window system?
The classic is a hostile remote binary which secretly maps a full-screen transparent window and captures everything you do in your other windows.
It's a little tough to do that in wayland, period. In general apps don't get to know (or control) their screen position or the stacking order. That's the compositor's decision. Likewise (I think) for input event delivery, although I'm not as familiar with that bit.
Still: that'd be a definition detail for whatever the remoting protocol ends up being. Things like RDP simply do not let you remote invisible input capture surfaces, it's just not there.
It's hard though, because wayland surfaces can have an alpha channel, and the only way to look at a surface and know it's transparent is to inspect every fourth byte... bit expensive that. But you might like to be able to remote windows the size of the screen for the x-terminal kind of use case, but still want to be able to cut/paste between remote and local apps... so you need some IPC, but you probably don't want full input thunking. Not intractable, just subtle.
- ajax
On Tue, 09.11.10 04:05, Jon Masters (jonathan@jonmasters.org) wrote:
From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core.
And what happens when all the apps are native Wayland apps and none of those can be run remotely?
If I wanted to step back to the pre-net era, I'd run Windows.
+1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility.
I think you aren't even aware how broken this "mix and match" network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly.
Yes, X11 over the network still kinda works, but if you claim the status quo was so awesome, then you're just blind.
Lennart
Lennart Poettering píše v Út 09. 11. 2010 v 23:07 +0100:
I think you aren't even aware how broken this "mix and match" network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly.
Well, isn't that mostly the fault of D-Bus, GConf and other relatively recent inventions that they decided to ignore this use case of running desktop applications? In the far past, IPC mechanisms somehow managed to cooperate with X (e.g. ICCCM, XSettings) - admittedly with lower-level functionality.
(The decision to ignore remote applications may have been correct - that's beside the point: You really can't blame X for things D-Bus/GConf didn't do; and the fundamental semantic problem of "should this setting refer to the machine this process runs or to the machine it is displayed" does not ever go away simply by changing the remote communication protocol.) Mirek
On Tue, 09.11.10 23:14, Miloslav Trmač (mitr@volny.cz) wrote:
Lennart Poettering píše v Út 09. 11. 2010 v 23:07 +0100:
I think you aren't even aware how broken this "mix and match" network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly.
Well, isn't that mostly the fault of D-Bus, GConf and other relatively recent inventions that they decided to ignore this use case of running desktop applications? In the far past, IPC mechanisms somehow managed to cooperate with X (e.g. ICCCM, XSettings) - admittedly with lower-level functionality.
(The decision to ignore remote applications may have been correct - that's beside the point: You really can't blame X for things D-Bus/GConf didn't do; and the fundamental semantic problem of "should this setting refer to the machine this process runs or to the machine it is displayed" does not ever go away simply by changing the remote communication protocol.)
Oh, of course you can blame X for that. There's simply no sane way how to get a "parallel" connection for D-Bus/GConf/ICE/PA/whatever to the main X11 display connection. Something like that has been tried a number of times, but in some way or the other it just failed in the end. It's a can of worms. Really, for example in the GConf case I know that Havoc spent quite some time to design the IPC so that it could be used alongside X11 on the network, but eventually gave up on it.
I think it is fundamentally wrong to ask us to support setups where you might or might not share $HOME, might or might not share the D-Bus session bus, might or might not share the D-Bus system bus, might or might not share PA, might or might not share GConf, might or might not share X11 displays, in all combinations over the network at all times.
Complete flexibility like that is not only impossible to manage or test, but also inherently slow. For example: if you say the D-Bus bus should be shared across the network, but $HOME shouldn't, then applications could not refer to files anymore in the bus protocols, which would basically require them to pipe everything through a bus, which is a textbook example how to make things slow. Of course, it's easy to assume that all the building blocks we build our desktop off would be completely independent black boxes, but turns they aren't, and are deeply integrated these days.
The pixel-scraping approach is the only thing that in the end makes sense, since you have a very clear idea of what you share, and what you don't share, and what you share is only at the very very end of what you do, i.e. the last step of presentation of the app to the user.
Lennart
That's true, using freenx to access a whole desktop works well with xfce and no sound. I can't imagine it working so well if trying to run gnome-shell, sound etc remotely.
I get the impression a lot of the current desktop infrastructure doesn't make sense when accessed remotely, eg if I ssh'ed into a machine what could I usefully do with nm-applet or a lot of other desktop infrastructure? A lot of the desktop is already beyond the reach of X.
On 9 Nov 2010 22:26, "Lennart Poettering" mzerqung@0pointer.de wrote:
On Tue, 09.11.10 23:14, Miloslav Trmač (mitr@volny.cz) wrote:
Lennart Poettering píše v Út 09. 11...
Oh, of course you can blame X for that. There's simply no sane way how to get a "parallel" connection for D-Bus/GConf/ICE/PA/whatever to the main X11 display connection. Something like that has been tried a number of times, but in some way or the other it just failed in the end. It's a can of worms. Really, for example in the GConf case I know that Havoc spent quite some time to design the IPC so that it could be used alongside X11 on the network, but eventually gave up on it.
I think it is fundamentally wrong to ask us to support setups where you might or might not share $HOME, might or might not share the D-Bus session bus, might or might not share the D-Bus system bus, might or might not share PA, might or might not share GConf, might or might not share X11 displays, in all combinations over the network at all times.
Complete flexibility like that is not only impossible to manage or test, but also inherently slow. For example: if you say the D-Bus bus should be shared across the network, but $HOME shouldn't, then applications could not refer to files anymore in the bus protocols, which would basically require them to pipe everything through a bus, which is a textbook example how to make things slow. Of course, it's easy to assume that all the building blocks we build our desktop off would be completely independent black boxes, but turns they aren't, and are deeply integrated these days.
The pixel-scraping approach is the only thing that in the end makes sense, since you have a very clear idea of what you share, and what you don't share, and what you share is only at the very very end of what you do, i.e. the last step of presentation of the app to the user.
Lennart
On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
Until recently, wayland required private branches of quite a few dependencies. But it should be possible to build wayland against F15 packages now, or at least it should be soon. If somebody wants to give this a try, I'd be happy to review packages.
Wayland certainly still has a way to go before we can think about replacing X altogether, but many pieces of this puzzle have been falling into place, and with the increased interest (and hopefully contribution), we may see it happen sooner rather than later.
Watch out for that 'gnome-shell on wayland' post... :-)
On Fri, Nov 05, 2010 at 11:12:09AM -0400, Matthias Clasen wrote:
On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
Until recently, wayland required private branches of quite a few dependencies. But it should be possible to build wayland against F15 packages now, or at least it should be soon. If somebody wants to give this a try, I'd be happy to review packages.
Last time I tried the big problem was Cairo-drm wasn't enabled in our cairo packages. Granted that was a while ago. Also I don't know the status of drivers other than Intel getting the page-flip ioctl in the kernel, which is the other major prerequisite.
Wayland certainly still has a way to go before we can think about replacing X altogether, but many pieces of this puzzle have been falling into place, and with the increased interest (and hopefully contribution), we may see it happen sooner rather than later.
The code definitely needed some more eyes last time I poked it. Its completely undocumented in most places, duplicates macro declarations across multiple files, and essentially implements its own version of point-to-point dbus (the politics there aren't quite so simple, as there may be an argument for Wayland doing its own IPC, even if it does seem rather too elaborate).
I'd love to see things move this way though.
--CJD
On Thu, Nov 4, 2010 at 19:11, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
There is an interesting article on LWN currently that outlines not Ubuntu's reasons but core X hacker Keith Packards on the changes:
http://lwn.net/Articles/413335/
for those with LWN subscriptions.
Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 2010-11-05 at 15:41 -0600, Stephen John Smoogen wrote:
On Thu, Nov 4, 2010 at 19:11, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Interesting move: http://www.markshuttleworth.com/archives/551
Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion.
There is an interesting article on LWN currently that outlines not Ubuntu's reasons but core X hacker Keith Packards on the changes:
http://lwn.net/Articles/413335/
for those with LWN subscriptions.
thanks for the pointer, that was interesting indeed. (reminder to RHers: we have a site subscription to LWN, details on the intranet.)
-
Adam Jackson -
Adam Williamson -
Alex Hudson -
Andrew Haley -
Ben Boeckel -
Benjamin Kreuter -
Bill Nottingham -
Björn Persson -
Brian Wheeler -
Camilo Mesias -
Casey Dahlin -
Chris Adams -
Daniel P. Berrange -
Darryl L. Pierce -
Dennis Jacobfeuerborn -
Garrett Holmstrom -
Garry Williams -
Gregory Maxwell -
Haïkel Guémar -
Jaroslav Reznik -
Jef Spaleta -
Jesse Keating -
Jon Masters -
Josh Boyer -
Kevin Kofler -
Lennart Poettering -
Mark Bidewell -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
mike cloaked -
Miloslav Trmač -
Nicolas Mailhot -
Przemek Klosowski -
Rahul Sundaram -
Richard W.M. Jones -
Seth Vidal -
Stephen John Smoogen -
Thomas Bendler