22 Oct 2017

feedPlanet GNOME

Adrien Plazas: retro-gtk: The Future, Marty!

Let's come back to retro-gtk. In the previous articles I explained how bad retro-gtk was, what I did to start improving it and more importantly what I did to prepare the terrain for further development. This article will detail the aforementioned planed improvements!

Unless stated otherwise, I don't plan these changes to be part of retro-gtk 0.14 and I have no idea when they will be implemented. If I say anything you know to be wrong or if you know something which could help the library's development, please share it in the comments!

Stabilization of the API

As stated in the previous article, I want retro-gtk's API to stop breaking as much as it did in the past. Starting with 0.14, we will avoid API and ABI breaks as much as possible, and if we do any we will document them properly. The API should be stable but given that some big changes are coming I don't feel comfortable promising proper stability just yet.

Gitlab

I requested to move retro-gtk to GNOME's GitLab. This would allow retro-gtk to stop parasiting gnome-games' Bugzilla and live its own life. This is particularly important as retro-gtk is expected to become more stable and hence more used. I hope it will be done before 0.14 get released.

Meson! 😃

I started porting retro-gtk's build system to Meson, nothing is on master yet and I am studying Meson as I do the port. I hope it will be done before 0.14 get released.

Y U NO Rust‽

The library has two major constraints: it has to use the low-level Libretro C API and it has to expose an introspected GObject C API. As far as I know Rust supports both these constraints, but I don't know Rust yet and the Vala code needed to be ported to some low-level language so I could develop the library more freely and make it move forward.

Rust support of GObject - even though it is very promising - is still in development, so porting retro-gtk to it while I had to learn the language would have delayed the needed low-level language port. I may port parts of the library to Rust later, once I took the time to learn it and once the GObject integration matured. I expect a C to Rust transition to be less painful while maintaining the ABI than the Vala to C was.

Hardware Rendering and Shaders

Currently retro-gtk renders the video output of the core by converting it with custom code and drawing it with Cairo. It was quick and easy to implement with the knowledge I had back then and it did the job so I let it that way so far, even though it's very clearly far from optimal. retro-gtk should instead use hardware acceleration to render the video.

The only problem is that I still know nothing about graphics APIs such as OpenGL. 🙂 I hope the learning curve won't be too steep, if you have any knowledge to share, please do! I'll rely on Emanuele's GtkGLArea presentation and Anton's OpenGL 4 Tutorials to start working.

This would allow retro-gtk to render the cores' video with shaders, such as CRT shaders, Game Boy shaders and more!

I plan to work on this during SUSE Hack Week 16, so it may land in 0.14! 🙂

Hardware Rendering for the Cores

Libretro defines RETRO_ENVIRONMENT_SET_HW_RENDER and struct retro_hw_render_callback to allow the cores to request a hardware rendering interface to the frontend. Some Libretro cores can't work without it, so retro-gtk should implement it.

This would allow retro-gtk (and by extension Games) to run Nintendo 64 emulators and many more Libretro cores it can't yet!

I also plan to work on it during SUSE Hack Week 16.

Gamepad Handling

retro-gtk handles some controllers internally via RetroCoreView, but it doesn't handle gamepads directly and rely on the application to implement gamepad objects. I am currently exporting the gamepad handling code of Games into its own library, it may be a good opportunity to let retro-gtk handle all its controllers - gamepad included - internally, avoiding to expose too much of its internals. I am not sure whether it is a good idea or not yet.

Run the Core in a Subproccess

This is by far the biggest change planned for retro-gtk, I have absolutely no idea when it will be implemented: I would like retro-gtk to run Libretro cores into their own subprocesses. I would like this to not change the API - or as little as possible - which is made easier by the new higher level API as it reduces the surface the IPC must cover, moving more of the code in the subprocess. Here are the effects I expect such a change to have.

Calling Back Core Support Improvements

As each core would be alone in its subprocess we can be sure of which core is calling back, so there is no need to track its identity, making retro-gtk able to handle Libretro cores calling back from a different thread. As a result the API is expected to be more asynchronous.

Avoid Static Memory Collisions

