On Thu, 28 Apr 2016 04:19:32 +0200 Armin Krezovic <krezovic.ar...@gmail.com> wrote:
> Hello everyone, > > As you may have seen, I was chosen to participate in GSOC > and work on your project. > > I do need to apologize for not contacting you sooner, but > it was a busy week here (midterms week), so I didn't have > much time to think about anything else. I hope you understand. > > I'll skip the introduction part, as I've already introduced > myself on this mailing list and also in my project proposal, > which is publicly available. > > I do want to note that the email address used last time was > different. From now on, this address will be used because > it's the one I used to register for GSOC. Hi Armin, I'll try to remember that. You should use that as your author/reviewer identity too, I often end up looking up email addresses from commits. > I must admit that I do not fully understand the part I'll be > working on just yet (it's not the weston code, but the DRM > part itself), but I am confident I can master that part as > well before the coding starts. So, expect some newbie questions > during the Community bonding period :). I wonder if there really will be much DRM part. DRM backend already handles hotplug, and I think most of the culprits are elsewhere. There seem to be lots of fairly trivial patches floating around these days, you are more than welcome to hone your reviewing skills on them. That would be excellent bonding period activity. Also, now that this years' GSoC selections are over, I think we could open the tasks reserved for GSoC applicants free for all once again. So if there is anything you'd like to tackle as an intro, feel free. :-) > Also, as I've noted earlier, I also want to use this Community > bonding period to discuss with everyone involved in the project > on what would be the best way to implement the feature I will > be working on when the coding period starts. I did suggest two > different ways in my project proposal, but I am open for more > suggestions. I'll send a separate mail about that as soon as I > familiarize myself with the code that's currently there (I can > manage that before next Wednesday). Very good. One of my first thoughts is how will you be able to conveniently test output removing and hot-plugging. Surely fiddling with cables while running the DRM-backend will be awkward, and if you need to debug, even more so. Yet, you need that before you can start finding the pain points. How about taking either the x11 or the wayland backends as the testbed for the Weston core changes, and writing a test plugin (either similar to, or extend tests/weston-test.c) that exposes a new protocol extension you can use to add and remove output windows from the backend by using a command line utility? [*] That way it would be easy to tell the backend to create and remove outputs at will, and you could later modify it for use in 'make check' tests. The DRM-backend does not really lend itself easily for that kind of output fiddling, that's why choosing x11 or wayland (and headless) backends. Actually, if you choose the wayland backend, we might be able to avoid patching the support into headless if we run weston/wayland under weston/headless in the test suite. > Last, I want to thank whoever it was that choose project mentors > for the great choice of mentors! I saw the welcome mail, but > didn't get the chance to reply to it. So, I want to use this > message to thank Pekka for the nice welcome mail. It's an honor > to be the first student to be selected for the Wayland project. You're welcome! Thanks, pq [*] Yes, I really did just propose that. The point is that it will be a test plugin, just like our existing test plugin that too exposes interfaces we would never expose at production runtime, and will never be installed with weston.
pgp9IY_bIRyEh.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
