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:[email protected]] > Sent: Donnerstag, 8. Juni 2017 10:24 > To: Ucan, Emre (ADITG/ESB) > Cc: [email protected]; 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)" <[email protected]> wrote: > > > Hi Pekka, > > Hi Emre, > > I'm adding back the Cc's. Replies below. > > > > From: Pekka Paalanen [mailto:[email protected]] > > > Sent: Mittwoch, 7. Juni 2017 10:00 > > > To: Ucan, Emre (ADITG/ESB) > > > Cc: [email protected]; 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