When a module is loaded twice in a process it is actually loaded just once, making the two instances sharing the same static memory space. Most Libretro cores where once standalone games or applications, hence they were free to use static variables and sometimes did so. Some of this is still present in some Libretro cores, making them buggy when two instances try to access the same static memory. retro-gtk avoid these clashes in a very dirty way: the module is copied to a temporary file which is loaded instead, tricking the loading mechanism in actually loading is twice… I hope that loading each module from a different process will solve that, but I really have no idea if it will: if you know anything about this please contact me.

Improved Stability

We could make retro-gtk resilient to crashes of the subprocess, whether it is caused by the Libretro core or the lower layers of retro-gtk, the applications could handle this as they want for example by kindly notifying the users. I hope it won't make debugging the cores harder and that meaningful backtraces and other useful debugging information will remain obtainable.

Improved Security?

libseccomp could be used in the subprocess to avoid the cores to run unauthorized syscalls, which could be used to mitigate exploits and other 0days. The problem is that we can't know which syscalls the Libretro cores need so it may be tricky to filter enough but not too much. It still needs some reflection.

Regarding Performances

On one hand, performances could get improved as the UI and the Libretro core would run on two different CPU cores at the same time. On the other hand, high performance IPCs are tricky to get right, especially as I have next to no experience in that field. Copies and locks should be avoided as much as possible but I don't expect to avoid them all. This strategy turned out well for web browsers so I can only hope it will here too. 🙂

Unit Testing, Code Coverage ans Non-Regression Tests

Because we should do all of that, period. Special Libretro cores may have to be crafted for testing, but we should use already existing ones as much as possible to avoid accidentally writing ones not following precisely Libretro's semantic and working only in retro-gtk.

Core Integration Tests and Non-Regression Tests

It would be really useful for retro-gtk to distribute a Libretro core integration testing tool. Games would no doubt benefit from it as we already encountered regressions in Libretro cores we ship with its Flatpak version, which is particularly bad when it causes your user's saves to be lost.

Conclusion

This article concludes the mini-series about retro-gtk. I hope this library to become the best way to build a GTK+ based Libretro frontend, and if all of these features get implemented I am sure it will be! 😊

22 Oct 2017 7:04pm GMT

21 Oct 2017

feedPlanet GNOME

Chandni Verma: [Problem3 SPOJ:ROBOTGRI] A problem for lovers of mazes!

PROBLEM: http://www.spoj.com/problems/ROBOTGRI/

This was a tough nut!

Its a graph problem. Its actually a combination of 2 problems in one! I have voted it as hard and given it my recommendation.

I went through the following resources (none has the actual solution but all serve as hints) to finally come up with a solution for it:

https://www.cs.bu.edu/teaching/alg/maze/
https://www.hackerearth.com/practice/notes/dynamic-programming-problems-involving-grids/
http://www.geeksforgeeks.org/count-possible-paths-top-left-bottom-right-nxm-matrix/
http://www.geeksforgeeks.org/count-number-ways-reach-destination-maze/
https://www.youtube.com/watch?v=PwxGTHraMNg&feature=youtu.be
http://www.geeksforgeeks.org/applications-of-breadth-first-traversal/



SOLUTION: https://github.com/glassrose/CPP_Problem_Solving/blob/master/SPOJ-ROBOTGRI.cpp
Tested and Accepted: http://www.spoj.com/status/ROBOTGRI,chandniverma/

Time complexity in the worst case: O(n^2 + E)
where n = number of rows (or columns) in the grid
and E = number of edges in the connected graph containing the starting cell 'S'.

Space complexity: O(n^2)

21 Oct 2017 12:28pm GMT

Sebastian Dröge: Rendering HTML5 video in Servo with GStreamer

At the Web Engines Hackfest in A Coruña at the beginning of October 2017, I was working on adding some proof-of-concept code to Servo to render HTML5 videos with GStreamer. For the impatient, the results can be seen in this video here

And the code can be found here and here.

Details

Servo is Mozilla's experimental browser engine written in Rust, optimized for high-performance, parallelized rendering. Some of the parts of Servo are being merged in Firefox as part of the Project Quantum, and already provide a lot of performance and stability improvements there.

