[GSoC Application Review] Application Review for Wayland Project

Fri Mar 18 14:49:32 UTC 2016

On Fri, 18 Mar 2016 14:53:45 +0100
Armin Krezović <armin.krezovic at fet.ba> wrote:

> On 18.03.2016 10:20, Pekka Paalanen wrote:
> > On Thu, 17 Mar 2016 16:37:25 +0100
> > Armin Krezović <armin.krezovic at fet.ba> wrote:
> >   
> >> On 17.03.2016 14:29, Pekka Paalanen wrote:  
> >>> On Sun, 13 Mar 2016 18:22:18 +0100
> >>> Armin Krezović <armin.krezovic at fet.ba> wrote:
> >>>     
> >>>> Hello Pekka, Quentin and Kat (sorry, don't know the real name yet).
> >>>>
> >>>> Pekka and Quentin have volounteered to review my GSoC application
> >>>> draft for the Wayland project. Pekka also suggested to add Kat to
> >>>> the list of reviewers.
> >>>>
> >>>> As suggested, I've used Google Docs to create a document. You can
> >>>> access it at:
> >>>>
> >>>> https://docs.google.com/document/d/1bBgH8h9UiAPkipGjxHePnmcVU73Tef033-xojVWIhCU/
> >>>>
> >>>> Embedded below is the text from document, so you can comment on
> >>>> individual sentences/paragraphs/etc if needed.
> >>>>
> >>>> Thank you in advance and looking forward to your reply.    
> >>>
> >>> Hi Armin,
> >>>
> >>> nice to hear from you. Since we last talked, I have learned that it is
> >>> actually encouraged for students to make their proposal drafts
> >>> completely public. You said public commenting is fine, so here it is.
> >>>     
> >>>> --- BEGIN HERE ---
> >>>>
> >>>> Project Proposal: Weston output management enhancements
> >>>>
> >>>> Armin Krezović
> >>>>
> >>>> Introduction
> >>>>
> >>>> My name is Armin Krezović, an engineering student studying at
> >>>> Faculty of Electrical Engineering, University of Tuzla, Bosnia
> >>>> and Herzegovina.
> >>>>
> >>>> Project Scope
> >>>>
> >>>> I am interested in implementing output hotplug in Weston. That
> >>>> includes making Weston able to start without any outputs present
> >>>> and implementing logic that handles output plugging/unplugging
> >>>> at runtime. When that's done, Weston will be able to properly
> >>>> configure newly plugged outputs, deconfigure unplugged ones and
> >>>> handle a situation when all outputs have been disconnected.
> >>>> This also includes applying different options for hotplugged
> >>>> outputs when their configuration is specified in the
> >>>> configuration file. And finally, depending on how long it will
> >>>> take to implement all the tasks listed above, I will try to
> >>>> implement output layout configuration through the Weston
> >>>> configuration file.    
> >>>
> >>> You might also want to consider if rewriting the output configuration
> >>> to match better the libweston architecture is in or out of scope for
> >>> your project. For reference, here are my thoughts on that:
> >>> https://lists.freedesktop.org/archives/wayland-devel/2016-February/027250.html
> >>>

> > Probably. There are interesting questions like should we report a fake
> > output to clients while there are no outputs, or should also the final
> > wl_output get removed. If it gets removed, how will the shell handle
> > maximized/fullscreened apps etc. You can propose a policy on what the
> > shell in Weston should do (if/when you do the work, not in the
> > proposal).
> > 
> > I'd expect fixing Weston core to be relative straightforward, but
> > making the shell(s) manage it requires inventing policies on what
> > should happen and how it will show towards the clients through e.g.
> > xdg-shell.
> > 
> > And don't forget that having automated tests would be extremely good to
> > have. I suspect this is a feature that will very easily break and go
> > unnoticed without tests. You might have e.g. the headless backend
> > simulate output hotplug.
> > 
> > Of course, drawing the line between in-scope and out-of-scope features
> > is up to you to propose. You probably don't have time to do everything.
> >   
> 
> Now, I'd too leave this one out from the proposal. Why? Because I'd like
> to receive input from more people involved with weston development. Sure,
> I can recommend a way or two, but there are always several ways to solve
> a single task.
> 
> From a quick look at the codebase, the fastest way would be to merge
> headless backend into the compositor, let a headless output always be
> present and hotplug everything else at runtime. Bonus task is to
> disable outputting to the headless output when non-virtual output is
> there and enable it when there are no others.

Hi Armin,

I don't like that idea, literally at least. The headless backend is
written as a test tool, and should remain one. It will likely grow even
more hack code for tests only, for example exactly what I mentioned
about tests: hooks to cause it to create and destroy outputs from the
test plugin.

Weston's architecture also does not allow multiple backends to be used
at the same time. *If* a fake output was needed, it'd be ad hoc, but I
would like to see an attempt without a fake output first.

> The other possible solution is like you suggested, to work with zero
> outputs at start, while possibly fixing shells and some clients.
> But, I am not sure I'm comfortable with possibly breaking other peoples'
> shells with that.

We break other people's shell plugins casually and often, there is no
need to worry about that if it leads to a cleaner solution. People know
we can break the plugin ABI on every minor release.

Clients are another thing, since I'm not sure if any compositor so far
has ever exposed no outputs, but even in that case, I'd say toolkits
would be better get fixed for that. I also don't expect you to fix
toolkits outside of Weston. You could ask what e.g. Mutter does when
you unplug the last output.

As I understand, the current status is that Weston does not work
without outputs. If you fix that, and then it's only the clients not
working without outputs, I'd consider that progress. You fixed Weston,
even though for an end user the result is roughly the same.

> This is why I want to use the community bonding period to discuss this
> with more people, not just yourself at this time. And while doing that,
> I can get more familiar with the code and look for alternate solutions.

Certainly.

> I'll make a note not to forget the tests, too.

Excellent.

> I'll update my draft later today. If everything goes well with that, I expect
> to submit everything on Monday (I've already received everything else that's
> necessary - this proposal is what's pending)

Good luck!

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160318/2095fb3d/attachment.sig>