Multimedia-chat-meeting-2018-04-05

11:16 < pinchartl> I'd like to start with the last topic this time
11:16 < pinchartl> next meeting
11:16 < pinchartl> as everybody is still here
11:16 < jmondi> thanks!
11:16 < pinchartl> I propose one hour earlier than today, which was the time I intended for today's meeting :-)
11:17 < pinchartl> Thursday 2018-04-19 at 
11:17 < pinchartl> 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST
11:17 < pinchartl> for the multimedia part
11:17 < pinchartl> so one hour earlier for I/O
11:17 < pinchartl> and half an hour earlier for Core
11:17 < pinchartl> would that be OK with everybody ?
11:17 < kbingham> pinchartl: I'll likely be on holiday that week.
11:17 < kbingham> But otherwise fine for me :)
11:17 < neg> Works for me
11:17 < geertu> Why only half an hour earlier for Core?
11:18 < pinchartl> because we usually have I/O at start + 0:00, Core at start + 0:30 and multimedia at start + 1:00 ?
11:18 < pinchartl> I meant half an hour earlier than 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST
11:18 < pinchartl> to make it clear
11:18 < pinchartl> I/O: 08:00 BST / 09:00 CEST / 10:00 EEST / 16:00 JST
11:19 < pinchartl> Core: 08:30 BST / 09:30 CEST / 10:30 EEST / 16:30 JST
11:19 < pinchartl> MM: 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST
11:19 < geertu> OK, I didn't know MM was the universal reference point ;-)
11:19 < geertu> "I propose one hour earlier than today", for all meetings
11:19 < pinchartl> it's my reference point when I write the MM report :-)
11:20 < pinchartl> geertu: too easy to understand ;-)
11:20 < pinchartl> is everybody fine with that schedule ?
11:21 < neg> fine for me
11:21 < uli___> me, too
11:21 < shimoda> yes
11:21 < jmondi> yup, I think for Europe is not a big deal as we're back where we were, maybe Japan doed not like 16pm?
11:21  * jmondi shuts up then
11:22 < pinchartl> jmondi: I assume Japan wouldn't mind going back home an hour earlier ?
11:22 < Marex> jmondi: that's 4pm, 4 is an unlucky number
11:22 < dammsan> i think it is a good idea
11:22 < pinchartl> jmondi: can I assume you're back, can we start the meeting ?
11:23 < jmondi> I haven't gone anywhere actually, but you can start, I'll read in 5 minutes
11:23 < jmondi> I need a coffe, I'm sorry
11:23 < pinchartl> ok :-)
11:23 < pinchartl> (I need a cup of tea)
11:23 < pinchartl> so welcome to the multimedia meeting
11:23 < pinchartl> Topic 1. Status Check for the Multimedia Tasks
11:23 < pinchartl> I was going to go in alphabetical order, but that would start with jmondi 
11:23 < pinchartl> so let's do reverse alphabetical order this time
11:24 < pinchartl> * Ulrich
11:24 < pinchartl> Since last meeting:
11:24 < pinchartl> - Sent summary of IGT test fails
11:24 < pinchartl> - Reviewed proposed additional tasks
11:24 < pinchartl> Until next meeting:
11:24 < pinchartl> - Up-port BSP patches
11:24 < pinchartl> Issues and Blockers: None
11:24 < pinchartl> uli___: any comment ?
11:24 < uli___> nope
11:24 < pinchartl> I have a question
11:24 < uli___> yes?
11:24 < pinchartl> what's your plan to upstream the igt patches you have sent ?
11:25 < uli___> no specific plan
11:25 < uli___> i haven't gotten around to fixing them up yet
11:25 < uli___> i guess that's on the todo
11:25 < pinchartl> ok, I'll had it to the todo list
11:25 < pinchartl> thank you
11:25 < pinchartl> next, neg 
11:26 < pinchartl> * Niklas
11:26 < pinchartl> Since last meeting:
11:26 < pinchartl> - [PATCH v3] i2c: adv748x: afe: fix sparse warning
11:26 < pinchartl> - [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller
11:26 < pinchartl> - Fished BSP code for up-port patches for VIN, CSI-2 and v4l2.
11:26 < pinchartl> - All VIN Gen3 support is now acked by both Laurent and Hans !
11:26 < pinchartl> - CSI-2 patches are now acked by Kieran, Laurent and Maxime !
11:26 < pinchartl> - Easter holiday.
11:26 < pinchartl> Until next meeting:
11:26 < pinchartl> - Collect review tags and small comments and repost VIN. Hans have  stated he intends to post a pull request for this as soon as -rc1 is  out.
11:26 < pinchartl> - Collect review tags and small comments and repost CSI-2. Ask Hans if  he also can send a pull request for that.
11:26 < pinchartl> - Once VIN Gen3 and/or CSI-2 driver is in media-tree start posting  up-port patches for those drivers (might not happen before next  meeting).
11:26 < pinchartl> Issues and blockers: None
11:26 < pinchartl> neg: any comment ?
11:26 < neg> Not on status update
11:27 < pinchartl> thank you
11:28 < pinchartl> * Morimoto-san
11:28 < pinchartl> Since last meeting: None
11:28 < pinchartl> Until next meeting: None
11:28 < pinchartl> Issues and Blockers: None
11:28 < pinchartl> morimoto: any comment ?
11:28 < morimoto> No :)
11:28 < pinchartl> easy :-)
11:28 < pinchartl> * Magnus:
11:28 < pinchartl> Since last meeting: None
11:28 < pinchartl> Until next meeting: None
11:28 < pinchartl> Issues and blockers: None
11:28 < pinchartl> dammsan: any comment ?
11:28 < dammsan> nope
11:29 < pinchartl> * Laurent
11:29 < pinchartl> Since last meeting:
11:29 < pinchartl> - Harvest BSP for multimedia patches
11:29 < pinchartl> - Patch review (VIN and CSI-2 are finally ready)
11:29 < pinchartl> - Preparation of additional tasks for Q2
11:29 < pinchartl> - Posted v2 of VSP BRU/BRS dynamic assignment
11:29 < pinchartl> Until next meeting:
11:29 < pinchartl> - Get the GMSL patches posted to public mailing lists
11:29 < pinchartl> - Upstream pending VSP patches
11:29 < pinchartl> Issues and blockers:
11:29 < pinchartl> - Ran out of Ben Shan oolong
11:29 < pinchartl> any question from anyone ?
11:29 < dammsan> how long is ben shan?
11:29 < pinchartl> https://teatrekker.com/product/ben-shan-spring/ :-)
11:30 < dammsan> =)
11:30 < pinchartl> * Kieran
11:30 < pinchartl> Since last meeting:
11:30 < pinchartl> - Tested Wheat D3 patch. Patches will be integrated through Simon's tree.
11:30 < pinchartl> - PeriUpporting
11:30 < pinchartl> - Examined ADV748x upport patches - Queried ADV748x std RESERVED_BIT patch. - Re: DRM Upport activities (Jacopo's thread) - Examined RCar-DU upport patches
11:30 < pinchartl> - VSP1 fix reported from Mauro
11:30 < pinchartl> See patch "media: vsp1: Fix BRx conditional path in WPF"
11:30 < pinchartl> - 4K testing
11:30 < pinchartl> Tests fail on plane-positioning and mode-set testing.
11:30 < pinchartl> - Reviewed BRx series from Laurent
11:30 < pinchartl> Until next meeting:
11:30 < pinchartl> - More 4K tests when I can move my board again.
11:30 < pinchartl> - Talk to Hans regarding EDID defaults
11:30 < pinchartl> - ... Some sort of additional task ...
11:30 < pinchartl> Issues and Blockers: None
11:30 < pinchartl> kbingham: any comment ?
11:30 < kbingham> Yes
11:31 < kbingham> Please add that I intend to take a week offline from 16th to 20th (this week was going to be my easter holiday week - but it's now moved to the 16th)
11:31 < kbingham> I'll likely (assuming we can still book it) be in a cabin in a forest with no internet access .. . :D
11:32 < pinchartl> lovely :-)
11:32 < pinchartl> will that include the surrounding weekends ?
11:32 < pinchartl> (I'll mark the weekends as part of your holidays ;-))
11:33 < kbingham> no actually ... but then we shouldn't be considering weekends as workdays ... uhm ... right ? :D
11:33 < pinchartl> :-)
11:33 < pinchartl> * Jacopo
11:33 < pinchartl> Since last meeting:
11:33 < pinchartl> - Analyzed BSP for DRM activities, helped with review of ADV devices and DU tasks, prepared list of suitable additional tasks.
11:33 < pinchartl> - LVDS encoder support: v[1-6] of the series. Waiting for Rob to tackle DTS properties name discussion
11:33 < pinchartl> - Review and discussion of Peter Rosin's bridge format patch
11:33 < pinchartl> - Implemented interlaced video support for CEU. Still to be tested
11:33 < pinchartl> - Reviews of sensor drivers (dw9870, ov7251)
11:33 < pinchartl> Until next meeting:
11:33 < pinchartl> - Tackle on of the D3/M3-N upporting tasks when assigned
11:33 < pinchartl> - Follow Peter Rosin's work for bridge format propagation and devel on top of it.
11:33 < pinchartl> - Possibly test CEU interlaced support
11:33 < pinchartl> - More SH fun with CEU camera
11:33 < pinchartl> Issues and Blockers:
11:33 < pinchartl> - Need to ping Rob directly to unblock LVDS
11:33 < pinchartl> - Welcome a Core/IO activity to alternate with Multimedia for Q2
11:33 < pinchartl> jmondi: are you back ?
11:34 < pinchartl> (how long does it take to make an Italian coffee ?)
11:34 < pinchartl> let's move to Topic 2. BSP Team Requests, we'll go back to Jacopo afterwards
11:34 < jmondi> pinchartl: yes
11:34 < pinchartl> ah :-)
11:34 < pinchartl> let's move to Jacopo then
11:35 < pinchartl> any comment ?
11:35 < dammsan> wsa_: please discuss additional tasks with me when you have time
11:35 < jmondi> pinchartl: you know we have a ritual for coffee
11:35 < wsa_> dammsan: i have time now
11:35 < morimoto> ritual
11:35 < morimoto> :)
11:35 < geertu> jmondi: I heard Starbucks coffee is better than Italian coffee...
11:35 < dammsan> wsa_: please move that to hangouts
11:36  * geertu hasn't tried Starbucks yet, IHRC
11:36 < jmondi> geertu: now we're going to have a fight on this
11:36 < pinchartl> morimoto: it's the Italian equivalent to 茶の湯
11:36 < morimoto> Ah, OK
11:36 < geertu> pinchartl: Nah, the Italian version takes less time
11:37 < pinchartl> コーヒー道
11:37 < pinchartl> more seriously, jmondi, any comment about the above list ?
11:38 < jmondi> nope, apart that I'll wait this afternoon and try to ping rob on irc eventually
11:38 < pinchartl> ok
11:38 < pinchartl> thanks
11:39  * morimoto I thought "ritual" means praying, bowing, etc
11:39 < pinchartl> morimoto: there are religious rituals, but ritual can be used in other contexts too
11:39 < pinchartl> Topic 2. BSP Team Requests
11:39 < pinchartl> - VIN/CSI2 format
11:39 < pinchartl> The VIN driver supports
11:39 < pinchartl> - MEDIA_BUS_FMT_YUYV8_1X16 - MEDIA_BUS_FMT_UYVY8_2X8 - MEDIA_BUS_FMT_RGB888_1X24 - MEDIA_BUS_FMT_UYVY10_2X10
11:39 < pinchartl> The VIN hardware can also support MEDIA_BUS_FMT_UYVY8_1X16 by using VnMC::YCAL. 
11:39 < pinchartl> The CSI2 driver supports
11:39 < pinchartl> - MEDIA_BUS_FMT_RGB888_1X24 - MEDIA_BUS_FMT_UYVY8_1X16 - MEDIA_BUS_FMT_UYVY8_2X8 - MEDIA_BUS_FMT_YUYV10_2X10
11:39 < pinchartl> The BSP team would like to have support for MEDIA_BUS_FMT_UYVY8_1X16 in VIN and for MEDIA_BUS_FMT_YUYV8_1X16 in CSI-2. Niklas will look into it.
11:40 < pinchartl> neg: morimoto: did I capture the e-mail communication correctly ?
11:40 < neg> yes
11:40 < morimoto> About format, yes
11:40 < morimoto> About mode, I posted use-case
11:41 < pinchartl> - VIN transfer mode
11:41 < pinchartl> Niklas solved the VIN transfer mode switching issue:
11:41 < pinchartl> git://git.ragnatech.se/linux v4l2/next/vin/mode-v2 https://patchwork.linuxtv.org/patch/47929/
11:41 < pinchartl> The patches will be upstream in v4.17.
11:41 < pinchartl> The BSP team has tested the code and confirmed the issue has been fixed. However, they noticed the disappearance of single capture mode support, and would like that functionality to be restored.
11:41 < pinchartl> Niklas noted that using continuous capture mode unconditionally simplified the driver and improved performances. If single capture mode is needed he isn't opposed to adding it back, but would like to have a clear description of the use cases.
11:41 < morimoto> It seems BSP team doesn't have strong reason
11:41 < pinchartl> ok. I propose continuing the discussion about VIN capture more on the mailing list then
11:41 < pinchartl> morimoto: you posted X-1, X-2 and X-4. is there no X-3 or have I missed it ?
11:42 < dammsan> may i propose "random" capture mode" to make it more exciting?
11:42 < neg> And I can't see a clean/usefull way of readding it other then a sysfs option / module paramater / v4l2 control to force using single capture mode, and all of those solutions seems odd
11:42 < neg> dammsan: I like your style!
11:42 < kbingham> Surely single capture mode is just send one buffer :D
11:43 < neg> kbingham: you need to specify how many buffers the driver wants before a stream can start and currently that is more then one, so no dice :-P
11:43 < pinchartl> neg: I agree with you. I don't see a use case for single capture, as we can capture a single frame even in continuous capture mode, can't we ?
11:43 < morimoto> pinchartl) sorry X- numbering is very random. total tree
11:43 < dammsan> how about using spectre/meltdown utility instead of silly sysfs?
11:43 < kbingham> neg: The driver no longer needs 3 buffers to start :D - (just 3 buffers to capture smoothly)
11:43 < pinchartl> morimoto: no worries, I just wanted to make sure I hadn't missed a X-3
11:43 < neg> pinchartl: yes, but you still need to queue 4 buffers as min_buffers_needed = 4
11:44 < pinchartl> did we have a lower minimum number of buffers when we supported single capture mode ?
11:45 < neg> pinchartl: yes, at first submission it was 3 then in a rework where it switched between single and continues capture the minimum was 1 but that led to the performance issue
11:46 < neg> pinchartl: so now with the always continues capture we need 4, which with a bit of work in patches I will submitt after Gen3 support is picked up might be able to be reduced to 3
11:46 < pinchartl> how about using single capture unconditionally when we have one or two buffers, and continuous capture when we have more ?
11:47 < pinchartl> I mean the number of buffers queued at streamon time
11:47 < pinchartl> that way we could support single capture using a single buffer
11:47 < pinchartl> without having to allocate buffers that will never be used
11:47 < neg> pinchartl: that could work, but then all v4l2 tools would run using single capture as they queue the min buffers needed and then start the stream
11:48 < pinchartl> do drivers report the minimum number of buffers they need ?
11:48 < neg> so to run in continues mode the applicaiton would need to know about this and queue more buffers before starting the stream or have bad performance
11:48 < kbingham> Can the driver report that it needs 4 buffers ... but 'accept' only one ?
11:48 < neg> pinchartl: yes in vb2_queue min_buffers_needed field
11:48 < pinchartl> neg: but that's not reported to userspace is it ?
11:49 < pinchartl> kbingham: I think the only information reported to userspace is through REQBUFS
11:49 < pinchartl> if you ask for less than the minimum, you get the minimum
11:49 < neg> pinchartl: not sure how user-space handles it, but somethigng in the v4l2 framework ensures that numbers of buffers are queued before s_stream is called
11:49 < kbingham> So no then :)
11:50 < pinchartl> if you ask for less than the minimum, you get the minimum
11:50 < pinchartl> oops
11:50 < pinchartl> we might need an API extension there
11:50 < pinchartl> but apart from that, I don't see how we could select between the two
11:51 < pinchartl> I agree that allocating buffers that will never be used is a waste of memory
11:51 < pinchartl> but to be honest, I also think that most use cases will capture video and will wait continuous capture mode
11:52 < neg> Yes, I agree. It's a waste of buffers if you only want to grab one frame but most use-cases IMHO would benefit from continues capture mode
11:53 < pinchartl> I think we could investigate that, but only if there's a real need, as development would require a substantial effort
11:53 < neg> So yes a API extension would probobly be needed if this where to be supported with a user-space interface
11:53 < pinchartl> are we done with this question ?
11:54 < neg> I still don't know if I shall handle this or if we are shelfing it
11:54 < dammsan> i propose shafing or quefing =)
11:54 < morimoto> The conclusion is supporting single mode is difficult at this point, and it needs API extension ?
11:54 < dammsan> instead of shelfing
11:54 < pinchartl> I'll state in the meeting report that we need feedback
11:54 < morimoto> And I think it is not realistic
11:55 < dammsan> please don't include my suggestions in the report
11:55 < neg> morimoto: I still don't understand the use-case, in your reply it only stated that single mode was used before, now it's not but it might be good if it where still an option. But I don't understand why that is :-)
11:55 < neg> dammsan: :-)
11:56 < pinchartl> morimoto: I think the conclusion is that we need an API extension to make real use of single capture mode, it will require substantial development effort, and we should thus only implement it if really needed
11:56 < wsa_> ack on the new meeting date. i can imagine 4pm is way better for JPeri
11:57 < morimoto> BSP team don't know how the customer is using single mode, or not. Their main reason is just simple. They want to keep compatibility, because they doesn't want to update BSP guid pdf :)
11:57 < wsa_> :D
11:57 < morimoto> I think we can drop single mode. what do you think ?
11:58 < pinchartl> morimoto: I think so too
11:58 < pinchartl> - Status of vsp-tests
11:58 < pinchartl> Morimoto-san reported vsp-tests failures on H3 ES1.1 in
11:58 < pinchartl> Subject: Re: [periperi] 2018-03-01 - Group meeting - Infos & Call for updates
11:58 < pinchartl> Date: Thu, 01 Mar 2018 15:50:45 +0900
11:58 < pinchartl> The issue has been discussed in the multimedia meeting on that day. The BSP team would like a status update.
11:58 < pinchartl> We haven't had time to look into these issues yet, they are still on the to-do list. As far as we understand this isn't urgent, but the priority can be raised if needed.
11:59 < pinchartl> that's all for the BSP team questions
11:59 < morimoto> I think it is not urgent.
11:59 < pinchartl> but today we have a new topic
12:00 < pinchartl> Topic 3. Questions for the BSP Team
12:00 < pinchartl> :-)
12:00 < morimoto> Just checking progress
12:00 < pinchartl> While going through the BSP patches to pick upporting candidate the following questions were raised (for the full discussion see "VIN and CSI-2 Upport" on the periperi mailing list). We would like the BSP team to provide us with information.
12:00 < pinchartl> - rcar-vin: Add memory type of VB_USERPTR support 373b05b01463bfbeca8d6382da29fa038ea4b8e1
12:00 < pinchartl> Is there a use-case for USERPTR? Niklas has never used it and Laurent explained that there are not many use-cases for this that are not better served by DMABUF. We would like to know more about this use-case before upporting this if possible.
12:00 < pinchartl> - rcar-vin: Add overflow debug message option 4c0da798c52053d5a10e6d74364c12c049af0caa
12:00 < pinchartl> Is there a test-case for this? Are overflows common or is this just some diagnostic help for debugging? If possible it would be useful to know more about the reason for this commit.
12:00 < pinchartl> - rcar-vin: Set MEDIA_LNK_FL_ENABLED by using rvin_get_chsel 29c1ff33427f2c56ccc3dd4a3dd79026b2316f77
12:00 < pinchartl> Niklas and Laurent discussed this commit and both think this is not suitable for up-porting. The user should enable the links in the pipeline as part of the format configuration before starting a stream.  Is there a use-case for this in the BSP which we should consider? How does Renesas feel about dropping this from the BSP ?
12:00 < pinchartl> - media: rcar-csi2: Add blank margin when caluculating bit rate e2f958eedfdcd63145e147f273585a66889fa0db
12:00 < pinchartl> What is the rationale behind this? Is this not a property of the video source and not the CSI-2 receiver? Should not this be included in the V4L2_CID_PIXEL_RATE reported by the source?
12:00 < pinchartl> On the periperi mailing list Niklas reported this should be upported, but Laurent disagreed and explained how it could be a property of the video source instead.
12:00 < pinchartl> - media: rcar-csi2: Fix field detection b6aac9f75929a1ac54e5b026eeb717a7db44aa8e
12:00 < pinchartl> We believe this patch follows a wrong approach. The standard shall not be propagated inside the kernel but be explicitly set by the user for a pipeline which is part of a media graph. Would this change in approach fulfill the use-case which lead to this patch in the BSP?
12:00 < pinchartl> morimoto: all this will be included in the meeting report, I don't expect you to answer right now :-)
12:01 < pinchartl> neg: did I capture all that correctly ?
12:01 < neg> pinchartl: wall of text, reading now :-)
12:01 < pinchartl> for everybody else: if you have any similar question regarding the BSP patches, please send them by e-mail (or ask them now if you want to)
12:03 < neg> pinchartl: looks good
12:03 < kbingham> pinchartl: I sent one question already to Matsuoka-san
12:03 < pinchartl> thank you
12:03 < kbingham> But really all I want to know is from "Re: [periperi] [PATCH] media: i2c: adv748x: Fix video standard selection register setting" if the patch fixes a known issue.
12:03 < morimoto> pinchartl: thanks, I will forward to BSP team
12:04 < kbingham> If it does'nt fix anything then I'll likely drop the patch.
12:04 < pinchartl> kbingham: sounds good to me
12:04 < pinchartl> so that's all for the question to the BSP team
12:04 < pinchartl> the next topic is something you've all been waiting for
12:04 < pinchartl> Topic 4. Additional Tasks for 2018 Q2/1
12:05 < pinchartl> The following additional tasks have been proposed for Q2/1, and Renesas has sorted them according to their priorities.
12:05 < pinchartl> 1) VIN and CSI-2 D3 and M3-N Support [9] (Split D3/M3-N)
12:05 < pinchartl> 9) DU D3 and M3-N Support [14] (Split D3/M3-N)
12:05 < pinchartl> 3) VIN and CSI-2 Power Management Support [2]
12:05 < pinchartl> 8) DU LVDS Dual Link Mode Support [1]
12:05 < pinchartl> 2) VIN Scaler (UDS) Support [4]
12:05 < pinchartl> 4) D3 VIN Support (Parallel Input) [0]
12:05 < pinchartl> 5) DU LVDS PLL Support [1]
12:05 < pinchartl> 6) DU 4k Display Support [2]
12:05 < pinchartl> 7) DU DPLL Fixes [3]
12:05 < pinchartl> We now need to estimate the effort.
12:05 < kbingham> what are the numbers in [*] ?
12:05 < pinchartl> the number of BSP patches that will be upported
12:05 < pinchartl> there are likely more patches than that
12:05 < kbingham> Aha ok
12:06 < pinchartl> I've only taken the ones that have been reported in the upport-related e-mails
12:06 < pinchartl> we can start estimating efforts now, or have a break and work on it this afternoon
12:08 < pinchartl> any preference ?
12:08 < kbingham> pinchartl: I'm fine here now as its only 11am, but it might be lunch time for you guys... so I can be flexible.
12:09 < jmondi> at 13.30 I will have builders here for a few hours to estimate some work in my place
12:09 < neg> I;d prefer this afternoon, but now works but if we do it like last time it will might be a longer meeting and then I might wish for a short break
12:09 < jmondi> I may be away for a few hours then
12:09 < pinchartl> I'd prefer having lunch first too
12:09 < jmondi> if afternoon is after 15pm CEST it should be fine for me
12:09 < kbingham> Ok - afternoon then :P
12:09 < pinchartl> after 15:00 CEST sounds good to me
12:09 < jmondi> thanks
12:10 < pinchartl> any other topic to discuss today ?
12:10 < neg> 1500 works for me
12:10 < kbingham> So - that's in how many hours :D
12:10 < kbingham> 3 ?
12:10 < neg> Not from me, thanks for summary of the BSP questions
12:11 < jmondi> not from me, thanks for the additional tasks proposals list
12:11 < pinchartl> 2h46 from now
12:11 < pinchartl> you're welcome
12:11 < pinchartl> the meeting is then adjourned
12:11 < pinchartl> thank you all for attending