During the hackfest I actually spent most of the time trying to wrap my head around the huge Servo codebase. It seems very well-structured and designed, exactly what you would expect from starting such a project from scratch by a company that has decades of experience writing browser engines already. After also having worked on WebKit in the past, I would say that you can see the difference of a legacy codebase from the end of the 90s and something written in a modern language with modern software engineering practices.

To the actual implementation of HTML5 video rendering via GStreamer, I actually started on top of the initial implementation that Philippe Normand started before already. That one was rendering the video in a separate window though, and did not work with the latest version of Servo anymore. I cleaned it up and made it work again (probably the best task you can do to learn a new codebase), and then added support for actually rendering the video inside the web view.

This required quite a few additions on the Servo side, some of which are probably more hacks than anything else, but from the GStreamer-side is was extremely simple. In Servo currently all the infrastructure for media rendering is still missing, while GStreamer has more than a decade of polishing for making integration into other software as easy as possible.

All the GStreamer code was written with the GStreamer Rust bindings, containing not a single line of unsafe code.

As you can see from the above video, the results work quite well already. Media controls or anything more fancy are not working though. Also rendering is currently done completely in software, and a RGBA frame is then uploaded via OpenGL to the GPU for rendering. However, hardware codecs can already be used just fine, and basically every media format out there is supported.

Future

While this all might sound great, unfortunately Mozilla's plans for media support in Servo are different. They're planning to use the C++ Firefox/Gecko media backend instead of GStreamer. Best to ask them for reasons, I would probably not repeat them correctly.

Nonetheless, I'll try to keep the changes updated with latest Servo and once they add more things for media support themselves add the corresponding GStreamer implementations in my branch. It still provides value for both showing that GStreamer is very well capable of handling web use cases (which it already showed in WebKit), as well as being a possibly better choice for people trying to use Servo on embedded systems or with hardware codecs in general. But as I'll have to work based on what they do, I'm not going to add anything fundamentally new myself at this point as I would have to rewrite it around whatever they decide for the implementation of it anyway.

Also once that part is there, having GStreamer directly render to an OpenGL texture would be added, which would allow direct rendering with hardware codecs to the screen without having the CPU worry about all the raw video data.

But for now, it's waiting until they catch up with the Firefox/Gecko media backend.

21 Oct 2017 11:38am GMT

19 Oct 2017

feedPlanet KDE

Hey Mycroft, Drive Me to our Goals!

Intro

Almost three months after Akademy 2017, I finally found the time to write a blog post about how I experienced it.

Akademy is where I learn again about all the amazing things happening in our community, where I connect the dots and see the big picture of where all the effort in the various projects together can lead. And of course, I meet all the wonderful people, all the individual reasons why being in KDE is so amazing. This year was no different.

Some people voiced their concern during the event that those who are not at Akademy and see only pictures of it on social media might get the feeling that it is mostly about hanging out on the beach and drinking beer, instead of actually being productive. Everyone who was ever at Akademy of course knows this impression couldn't be further from the truth, but I'll still take it as a reason to not talk about any of the things that were "just" fun, and focus instead on those that were both fun and productive.

Tales from the KDE e.V. Board of Directors

One thing that happens at every Akademy is the Annual General Assembly (AGM) of the KDE e.V.

This association, usually just called "the e.V." by the community, is KDE's legal and financial representation. Among other things, it raises funds and uses them to make in-person meetings within KDE happen, such as developer sprints or conferences, and sponsor attendees who cannot afford travel and accommodation for those themselves. It also takes care of legal issues such as maintaining KDE's trademarks, and this year it also uses some of its funds for two marketing contractors, Ivana and Paul, to help push our promo efforts. Since last Akademy I am on the board of directors of the KDE e.V., so the AGM is especially important to me.

One important aspect of this year's AGM was that three out of the five positions in the board of directors were up for re-election. Two of the board members whose terms ended, our president Lydia Pintscher and vice president Aleix Pol, ran for another term and were re-elected, whereas Marta Rybczynska was not able to run for another term as treasurer, and is now followed by Eike Hein. Eike used to be one of the "KDE phantoms": He's been a very active KDE contributor for many years (most notably the maintainer of Konversation, Yakuake and several key parts of Plasma such as the Task Manager), but the majority of his fellow KDE members have not seen him in person until this year.

New Board 2017.jpg

