[RFC weston 0/9] weston-debug protocol, API, and tool

Fri Jun 9 14:10:56 UTC 2017

Hi Pekka,

I like your idea with scope trees. I want to play around a little bit with the protocol next week. Later I will finalize my proposal for the protocol.
Maybe you are right and we can use the protocol as it is.

Do you think that the RFC is mergeable to upstream ? Are there something to address before ?

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Donnerstag, 8. Juni 2017 10:24
> To: Ucan, Emre (ADITG/ESB)
> Cc: wayland-devel at lists.freedesktop.org; Friedrich, Eugen (ADITG/ESB)
> Subject: Re: [RFC weston 0/9] weston-debug protocol, API, and tool
> 
> On Wed, 7 Jun 2017 14:28:58 +0000
> "Ucan, Emre (ADITG/ESB)" <eucan at de.adit-jv.com> wrote:
> 
> > Hi Pekka,
> 
> Hi Emre,
> 
> I'm adding back the Cc's. Replies below.
> 
> > > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > > Sent: Mittwoch, 7. Juni 2017 10:00
> > > To: Ucan, Emre (ADITG/ESB)
> > > Cc: wayland-devel at lists.freedesktop.org; Friedrich, Eugen (ADITG/ESB)
> > > Subject: Re: [RFC weston 0/9] weston-debug protocol, API, and tool
> > >
> 
> > > I explained that somewhere. The "list" scope will print a human
> > > description of everything supported. The description is not meant to be
> > > machine-parsable, not even the names.
> >
> > But then how can I implement a generic weston-debugger client ?`
> > It would be much better to have an event similar to global event of
> > wl_registry interface, which advertises available streams.
> 
> How do you mean you cannot? The client I provided is already completely
> generic.
> 
> You can add an event for informing about scope names, but what is the
> use case? If the use case is some GUI app with a list of scopes you can
> click, you probably also want to update that since scopes can be added
> and removed at runtime. That means one needs events for adding and
> removing scope names. Then you will have a race between the client
> subscribing to a scope name and the remove event, but that shouldn't be
> too bad since I defined an unknown name to just trigger the failure
> event.
> 
> If you really want all that, that's fine, but originally I thought that
> would be over-engineering this.
> 
> After reading your below comments, I think you wouldn't actually need
> that, because you would want to use the command line option to
> subscribe to debug scopes from compositor boot.
> 
> > >
> > > I never intended the scope names or the output to be standardized in
> > > any way, hence I thought there was no need to provide
> > > machine-readable introspection.
> > >
> > > I also wanted to leave the debug print formats themselves
> > > unspecified. Most of the scopes will not print machine-parsable
> > > text. I do not want to commit to "stable debug print formats" at
> > > all. I want to be able to easily add any sort of debug prints
> > > whenever I need them and push them upstream - if I needed it to
> > > debug something, quite likely it will be needed again in the
> > > future. Of course, when one adds a new scope, one can choose give
> > > whatever guarantees they want.
> >
> > My idea is a little bit different. We are working on embedded devices
> > which are not very easily debuggable. Furthermore, sometimes it is
> > very hard to reproduce bugs in an embedded device. Therefore, it is
> > very important that we have some logs about the issue when it
> > occurred.
> >
> > Our plan is to run the weston-debugger client all the time and parse
> > stream contents to a persistent memory. I don't think we have to
> > specify print formats tediously to achieve this. It would be enough
> > to say every debug message ends with "\n".
> 
> Sounds reasonable, but if you want to include upstream weston scopes in
> there, I cannot guarantee one line is a whole message. The output is
> meant for human consumption, so printing e.g. a long array one may want
> to break it into several lines, or format matrices one row per line.
> 
> But I do agree that one line should be at most one message.
> 
> You'll be interested in the command line option idea I wrote down
> below. A client may not get everything from boot.
> 
> 
> > > After all, the feature was intended to be used directly by humans,
> > > avoiding lots of tedious format etc. specification work.
> > >
> 
> > > I have two more ideas I did not write down yet:
> > >
> > > - A compositor could have another command line option to start the
> > >   named debug streams from boot to the given file(s). This way the
> > >   logging would start before any clients could even connect. If
> > >   implemented properly, scopes would be subscribed to the moment
> > > they are created, so no message would be lost.
> 
> Oh, and using this option without the --debug option would not expose
> the protocol interface, to avoid the DoS risks.
> 
> > >
> > > - Adding arguments to scope subscriptions, e.g. getting all protocol
> > >   events related to specific client(s).
> >
> > Both ideas are good. I have also another suggestion.
> > We can add debug log levels to subscribe request.
> > Levels could be "LOG, WARNING and ERROR" so that we can filter some
> > of logs.
> 
> I have not seen any need for log levels yet, and I would have very hard
> time to pick levels for my messages. Essentially we have two levels:
> weston_log() is the LOG, WARNING and ERROR level, and debug scopes are
> the DEBUG level.
> 
> In systems which use multiple debug log levels, I always enable either
> as much as possible, or nothing. If I picked something in between, I
> wouldn't know what I'd miss, so to be safe I always use the most
> verbose level. Levels are practically never documented by what they
> will give you, it's only a vague "more" or "less".
> 
> I would rather recommend just using different scopes for different
> levels of debug. It's totally supported to subscribe several scopes
> with the same underlying file, and the messages will be correctly
> ordered too.
> 
> E.g. for debugging XWM, I would imagine I have to enable at least
> xwm-wm-x11 and desktop-shell-xwm debug scopes to get a complete
> picture, possibly also desktop-shell-wm for generic WM messages. The
> human readable descriptions would also suggest these, so a newcomer
> will get a clue he might want more than just one.
> 
> > For example, it would be nice to have some logging about touch
> > handling. But it would be an overkill to get logging about every
> > touch event as default.
> 
> In my opinion that would be a perfect example for separate debug
> scopes, say: touch-actions and touch-events. You can pick either or
> both.
> 
> So far I can think of just one way of how different debug levels would
> be useful: if increased level provided more information on the *same*
> messages. E.g. level 1 prints only the action, level 2 prints the
> action and most important arguments, level 3 prints all arguments
> verbatim. But I haven't needed that yet, either, and it might be
> awkward to use in the code.
> 
> > The clients, who interested to get everything, can set log level to
> > LOG and other clients can set it to WARNING or ERROR.
> 
> I intended all this to be only DEBUG level. DEBUG prints are what will
> flood logs and cause performance degradation when enabled and require
> scoping. Informational, warning, and error messages should be logged
> via the normal logging system, IMHO.
> 
> I did not want this to supersede weston_log(). There is the 'log' scope
> which will allow you to see the non-debug messages between the debug
> messages in the correct order.
> 
> This discussion did bring a new idea to mind: we'd probably want named
> collections of scopes. E.g. scope 'input-events' would actually be the
> collection of scopes 'pointer-events', 'keyboard-events', and
> 'touch-events'. This would be more flexible than a level system, since
> you can really pick and choose exactly what you wanted. With a level
> system it is not usually possible to get only level 3 messages without
> level 1 and 2 messages - if levels were used to choose which messages
> to print rather than the level of detail for each message.
> 
> What I'm actually proposing is a tree of debug scopes, where the leaf
> nodes are where the actual messages are produced. None of this would
> require changes to the protocol though.
> 
> 
> Thanks,
> pq