diff options
Diffstat (limited to 'wiki/Chat_log/20180405-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20180405-mm-chatlog | 322 |
1 files changed, 322 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180405-mm-chatlog b/wiki/Chat_log/20180405-mm-chatlog new file mode 100644 index 0000000..51fd72a --- /dev/null +++ b/wiki/Chat_log/20180405-mm-chatlog @@ -0,0 +1,322 @@ +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 + |