path: root/wiki/Chat_log/20160831-mm-chatlog

Multimedia-chat-meeting-2016-08-31

10:05 < pinchartl> topics for the day
10:05 < pinchartl> 1. Status check for the multimedia tasks
10:06 < dammsan> pinchartl: please connect to me via google chat at some point today so we can briefly talk about some paper stuff?
10:06 < pinchartl> sure
10:06 < pinchartl> does anyone want to add another topic ?
10:07 < dammsan> i have an idea:
10:07 < dammsan> additional task proposals for next quarter
10:08 < dammsan> at least something to start thinking about
10:08 < pinchartl> it's a good time to start thinking about it, yes
10:08 < dammsan> nothing apart from that from my side
10:09 < pinchartl> Topic 1. Status check for the multimedia tasks
10:09 < pinchartl> ----------------------------------------------
10:09 < pinchartl> in sort -R order
10:09 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
10:09 < pinchartl> - Ulrich
10:09 < pinchartl> - Magnus
10:09 < pinchartl> - Niklas
10:09 < pinchartl> - Kieran
10:09 < pinchartl> - Morimoto-san
10:09 < pinchartl> - Laurent
10:09 < pinchartl> uli___: your turn
10:10  * geertu stops using gose
10:10 < uli___> see the e-mail i sent; i think task statusses are not affected by any stuff i have done since last time
10:10 < uli___> we would have to talk about how to proceed with hdmi out
10:11 < pinchartl> let me copy it here for reference
10:11 < pinchartl> A) Since last time
10:11 < pinchartl> - Refreshed HDMI out series for Gen3
10:11 < pinchartl> Updated for 4.8-rc2. (See also C.). Some of the larger patches (e.g. bridge API conversion) have been upstreamed and could be dropped.
10:11 < pinchartl> B) Until next time
10:11 < pinchartl> - Gen2 VIN integration
10:11 < pinchartl> C) Problems
10:11 < pinchartl> - HDMI out doesn't work on Morimoto-san's Salvator-X board.
10:12 < pinchartl> The CMA reservation patch that is part of the HDMI out series breaks the kernel. This patch is required, so we'll have to find out why it doesn't work. An issue with firmware 2.8.0 is the prime suspect ATM.
10:12 < pinchartl> - Product register access unresolved
10:12 < pinchartl> The HDMI out series requires access to the product register. How to implement that the right way is part of a discussion ("[PATCH 0/4] ARM: Renesas: R-Car3: Add product register support") that ended without conclusion.
10:12 < uli___> thanks
10:12 < dammsan> i sort of thought we had a plan about PRR
10:12 < dammsan> but that's a topic for core i think
10:12 < geertu> Yes, ES handling
10:12 < pinchartl> regarding the HDMI output series for Gen3, are there patches you think could be upstreamed sooner than latter ?
10:13 < pinchartl> s/latter/later/
10:13 < uli___> it consists of a lot of bit parts that should not bother anybody if they get merged
10:13 < uli___> the big issues are prr and (i guess) binding the dw-hdmi driver
10:14 < uli___> nobody has commented on the latter yet
10:14 < pinchartl> to ask it differently, are there patches you'd like to fast-track now, or should everything be merged together ?
10:14 < uli___> those things have already been picked up (bridge API etc.)
10:14 < uli___> the rest makes more sense together
10:14 < pinchartl> I agree
10:15 < dammsan> May I ask why the CMA reservation patch is required?
10:15 < pinchartl> what's the plan for the CMA issue ?
10:17 < uli___> without it, the du driver fails to initialize
10:17 < uli___> i get the same result as morimoto-san in that case
10:17 < uli___> (panic)
10:17 < pinchartl> do you know why ?
10:17 < uli___> no
10:18 < dammsan> it is usually possible to increase the default CMA area with other standard methods
10:18 < morimoto> This patch was created by Fukawa-san, and I can ask to him. But he is talking to other guy now
10:18 < dammsan> morimoto: Fukawa-san is adding that patch for the MMP
10:18 < dammsan> see the patch commit message
10:19 < dammsan> it is way of dealing with memory management for the inhouse multimedia package
10:19 < dammsan> it is not the same as what upstream is supposed to do
10:19 < dammsan> just applying it blindly seems a bit short sighted IMO
10:19 < pinchartl> I'll have a look at that
10:20 < dammsan> uli___: what happens if you increase the default CMA size?
10:20 < uli___> haven't tried that. now that i think about it, i had a similar issue on lager where that helped...
10:20 < uli___> i'll check it out
10:20 < pinchartl> the DU driver could fail with the default CMA area, but the kernel should not panic in any case
10:21 < dammsan> yeah, same thing existed on older generation as well
10:21 < dammsan> pinchartl: agree that panic is not supposed to happen
10:21 < morimoto> Mine doesn't *panic*, but DU do nothing.
10:22 < neg> (My M3 carrier just arrived, need to run down and fetch it)
10:23 < dammsan> pinchartl: any idea how much work there is to enable HDMI on M3-W?
10:23 < pinchartl> dammsan: once it works on H3 it should be pretty straightforward
10:24 < pinchartl> (after enabling DU on M3-W of course)
10:24 < dammsan> i wonder if DU on r8a7796 differs from r8a7795
10:24 < dammsan> the driver development portion for that would be useful to get done sooner than later
10:24 < pinchartl> it differs but not in a way that should cause any issue
10:24 < dammsan> please note that i would like to control the integration order on r8a7796 to coordinate with IPMMU
10:25 < dammsan> but some prototyping w/o IPMMU would be useful for sure
10:26  * neg is back with a big box of 'High Reliabibility Parts of Electronics'
10:26 < geertu> Christmas is early this year...
10:27 < pinchartl> uli___: what's the status of 'VIN HDMI input EDID' ?
10:28 < uli___> i guess hans needs a nudge there, i was asking if the series should be split up into code and DT
10:28 < uli___> i though he was just going to review niklas's patches first
10:29 < pinchartl> please remember to send the description of the test environment to Jinzai by the end of the weekend (September the 4th)
10:29 < uli___> will do
10:30 < pinchartl> thans
10:30 < pinchartl> thanks
10:30 < pinchartl> next, dammsan 
10:31 < dammsan> nothing to report here really
10:31 < dammsan> currently poking around with IPMMU and DU, about to test the code from pinchartl =)
10:32 < pinchartl> any issue or blocker ?
10:33 < dammsan> not so far, i suspect some display list code may need more attention
10:33 < dammsan> but i will know for sure later today
10:34 < pinchartl> ok
10:34 < pinchartl> next, neg 
10:34 < neg> a) VSP HGT driver almost done, evrything works just some documentation missing. Hans picked up a patch sereis for VIN so one step closer to Gen3 support upstream
10:34 < neg> b) Post HGT driver and onther VIN patch which Hans hopefully will pickup for v4.9
10:34 < neg> c) HGT test program to emulate HST (RGB->HSV) do not match HW perfectly. No review on VIN GEN3 patches I don't think they will make it to v4.9 :-(
10:35 < pinchartl> regarding HGT
10:36 < pinchartl> I had a look at the RGB to HSV transformation
10:36 < pinchartl> the test application that generate frames is able to compute S and V exactly
10:36 < pinchartl> but for H it differs from the hardware values by 1 at most, in ~8% of the cases
10:37 < pinchartl> you've asked Morimoto-san to check if we can get information about how the hardware performs the transformation
10:37 < morimoto> About your question about RGB <-> HSV, I think I replyed answer. Does it OK for you ?
10:37 < pinchartl> and he replied that the BSP team has no information about it
10:37 < pinchartl> I'm not surprised, as it's a hardware-related question :-)
10:38 < pinchartl> do you think we could get information from the hardware team ?
10:39 < morimoto> The Document issue S vs V is under HW team control now.
10:39 < pinchartl> S and V are fine. it's H that we have trouble with
10:40 < neg> morimoto: yes I understand that precision is lost in RGB->HSV->RGB as the manual states but this is for RGB->HSV which is deterministic. If I use a lookup table for the 8% of values I can not compute the HW is emulated perfectly
10:41 < pinchartl> there's a division by 3 in the equation used to compute H, and I'm pretty sure the hardware approximates that by a multiplication followed by a shift (probably *341/1024 or *683/2048)
10:41 < pinchartl> but even with that we haven't been able to achieve a perfect match
10:41 < neg> so it's the way I calculate RGB->H that is wrong and if possible I would like input on
10:42 < pinchartl> neg: I wouldn't say it's wrong. the issue is that the hardware performs approximations and rounding in a way we don't know
10:44 < geertu> neg: How big are the absolute errors? E.g. can't you just allow -1/+1 differences?
10:44 < pinchartl> geertu: when comparing images, sure, but when computing histograms it can cause an unknown amount of pixels to fall into another bucket
10:45 < neg> geertu: the error is in the range +/- 1 but it's used to generate a histogram with buckets and that error results in a value being counted in the wrong bucket unfortunatly
10:46 < neg> alsa this is only for the test application, so one workaround is to only test it using 1 out of 6 buckets
10:46 < geertu> Can multiple values end up in the same bucket? or is it one-to-one?
10:46 < neg> multiple values can go in the same bucket
10:47 < pinchartl> the histogram generator puts pixels in buckets and reports the number of pixels in each bucket (roughly)
10:47 < neg> there are in total 6 buckets wich can be spread out over a value range of 0-255
10:48 < geertu> If the test software uses one-to-one buckets, it can calculate upper and lower bounds for each hardware bucket, assuming a max error of -1/+1
10:48 < pinchartl> geertu: I don't see how that would help
10:49 < pinchartl> a -1/+1 error can cause a pixel to fall in the next bucket
10:49 < geertu> i.e. sum (sw_bucket[first..last]) <= hw_bucket <= sum(sw_bucket[first-1..last+1])
10:49 < geertu> And the total sum must match
10:49 < pinchartl> in the worst case all pixels could fall in another bucket
10:50 < pinchartl> the purpose of the test is to verify that the driver works correctly. if we have to accept 100% errors, it's quite pointless
10:50 < geertu> Sure, but only due to a -1/+1 difference, right?
10:51 < pinchartl> still
10:51 < pinchartl> we want to catch things like an off-by-one write to registers
10:51 < pinchartl> which would result in pixels falling the another bucket the same way than the H computation error would
10:52 < geertu> In that case you do need to know exactly how the hardware works
10:52 < pinchartl> that's my point, yes
10:52 < pinchartl> anyway, Morimoto-san, if we can get information from the hardware team about how the hardware computes the H value from the R,G,B values, then we'll be able to test the HGT
10:53 < neg> geertu: we know how the HW works for S and V only H still eludes me :-)
10:53 < pinchartl> otherwise we won't be able to catch HGT regressions in the test suite
10:54 < pinchartl> neg: regarding the deadlines
10:54 < pinchartl> you mentioned that tests should be done tomorrow
10:54 < pinchartl> but, first of all, the due date is September the 4th
10:54 < pinchartl> and it's only the description of the test environment that's needed
10:55 < pinchartl> not the full test suite
10:55 < morimoto> OK, I will find HW guy, and will ask.
10:55 < pinchartl> i.e. the list of the test tools
10:55 < morimoto> I can say it will be long term.
10:55 < pinchartl> so that Jinzai can cross-compile them already
10:55 < neg> pinchartl: ohh I thought the entier test suite should be done
10:56 < pinchartl> morimoto: thank you. if we can get the verilog code corresponding to the H computation, I can find out how the hardware works myself ;-)
10:56 < morimoto> pinchartl: OK
10:56 < pinchartl> neg: test scripts can still be modified until the final due date
10:56 < neg> but if they need to compile the tools now this still needs to be done since this is in the gen-image test tool of vsp-tests
10:57 < pinchartl> they can recompile the test tools when performing tests
10:57 < neg> ahh great
10:57 < pinchartl> what they want to avoid is running into cross-compilation issues at the last minute
10:57 < pinchartl> a git pull && make, if there's no additional dependency, is fine
10:58 < neg> I take it from this discussion that it's better for me to submit a vsp-tests that only uses 1 bucket over bundeling the 54M lookup table and use all 6 buckets? Atlest untill we figure out how the HW works
10:59 < pinchartl> yes, please
10:59 < neg> good
11:00 < pinchartl> kbingham: you're next
11:00 < neg> About VIN Gen3, please find time to review it :-)
11:00 < kbingham> VSP-Partitioning Status
11:00 < kbingham> Initial prototype for partition algorithm implemented, work in progress to debug some issues, and get some real testing going.
11:00 < kbingham> Ongoing Plan:
11:00 < kbingham> After a little bit of catch up from being on holiday, my plan is to work on progressing the VSP partitioning, and get some viable tests going. Then of course solve all the bugs that will inevitably pop up.
11:02 < kbingham> If you need me to look at FDP1 stuff anytime - let me know, as I'll focus on VSP for the moment.
11:02 < pinchartl> thanks
11:02 < pinchartl> let's focus on the VSP, yes
11:02 < pinchartl> I'll post my current version of the FDP patches
11:03 < pinchartl> no issue or blocker ?
11:04 < morimoto> pinchartl: could you get M3 board ? and forwarded it to kbingham ? I would like to know
11:04 < kbingham> none at the moment - as I've not got very far yet with being back. Various accountant things and email catch up took up most of yesterday. but I can actually boot a board today :D
11:05 < pinchartl> morimoto: not yet, it's currently in a plane from Tokyo to Helsinki according to the shipment tracking page. it should land in the afternoon
11:05 < morimoto> Ahh, OK. Thank you
11:06 < pinchartl> morimoto: your turn :-)
11:06 < morimoto> OK
11:06 < morimoto> RSND,v4.10,public,morimoto,DT bindings for graph sound
11:06 < morimoto>  
11:06 < morimoto> this is on going. it need many steps.
11:07 < morimoto> but it have small steps now.
11:07 < morimoto> RSND,v4.10,public,morimoto,dw-hdmi-i2s-audio prototype on Gen3
11:07 < morimoto> I posted this patch to ML, and I think it is OK
11:07 < morimoto> but maintainer had summer vacation, and it seems forgot about this
11:07 < morimoto> RSND,v4.10,prototype,morimoto,HDMI SSI prototype on Gen3
11:08 < morimoto> This works in my local envilonment on old kernel.
11:08 < morimoto> It doesn't work on latest geert's branch, because of above HDMI out issue.
11:08 < morimoto> HDMI sound is based on HDMI video
11:09 < morimoto> RSND,v4.10,plan,morimoto,HDMI sound Upstream support without hotplug on Gen2
11:09 < morimoto> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3
11:09 < morimoto> Is is big topic
11:09 < morimoto> ALSA SoC framework should be cleanup/update
11:09 < morimoto> This is related to unbind issue too
11:10 < morimoto> I posted this topic to ML, and we had discussion
11:10 < morimoto> And I posted cleanup patches.
11:10 < morimoto> 1 series was accepted. but other was NACK:ed by Lars
11:11 < morimoto> I think I and Lars and maintainer (= Mark) want to talk F2F (?)
11:11 < morimoto> EOT
11:11 < pinchartl> thank you
11:11 < pinchartl> regarding the HDMI output issue with the latest renesas drivers tree
11:12 < pinchartl> you mentioned in your e-mail that you would like to know the plan
11:12 < morimoto> Yes, is this Ulrich's task ?
11:12 < pinchartl> we've discussed this earlier, Ulrich will check if we can just increase the default CMA area size without requiring the DT patch
11:12 < pinchartl> uli___: is my understanding correct ?
11:12 < uli___> yes
11:13 < pinchartl> thanks
11:13 < morimoto> OK, nice. I thought it (= prototype) was his task, but after that it is Laurent's task.
11:13 < morimoto> OK, uli___ has this handle
11:15 < morimoto> no more comment form me
11:15 < morimoto> s/form/from/
11:15 < pinchartl> morimoto: will you attend ELCE ?
11:16 < morimoto> Yes
11:16 < morimoto> Lars has presentation about this topics
11:16 < pinchartl> it would be good to schedule a face to face discussion with Lars
11:16 < morimoto> I think so
11:16 < pinchartl> I'm not sure if his presentation will address this specifically
11:17 < pinchartl> I think he will talk, among other things, about the current mess with the Intel audio hardware
11:17 < pinchartl> (i.e. no Linux support for audio on latest Intel platforms)
11:18 < morimoto> interesting
11:18 < pinchartl> could you contact Lars to schedule a meeting ?
11:19 < morimoto> no. I think I can find him on ECLE ? or should I ask to him ?
11:19 < pinchartl> please ask him beforehand, everybody is busy during ELCE, and this is important enough to make sure we can allocate enough time for the discussion
11:20 < morimoto> OK, will do
11:20 < pinchartl> thank you
11:21 < pinchartl> next, me
11:21 < pinchartl> since last meeting
11:21 < pinchartl> vacation :-)
11:22 < pinchartl> I've submitted IPMMU + DU integration patches
11:22 < pinchartl> they have been tested on Gen2 only due to the IPMMU being broken on H3
11:22 < dammsan> pinchartl: on ES1 =)
11:22 < pinchartl> the patches include DT integration and changes to the FCP, VSP and DU drivers to make it all work
11:22 < pinchartl> dammsan: yes, ES1.0 :-)
11:23 < pinchartl> I've also reworked Kieran's FDP driver and will post a v2
11:23 < dammsan> pinchartl: it seems the integration stuff is somewhat experimental, is that correct?
11:23 < pinchartl> which fixes several issues but breaks overalll operation :-)
11:23 < pinchartl> yes, it's experimental
11:23 < dammsan> cool, thanks
11:23 < pinchartl> the DT part should be quite stable
11:24 < pinchartl> changes to the FCP, VSP and DU drivers is experimental
11:24 < pinchartl> I'd really appreciate a careful review
11:24 < pinchartl> not so much for the implementation itself, but for the APIs between the drivers
11:24 < dammsan> right
11:26 < pinchartl> for the next two weeks
11:26 < dammsan> the DT part does not seem to change so much =)
11:26 < pinchartl> no, the DT part is quite stable I think
11:26 < dammsan> hehe
11:26 < pinchartl> there's no new Dt binding
11:26 < dammsan> that's a good thing
11:27 < dammsan> but we do want a stable implementation too =)
11:27 < dammsan> but it begins with a review
11:27 < pinchartl> definitely :-)
11:27 < pinchartl> for the next two weeks
11:27 < pinchartl> - Continue working on the FDP driver to get it merged upstream
11:27 < pinchartl> - VSP image partitioning support
11:27 < pinchartl> - DU and VSP integration on H3
11:27 < pinchartl> - VIN and HDMI output patch review
11:28 < pinchartl> blockers and issues
11:29 < pinchartl> Geert pointed out, when reviewing the DU and VSP DT integration patches, that the latest Gen3 errata removed VSPD3
11:29 < pinchartl> the DU3 channel is now fed by VSPD0, as is the DU0 channel
11:30 < dammsan> this is true for both H3 and M3-W?
11:30 < pinchartl> no, only for H3, M3-W has 3 DU channels only (DU0 to DU2)
11:30 < pinchartl> not only does this not match my experience with H3 ES1.0 on which I've used VSPD3 with DU3 successfully
11:30 < pinchartl> but it would also completely break the whole VSP + DU software model
11:31 < pinchartl> I think I've politely mentioned "brain-dead design" when replying to the e-mail
11:31 < pinchartl> I'd like to get more information about this
11:31 < dammsan> that's very polite of you =)
11:31 < pinchartl> and how it's supposed to work
11:33 < dammsan> there may be some sort of reason behind all this
11:33 < pinchartl> morimoto: do you think I could bother you to get more information about this ?
11:33 < dammsan> if it makes sense or not is a different question
11:34 < pinchartl> first of all, whether the errata is correct or not
11:34 < pinchartl> whether it applies to H3 ES1.1 only or ES1.0 too
11:34 < pinchartl> and how DU0 and DU3 are supposed to be operated if they use the same VSPD
11:35 < dammsan> right
11:35 < morimoto> Can you email it me ? I can ask to HW guys.
11:36 < pinchartl> sure, thanks
11:36 < pinchartl> I'll explain that in the meeting report
11:36 < pinchartl> would you like a separate e-mail ?
11:36 < morimoto> meeting report is OK
11:36 < morimoto> Is this for HW team ? or BSP team ?
11:36 < pinchartl> thank you
11:36 < pinchartl> that's all for me
11:36 < pinchartl> Topic 2. Additional tasks for Q3 2016
11:36 < pinchartl> -------------------------------------
11:37 < pinchartl> we need to start thinking about additional tasks
11:37 < pinchartl> obviously specific requests from Renesas should be taken into account
11:37 < pinchartl> but we can also be proactive and propose tasks for areas that we have identified as needing love
11:37 < pinchartl> I would thus like feedback from all of you about this
11:38 < pinchartl> if you already have ideas please mention them now
11:38 < pinchartl> otherwise, please think about it this week and propose them by e-mail
11:38 < pinchartl> and just talk to me on IRC
11:38 < dammsan> M3-W DU prototype
11:39 < dammsan> M3-W VIN prototype
11:39 < pinchartl> I'll double-check the details, but I think we can skip the prototype stage and go directly to an upstream-ready patch series for M3-W DU
11:39 < pinchartl> for VIN I'll let neg check what makes sense
11:40 < neg> Will check and get back to you
11:40 < dammsan> that sounds nice, but perhaps we can do prototype for first batch and upstream for next
11:40 < dammsan> we don't know what kind of issues that may be lurking
11:40 < dammsan> if you can do upstream-ready directly then that's fine too
11:41 < dammsan> we need HDMI video out support too eventually
11:41 < pinchartl> let me get my M3-W board and then I'll check what makes the most sense
11:41 < pinchartl> but in any case an M3-W DU task makes sense
11:41 < pinchartl> yes
11:41 < dammsan> sounds good
11:42 < dammsan> are we ready for a dma_buf zero copy user space test program?
11:42 < dammsan> from vin via vsp to du
11:42 < pinchartl> I think we're ready to start working on that, yes
11:43 < pinchartl> we still haven't addressed cache management
11:43 < dammsan> how about audio test program, for loopback testing of kHz setting and L-R issues
11:44 < dammsan> i think the cache management requirement actually means that they want to improve performance
11:44 < pinchartl> yes
11:44 < dammsan> and they have some sort of proposal
11:44 < dammsan> which may or may not make so much sense
11:44 < dammsan> but we probably need some base line to begin with
11:45 < pinchartl> we need to come up with a proposal to achieve proper performances
11:45 < pinchartl> whether it requires special cache management is more of an implementation detail
11:45 < dammsan> yes exactly
11:46 < dammsan> it depends on what user space does too
11:46 < dammsan> i think it makes sense to cook up a zero copy test app as counter-proposal
11:47 < dammsan> but perhaps i need to listen to their requirement more
11:47 < pinchartl> :-)
11:47 < dammsan> how long time would a zero copy test app take to implement?
11:47 < dammsan> would it be possible in one "slot" of additional tasks?
11:48 < pinchartl> I think so
11:48 < dammsan> in two weeks something should be doable IMO
11:48 < dammsan> so i hope to figure out some additional task for all memebers sometime soon this month
11:49 < dammsan> this for the first slot of next quarter
11:49 < dammsan> the second slot content can be discussed in Berlin
11:49 < dammsan> i hope to fix the first slot content in middle of September
11:50 < pinchartl> sounds good to me. I propose letting everybody think about additional tasks until the end of the week and discussing them early next week
11:50 < dammsan> good idea
11:50 < pinchartl> everybody, please think about what you believe is needed and let me know by the end of the weekend
11:52 < pinchartl> I propose holding the next meeting in two weeks from now
11:52 < pinchartl> 2016-09-14 at 09:00 BST / 10:00 CEST / 11:00 
11:52 < pinchartl> EEST / 17:00 JST
11:53 < neg> time works for me
11:53 < uli___> +1
11:53 < dammsan> me too
11:54 < dammsan> we should have finalised the first slot of additional tasks by then
11:54 < dammsan> the due for first slot is 11/M and second slot is 12/M
11:54 < dammsan> same pattern as current quarter
11:55 < pinchartl> ELCE and LPC will fall in the first slot
11:55 < pinchartl> who will not attend ELCE ? and who will attend LPC (I will) ?
11:55 < morimoto> LPC is what ?
11:55 < morimoto>  
11:56 < pinchartl> Linux Plumbers Conference
11:56 < dammsan> did not consider LPC yet
11:56 < pinchartl> in Santa Fe https://www.linuxplumbersconf.org/2016/
11:56 < pinchartl> (November 1-4)
11:56 < dammsan> intend to attend ELCE and also Linuxcon
11:56 < pinchartl> it will be collocated with the kernel summit
11:56 < pinchartl> anyone plans to attend the kernel summit by the way ?
11:57 < pinchartl> (I will)
11:57 < morimoto> Kobayashi will attend to LPC from OSD2 :)
11:57 < morimoto> I wil attend ELCE
11:57 < pinchartl> :-)
11:57 < pinchartl> neg: uli___: kbingham: how about you ?
11:57 < uli___> elce only.
11:58 < kbingham> ELCE only here ...
11:58 < neg> ELCE and if there is periperi stuff before LinuxCon I will also attend it
11:58 < morimoto> Oh, we can meet kbingham this time !!
11:58 < kbingham> I haven't booked flights yet - so  Ican extend if needed.
11:58 < kbingham> but I'm booked in the Conference hotel.
11:59 < pinchartl> we need to decide whether to have a peripericon in Berlin sooner than later, but that's not a multimedia topic
11:59 < morimoto> I will go to Berlin 10/3 - 10/14
11:59 < dammsan> i'll also be there those days
12:00 < pinchartl> I currently don't plan on attending LinuxCon but I can change my plans to some extent if needed
12:01 < dammsan> there is a deadline for cheaper conference tickets on 3rd btw
12:01 < morimoto> Maybe we can have MiniPeriCon if needed ? not FullPeriCon
12:01 < pinchartl> that's an option too, yes
12:02 < pinchartl> I think we're done for today
12:02 < pinchartl> I propose adjourning this meeting
12:02 < pinchartl> does anyone second ?
12:02 < neg> I'm happy to go also go 10/3 - 10/14 if there is meeting or stuff to be done (drinking beer is stuff)
12:03 < neg> seconded
12:04 < pinchartl> thank you
12:04 < pinchartl> have a nice day/evening everybody
12:04 < pinchartl> thank you for attending
12:04 < dammsan> thanks, you too
12:04 < morimoto> Thanks.
12:04 < neg> thanks all
12:04 < uli___> thank you