The new board (from the left): Eike, yours truly, Aleix, Lydia and Sandro

Fortunately I had the opportunity to talk to Eike more than anybody else at this Akademy because we had been assigned as roommates. He had lots of interesting stories to tell, from the way IRC facilitates building communities, to communication culture in Korea (where he now lives), to the experience of moderating multiple Subreddits, and much much more. I'm really looking forward to working with Eike on the board!

My highlights from two days of talks

The following are explicitly my personal highlights. If you're a non-programmer like me, who is also especially interested in design and/or in KDE software running on anything that isn't a traditional desktop or laptop PC, chances are you might find those talks as interesting as I did. If you know more about programming than I do, you'd also enjoy a lot of the other presentations, where I could just sit and be amazed by how people like you can understand all of that technical stuff.

So, here goes:

Aleix Pol's talk about A laptop by KDE summarized our experience with the KDE Slimbook, the very first KDE-branded hardware on the market, and gave a few ideas on what we might do next in that area. This was especially important to me because I was deeply involved in promoting the KDE Slimbook initiative. The talk was followed up by a BoF session during the week where we did an in-depth retrospective on how the Slimbook project went so far and what we learned from it.

A talk which was especially relevant for me as a user researcher was the one on (K)UserFeedback, where Volker Krause introduced the new framework that allows applications to - after opt-in and fully anonymized, of course - collect usage data and send them to KDE to use it for improving our software. Given that privacy is at the core of our Vision and Mission, of course we are extremely cautious in that area, but some usage data is needed for us to make software that fits the needs of our users, not just our own. Volker's talk was accompanied by a BoF on Tuesday where we discussed what our policy on collection, storage and use of that data should look like in order gain useful information without compromising our users' privacy.

A talk which was interesting for me from a strategic, design and user perspective was the one about Mycroft AI Plasmoid & Plasma Desktop Integration, in which Aditya Mehra presented some of the amazing things the Mycroft AI can already do in Plasma, as well as his plans for the future. Digital Assistants are one area where the Linux desktops clearly lag behind all big proprietary operating systems. Many Free Software proponents reject digital assistants outright due to a perceived inherent privacy problem, but Mycroft (apart from currently using a Google service for speech recognition, but there are plans to replace that) shows that privacy-protecting and fully user-controlled digital assistants are possible. That is why from my perspective, this is a hugely important strategic area for KDE. This talk was also accompanied by a BoF on Tuesday, about where else in Plasma we can use Mycroft's capabilities. If you are as excited as I am about the role KDE could play in Free Software solutions for AI and home automation, consider participating in the discussion on my community goal proposal on that subject.

Aditya giving his talk about Mycroft

In his talk Opening new doors: KDE in embedded, Agustin Benito Bethencourt presented some of the ways in which KDE could play an important role in the world of embedded systems, for example in the automobile industry. He has been involved in two different projects in that area and told us that the industry is waking up to the benefits of open source, and that from his perspective, now would be a great time for KDE to make ourselves known in that space. This talk, too, was accompanied by a BoF session, where we discussed next steps for getting our software to run on automotive systems. This is also an area where I believe it's important that KDE champions Fee Software, because, like with virtual assistants: What have we won if our PCs and phones run Free Software, but our cars are not in our full control and might even spy on us? If you are interested in this project, head over to the Automotive project on Phabricator and join the discussion and work there!

In his talk Looking for Love, our marketing contractor Paul Brown taught us the importance of focusing our communication strategy on the users' needs, by presenting, in clear and easy to understand words, what benefit our products bring to them, instead of trying to describe their purpose as precisely as possible from our own perspective. That he took the Kirigami wiki page, which I had contributed significantly to, as a negative example of a description which uses way too much jargon and focuses on technical details instead of user benefits, of course meant that I had to endure seeing one of my "babies" being ripped apart in front of my eyes, but it was definitely worth it! The talk was meant as an appetizer for a workshop on Monday, were Paul helped everyone who wanted to improve their product website.

In his talk Input Methods in Plasma 5, Eike Hein made it clear that the state of input methods (which are needed primarily for text input in e.g. many Asian writing systems, but can also handle things such as emoji input or auto-completion or -correction) in Plasma and KDE applications is currently lagging behind other popular operating systems and desktop environments. He presented what needs to be done to improve the situation, and is now rallying people behind a proposal for a community goal to make it happen together. So here as well: If you also feel that improving input methods in KDE software is important, join the conversation on the proposal!

