If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir
nor Wayland have any built in toolkit. All renderings are done to buffers and buffers
alone. And because of that no software like xclock or xcalc will be written for any
of the as that simply isn't possible. Toolkit is what will be used and if a toolkit
supports both your app bill support both.

And I don't know what running a DE in XMir have to do whit any of this. If you
think it's pointless then god don't do it, nobody cares.

awesome comment from a dude that never touched a compiler, in the real world even using toolkit X.y version can sigsegv between different Xorg minor releases[lets say 1.14.0 and 1.14.1] and very very often you need a lot of swtiching logic to deal with graphic drivers and opengl implementations

No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir nor Wayland have any built in toolkit. All renderings are done to buffers and buffers alone. And because of that no software like xclock or xcalc will be written for any of the as that simply isn't possible. Toolkit is what will be used and if a toolkit supports both your app bill support both.

First, point out where did I say any of those have built in toolkits. I only said toolkits (as in Qt, GTK, etc) help alleviate the fragmentation. Also, I didn't say it was severe fragmentation, but that it was *more* severe than the general case. This is due to having to write, when not using a toolkit, or using some specific things of the underlying infrastructure, a backend for each, if you want to support everyone.
Also, rendering doesn't require a toolkit, since you can do it yourself in several ways.

And I don't know what running a DE in XMir have to do whit any of this. If you think it's pointless then god don't do it, nobody cares.

It has things to do with this, specifically with you talking about how people who cares about the technology doesn't care about this discussions. The fact is, I will not use it, but I know of several people who will because they lack the technical knowledge to disable it, and those users, friends of mine, will see mostly negative effects out of it, when the only reason to run it is to make some noise.

Originally Posted by mdias

What about the maintainers of QT, GTK and so on? They need to double the effort to support and maintain both Mir and Wayland.
Bugs found and fixed on Mir aren't going to be bugs found and fixed on Wayland and vice-versa, therefore fragmenting efforts.

Also, this. This is why it's more severe than in most cases. In most cases, which exclude toolkits and display servers, the fragmentation introduces affects only the project who introduces it (i.e., having people maintaining MATE only means this people ain't be working on something else). In the case of having several toolkits and display servers, there are other things depending on them, which will pay the consequences.

This is just an ugly situation for everyone. What happens when ubuntu users, which make up the majority of steam users, don't submit their bugs to intel anymore. And intel will ignore the patches sent from Ubuntu..... so will steam bugs in the intel gpu driver just sit unknown and unfixed? This is a shitty situation for everyone, especially the users.

This will all very soon be resolved, intel will revert its position as soon as the real management hears whats going on. Intel's business is not on selling OSes, much less display servers or whatherver. Intel's business is selling chips, and it is stupid to not accept patches to your driver that allows the support of more users, thus selling more chips.

This is just an ugly situation for everyone. What happens when ubuntu users, which make up the majority of steam users, don't submit their bugs to intel anymore. And intel will ignore the patches sent from Ubuntu..... so will steam bugs in the intel gpu driver just sit unknown and unfixed? This is a shitty situation for everyone, especially the users.

Please, point out how support for XMir on the DDX driver affects Steam at all.

This will all very soon be resolved, intel will revert its position as soon as the real management hears whats going on. Intel's business is not on selling OSes, much less display servers or whatherver. Intel's business is selling chips, and it is stupid to not accept patches to your driver that allows the support of more users, thus selling more chips.

well this problem is way more complex, hardware bussiness people don't count ubuntu users they count OEM sales and even if you have ubuntu or mint or gentoo or arch that computer you bought already included the money for intel and was registered as a microsoft sale not ubuntu with exception of hand picked OEM like system76 or Dell linux laptops or custom builds that compared to HP/Gateway/other big OEM are extremely low, as far as intel care you payed the hardware already and payed microsoft too. On the other hand Xeon/opteron/firegl/quattro chips are registered as RedHat sales by the OEM and have huge margin gains[unlike that cheap corei7/FX/radeon/geforce], this is intel/amd/nvidia real interest in linux desktop[tizen/jolla/IVI/etc influence this too but for mobile] and they basically have open drivers[except nvidia] to please this RedHat customers, ofc make it open and maintained for other distros like ubuntu or fedora allow you to reduce cost and ROI + free technical able testers/contributors.

In the case of valve is the same, they don't care about ubuntu/gentoo/arch/fedora users per se, they care about BigPicture and SteamBox and for that they need to learn the platform and get free testers to reduce the initial investment and make bussiness decisions, get Valve games on linux is just a nice side effect. Seeing this and the need of Valve for AAA+ hardware support they will simply follow intel/amd/nvidia decisions for the custom valve distro software implementation.

the real management make that decision based on bussiness since suporting mir cost them money but loose every ubuntu users out there cost them 0$ since they already sold the chip to you and since the number of ubuntu are so low compared to windows or mac that they don't even care and since they market position is so big that you want it or not you will buy intel again at some point in time.

the only reason they listen to RedHat is that RedHat move lots of sales through OEM with big fat gross gains in the enterprise market

But putting that fact aside for the moment, is it pretty much certain now that there will be no -- zero, zip, nada -- Mir support in Intel drivers? Because it's going to be hard to jive the idea of not accepting an XMir patch on the basis of Intel "not condoning the actions of Canonical [by creating Mir]", and then separately providing support for Mir.

But putting that fact aside for the moment, is it pretty much certain now that there will be no -- zero, zip, nada -- Mir support in Intel drivers? Because it's going to be hard to jive the idea of not accepting an XMir patch on the basis of Intel "not condoning the actions of Canonical [by creating Mir]", and then separately providing support for Mir.

is backwards, is certain that intel won't touch Mir, so canonical will have to maintain their own mesa branch to make Mir support intel drivers, aka the burden of support the hardware is back to canonical which is the one with the genius idea of make Mir in the first place, not intel in the upstream driver that have noting to do with canonical decisions.

so like is working today ubuntu will provide a mesa packages will all the neccesary patches to support open drivers in Mir and regular mesa will have wayland support by default thats is all this decision means