Hi everyone,
On 26/09/18 01:05, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi everybody! > > > Sure thing. I even wrote to you on IRC on #debian-devel but you might have > missed it. > > I want to stress a point here: in my reply below I might sound too negative, > but I have been struggling with this subject for at very least a couple of > years now. The big issue behind this is lack of proper data and industry > definitions in terms of what is the real trend behind all this. I really appreciate your hard work on this topic Lisandro and I'm very thankful for you agreeing to revisit this issue. I think there would be a huge benefit implementing this change. > That being said every data that can help us make a better decision will be > highly appreciated. I have compiled some data for us to work with: https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls I'm currently working through this list to gauge the level of qt related activities with these boards (column g). So far I can't see much activity at all but I'm still going through the forums of the more popular platforms. Could we start discussions with the ones documented? > I would disagree with that, specially with the use of QML, but the arm64 > server scenario is definitely not a fully deployed one yet so there is lot of > room for changes. > > But I would *love* to have one more data point: how many of those boards > require the proprietary video card vendor's headers to be present at Qt build > time? Yes, some of them need to be present at qtbase's build time in order to > fully work (or even work at all). > > Take a look at [experimental's] qtbase build. Look for "QPA backends" → > "EGLFS > details". As you can see there is EGL support, but some vendors require > specific proprietary code to be present at build time. Even if it where not > proprietary they are self-excluding, ie, you can only pick one at a time. > > [experimental's] > <https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=amd64&ver=5.11.2%2Bdfsg-2&stamp=1537603343&raw=0> > > So the question is: if we do the switch, how many boards we will really > support? And actually, did the switch to EGL really served the other arm* > archs? That really depends on the number of bards that do not require > proprietary stuff around at build time. Good point. Let's take a conservative approach and assume all. That would still leave us with all arm64 boards being able to run KDE or LXQT. People wanting to write their own window applications outside the actual windowing system would still need to build qt for their own needs as they had to in the past. I haven't seen much evidence of people doing that. The few exceptions I have found are building their own qtbase with EGLF support for their platform. Gauging the interest for a lightweight desktop environment on https://www.armbian.com/ and having experienced LXQT on the gemini, I am positive that this is going to be very well received and the combination of choice in the future. > Side note: I have just created #909579 to see if we can add Vulkan support > without breaking anything else. > >>> More objectively, Ubuntu did that switch two years ago and there have >>> been no issues reported in launchpad as a result of it. > This is not actually true. There's what I wrote above *and* the fact that > this > breaks API/ABI. How so? Well, EGL is not compatible with GLU/GLUT, on which > many Qt-based applications rely upon, see [glut]. > > [glut] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408#67> > > Note that at the moment I was convinced to switch arm64 and we did know of > few > packages that had issues. That changed. Also a good point, and a scary one, too. I have done a scan of the activities in some of the board's forums and couldn't find any indication that anyone is, or has been, developing or running GLU applications on arm64. I might be looking in the wrong corners of the Internet but it looks currently very quiet in the arm64 space when it comes to qt. I would need a few more days to check out the forums and IRC channels of the popular boards to see what they are up to but we might have an opportunity to get this over the line before people start putting some serious effort into this space. I understand that there is a considerable likelihood of something going wrong, you have plenty of experience from the Ubuntu switch, but the impact might be lower than last time. I'm going out on a limb here, but: - assuming that the uptake of qt on arm64 is currently very low - GLU has been broken on armhf a few years ago already so people have probably been driven away from it - ?? Doesn't FreeGLUT offer support for GLES ?? I have to dig into that a bit more the impact on users may even be negligible compared to the benefit of having a proper desktop environment on all arm64 boards and, if the Gemini is a success, future arm64 handhelds. Experiencing LXQT on those boards is leaps ahead of what is currently available and is something to be proud of. Thanks heaps for your help with this, I much appreciate it. Many thanks, Re4son