Camilo Higuita, author of the Babe music player, gave a talk Introducing Babe and a contextual approach to multimedia desktop apps where he demonstrated how Babe uses various techniques and online services to find connections between songs in order to give smart answers to search queries. His talk was also accompanied by a BoF session during the week, where we discussed some design ideas and how to use Kirigami to make Babe a convergent desktop and mobile application.

Yours truly also gave a presentation, together with Dan Leinir Turthra Jensen, titled Folding Your Applications, where we talked about the design behind the Kirigami Ui framework and how application developers inside and outside of KDE are already using it to easily create mobile and convergent user interfaces.

Putting Ideas to Action: The Workshop and BoF Days

Monday through Thursday were dedicated to workshops and Birds of a Feather (BoF) sessions, where various groups in KDE - established project teams, groups spontaneously forming around a topic, or often a combination of both - discussed how to drive their ideas forward.

In addition to the already mentioned follow-up sessions to talks from the previous days, these were the sessions that inspired me most:

In the Plasma Mobile part of the Plasma BoF, we learned about Plasma Mobile's current status and discussed what needs to be done next. There is also a proposed community goal to improve the Plasma Mobile platform for end-user needs, so if you agree with me that Plasma Mobile is of strategic importance to KDE, please participate in the discussion there!

If you ask yourself what the deal is with all those community goals I keep referring to: The initiative to define some concrete mid-term goals for KDE for the next 3-4 years was actually born at Akademy, during a BoF titled '"Luminaries" Kabal Proposals', where Kevin Ottens, Frederik Gladhorn and Mirko Boehm presented to us what came out of their discussion about how they think KDE can be put on the right track towards the future. The goal-setting initiative was one of their proposals. Another one was integrating the KDE e.V. working group reports, which have so far been part of the AGM, into the general conference schedule, allowing people who are not members of the KDE e.V. to learn what's happening there, as well as significantly shortening the AGM. This proposal will be implemented at next year's Akademy. Their third proposal, making sure the barrier of entry to contributing to KDE is as low as possible, has been picked up in two goal proposals (which are likely to be merged into one), so, once more: If you agree that this is important for KDE, join the discussion over there!

In a BoF titled "Visual Design Direction", Andres "Andy" Betts brought up some ideas on how to better integrate designers into the Plasma development process again, and volunteered to spearhead the next round of design improvements. Andy has also submitted a goal proposal related to this, so… you know the drill by now.

BoF wrap-up session, where BoF leaders summarize the results of their session to the rest of the attendees

Closing Words (and a shameless plug)

Now that I've advertised various community goal proposals here (one of them being my own), let me use the final paragraph to link to my other proposal, Making KDE software the #1 choice for research and academia. This goal aims to give KDE software the exposure in the research and academic sector that it deserves due to its features and quality, but currently does not have. I think KDE has a lot to offer to researchers, teachers and students, so I'd like us to get in touch with them, promote our software to them and improve it based on their direct feedback. If you agree, participation is welcome!

With hat out of the way, I can summarize that this year's Akademy was a very successful event, despite being slightly smaller than usual (due to the location being a bit hard to reach and the timing falling into vacation time for many KDE members). I'm now full of enthusiasm again about the things to come for KDE, and looking forward to next year's Akademy in Vienna!


Filed under: KDE

19 Oct 2017 9:46pm GMT

KDE Edu sprint 2017 in Berlin

I had the privilege to attend the KDE Edu sprint in Berlin that happened from the 6th to the 9th of October.

There i mostly worked in the KTuberling port to Android. If you have children (or maybe if you want to feel like one for a few minutes) and an Android device please try it and give some constructive feedback ;)



Though of course that's not all we did, we also had important discussions about "What is kde edu", about how we should be involved in the "Making KDE software the #1 choice for research and academia" KDE goal and other organization stuff like whether we want a phabricator rule to send email to the kdeedu mailing list for a set of projects, etc.



Thanks go to all the people that donate to KDE e.V. that made sponsoring the trip possible, and to Endocode for hosting us and sponsoring all kind of interesting drinks and pizza on Sunday :)

19 Oct 2017 9:29pm GMT

feedplanet.freedesktop.org

Christian Schaller: Looking back at Fedora Workstation so far

So I have over the last few years blogged regularly about upcoming features in Fedora Workstation. Well I thought as we putting the finishing touches on Fedora Workstation 27 I should try to look back at everything we have achieved since Fedora Workstation was launched with Fedora 21. The efforts I highlight here are efforts where we have done significant or most development. There are of course a lot of other big changes that has happened over the last few years by the wider community that we leveraged and offer in Fedora Workstation, examples here include things like Meson and Rust. This post is not about those, but that said I do want to write a post just talking about the achievements of the wider community at some point, because they are very important and crucial too. And along the same line this post will not be speaking about the large number of improvements and bugfixes that we contributed to a long list of projects, like to GNOME itself. This blog is about taking stock and taking some pride in what we achieved so far and major hurdles we past on our way to improving the Linux desktop experience.
This blog is also slightly different from my normal format as I will not call out individual developers by name as I usually do, instead I will focus on this being a totality and thus just say 'we'.

I am sure I missed something, but this is at least a decent list of Fedora Workstation highlights for the last few years. Next onto working on my Fedora Workstation 27 blogpost :)

19 Oct 2017 6:35pm GMT

feedPlanet KDE

Kubuntu 17.10 Artful Aardvark is released

Kubuntu 17.10 has been released, featuring the beautiful Plasma 5.10 desktop from KDE.

Codenamed "Artful Aardvark", Kubuntu 17.10 continues our proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 4.13-based kernel, KDE Frameworks 5.38, Plasma 5.10.5 and KDE Applications 17.04.3


Kubuntu has seen some exciting improvements, with newer versions of Qt, updates to major packages like Krita, Kdenlive, Firefox and LibreOffice, and stability improvements to KDE Plasma.

For a list of other application updates, upgrading notes and known bugs be sure to read our release notes.

Download 17.10 or read about how to upgrade from 17.04.

19 Oct 2017 1:51pm GMT

18 Oct 2017

feedplanet.freedesktop.org

Christian Schaller: Fleet Commander ready for takeoff!

Alberto Ruiz just announced Fleet Commander as production ready! Fleet Commander is our new tool for managing large deployments of Fedora Workstation and RHEL desktop systems. So get our to Albertos Fleet Commander blog post for all the details.

18 Oct 2017 12:01pm GMT

Eric Anholt: 2017-10-18

Something went incredibly right, and review feedback poured in last week and I got to merge a lot of code.

My VC5 GL driver's patches for core Mesa got reviewed (thanks Rob Clark, Adam Jackson, and Emil Velikov), so I got to merge it to Mesa. It's so nice to finally be able to work in tree instead of on a rebasing branch that breaks most weeks.

My GL_OES_required_internalformat got reviewed by Nicolai Hähnle, so I gave it another test run on the Intel CI farm (thanks, Mark Janes!) and merged. VC4 and VC5 now have proper 5551 texture format support, and VC4 conformance test failures with 565 are fixed.

My GL_MESA_tile_raster_order extension for overlapping blit support on VC4 got merged to Khronos's git tree. Nicolai reviewed my Mesa implementation of the extension, so I've merged it. All that's left for that is merging the X Server usage of it and pushing it on downstream to Raspbian.

I tested the fast mutex patch series for Mesa, and found a 4.3% (+/- .9%) improvement in 10x10 copywinwin on my Intel hardware. Hopefully this lands soon, since those performance improvements should show up on ARM as well.

On the VC5 front, I fixed VPM setup on actual HW (the simulator's restrictions didn't catch one of the HW requirements), getting a lot of tests that do gl_ModelViewProject * gl_Vertex to work. I played around with the new GPU reset code a bit, and it looks like the next step is to implement binner overflow handling.

I've been doing some more review feedback with Boris. We're getting closer to merge on MADVISE, for sure. I respun my DSI transactions fix based on Boris's feedback, and it's even nicer now.

Next week: VC5 binner overflow handling, merging MADVISE, and hopefully putting together some Raspbian backports.

18 Oct 2017 12:30am GMT