 My name is Hans Verkau. I have been involved in the video for Linux subsystem for 14 years or so by now I Used to do about every year a status report during the ELC Haven't done it in the last several years. So I was thought it was time to do another one What is new is also CEC consumer electronics control. That's a brand new subsystem and That will be the second half So this is a two-parter the first half is video for Linux the second half is the status of CEC Depending on the time I may have I might have questions after the first half or I will postpone it until the end We will see how it goes So first video for Linux Start with the boring bit, but if you have that heart where it's very interesting of course So there are since several this is I'm going back several years now So in the last several years we have a whole bunch of new video for Linux drivers Renaissance for their our car automotive platform They are they are doing very very well. There's lots of support for those is is in in the kernel Texas instruments for various chips for the video capture codec parts Same thing for Texas instruments. They're in the automotive business Otmel some soon has done a lot of work for the codec supports in the axinos chips You you probably want it's fairly unlikely that we will see camera support for axinos 5 and up Due to the way they designed their hardware and firmware it is Unlikely that we will ever see something for that in the kernel Media tech very interesting They started to be active in about the last year year and a half and they have really do been doing a good job So these this driver for this codec came from media tech was developed by media tech themselves and it's very good quality. I Was pleasantly surprised by that ST microelectronics has been developing quite a few codec drivers as well what is interesting about this list is first of all the absence of of Is mostly that these companies are interested especially renaissance and ti in the automotive business So I'm seeing a so this is my own opinion. It may be completely wrong But I'm seeing a shift in how companies deal with with video with codecs and camera input In the past they used to have As you see vendors used to have a few big customers So they would take millions of chips from them And but there were only a few customers making smartphones and the life cycles were very short So while we would have loved to see upstream support, they basically were continually in the you know We have a next model coming up in a year and we have to develop for that So we have absolutely no time or interest in going upstream because it frankly doesn't We don't get any benefits We now see a shift in the industry going for two reasons one is automotive The main difference between smartphones is your car. You don't throw it away after a year or two so the support for Software in cars has to as a much longer life cycle and you need security fixes So there is much more interest in getting things upstream Because now it starts to make sense The other industry shift is that of the internet of things where instead of having with smartphones You have only a few big customers with internet of things. You have lots of small ones So with the smartphone business they can't put in support teams for just those customers You cannot do that for internet of things The only way to scale is to get things upstream using a standardized API That is easy to use and you don't have to support them and if it's upstream They can get automatically security fixes by just upgrading to the new kernel So I see a shift in the industry and I see a lot more interest in actually getting things upstream For the past one two years the main focus seems to have been on codex I am Uncertain how much we will see for camera ISPs a Lot of companies like to keep that secret for one reason or another So how that will work out? I'm not sure we will see how but the future will bring in that respect We might perhaps see fairly limited implementations. So you won't have to fool ISP functionality But you can get say the raw data from the sensor and you can do your own processing in a GPU if you want But then it's up to you so We will have to wait and see what will happen. This is basically what I see right now Let me go to the next slide because that is interesting Where the Qualcomm this is for example, there's a driver being developed for the Qualcomm camera system But that is a very limited Implementation so you can get data from the camera, but you won't have access to the full ISP But you can process it yourself if you want Other things that are upcoming free skill. So the free skill has always had a video for Linux implementation Which was frankly horrendous They managed to pick an API for sensors that was in the kernel for only I think two or three releases before it was deprecated and removed so every sensor drive they made is completely incompatible with anything that we have today and Frankly the driver source is it's really really really bad So a consultant came up and they actually to two competing implementations we had but one is now being picked as close to be in staging that did a great work for having almost full functionality, I think for free skill so see when it comes to the ISP and all the blocks that are in there So I'm very hopeful that this will go in in staging for 412 or 413 I'm I'm pushing it a bit I really like to get this in as soon as possible even if it's in staging Because free skill it sees a lot of traction a lot of people use it So this would be really nice for Qualcomm again, this comes from Consultants not yet from Qualcomm themselves unfortunately again I'm with the shift in industry this might change but for now it's been limited to consultants who ditched They look at the code and ditch it and write something proper themselves Synopsis is trying to get a CSI to Driver in here. I'm waiting for the next version for that to be posted and recently I learned that a Raspberry Pi 3 implementation was added and it's apparently in staging for 411 I haven't seen it yet, but that's what I what I heard So again, that will be very nice to have Raspberry Pi. It's really I Know there was a video flinx implementation out there, but it was never upstream so seeing this upstream will be very beneficial for lots of people I think Given the popularity of the Raspberry Pi So that is that is what we have been seeing in the form of drivers And especially the last year a lot of new drivers were posted and I'm hope that this will continue in the in the coming year so another thing we've been involved in our of course core activities core functionality that needs to be improved needs to be changed and The one thing that I'm working on is removing the SOC camera framework So for those who don't know as a C camera framework in the video flinx subsystem was a framework and it's Quite a long time ago when we didn't have to fool full-flash functionality that we have today to handle complex hardware And it was basically for very simple SOC pipelines and as a sensor Output goes into the SOC and you have a DMA engine perhaps a little bit of processing, but it's very limited. So very short very simple pipelines the problem that we had with that framework is that Sensor drivers needed to be written specifically for that framework So they were incompatible if you wanted to use it with the regular video flinx framework So you could have duplicate drivers or you have painful you wanted to use an SOC sensor But you use it with another as a see that didn't wasn't based on as a camera and you couldn't do that so we have done a lot of work in trying to convert existing SOC drivers to the regular model and There is now only one there are two left One is very close to being moved out and then the remaining one is for various reasons next to impossible to convert So we will just merge the SOC camera framework into that driver and make it impossible to be used by anyone else As you see camera has been a real big pain point because of the incompatibilities that it introduces So it would be really nice when it is finally removed Another thing we've been struggling with is Ref-counting and lifetime management So you have if you have a complex pipeline you have lots of objects lots of Devices and they all work together But when for whatever reason you either unbind or unplug something or in an FPGA you may remove a dynamically remove a block Then you need to make sure that the right things That memory sticks around until the last ref count goes away and lifetime management turned out to be really complicated In 99% of the cases everything works fine. You never notice But when you for example unbind forcibly unbind subdevice sensor Chances are everything will crash especially if you're streaming at that point We've been looking into improving that and work is being done on getting this done the right way But that really requires some very low-level changes in the framework to have to write ref-counting and locking in place But it would be good to have this While doing this one interesting thing that I was not aware of for a long time is Devmk Malloch and Kevin Devmk Z Malloch and friends It turned out that if you Allocate memory for a device like this. It will be really released as soon as you unbind that device But if others still depend on it There's there's no ref counting involved. So you unbind the device anything allocated with Devmk Malloch for that device is immediately released freed so this causes lots of issues and In practice you if you have a whole pluggable device you really cannot use Devmk Malloch You can do that with clocks and other hardware resources because once it is removed you can't use them anyway So it does make sense that they disappear, but memory you typically should not use that Unfortunately, we're using this in quite a few places because we were not aware of it But this needs to be fixed as well, I'm just mentioning it here because I didn't know I thought it was rev counted so when the When the last reference to the device truck itself would go away only then would the memory be released But that's not the case. It is released as soon as to remove call is called So this is not rev counted and that's not I did not expect that Another very big part that we working on Well, Lord on Pinchard specifically is the request API and stateless codec support Now this needs a bit of explanation Request API basically comes for the Android Hull support Android camera support What they do is for every frame that they submit to to capture You can associate settings controls like setting the right game setting the right white balance values Whatever and they need to be synchronized. So when you capture to that That buffer the same before you do that those controls need to be applied at the right time So you have per frame configuration. We do not have that today in the kernel we've been working on this for a long time and The first patch should have been there end of December and then it was end of January and it's still not there and I'm We are need to figure that out how to get something upstream So this is actually fairly complex is a fairly big change But we can If all goes well, we can really control everything on a per frame basis So not just controls like gain, but also dynamically changing resolution or formats or even even the pipeline the video pipeline You might change on the fly because that is what Android expects you to be able to do So we need to do that as well The other reason for the request API has to do with stateless codecs. So codecs, you know 8264, 8265, MPEG They the ones we have in the kernel today. There are stateful codecs. So the hardware will Remember the state you provide it with a role frame for an encoder and Internal states will remember whether it should be encoded as an iframe or a pframe or whatever And it keeps track of that over the lifetime a Stateless codec Offloads that to the CPU So when you pass in a frame you not only have to pass in the frame But also the current state and when you get the encoded frame back You also get to update the states back or you have to do that yourself. I'm not sure how that works exactly on the low level But that means that It is but it again is per frame configuration because you have to pass in not just the frame but also lots of information to the hardware So the request API and stateless codec support they go hand in hand You need you need the request API in order to implement the stateless codec an early version of the request API is Currently being used for several years now by Chrome OS So they have a some number of video philinex stateless codec drivers and they've just been carrying that patch series But they really would like to see this Support getting upstream so they can also upstream those drivers At 10 there is a session by Laurent Pinchard about exactly this topic stateless codec drivers so if you're interested I Pitch this talk to you to go there because you should get a lot more in-depth information Another thing we've been working on we have a media controller for those who do not know the media controller is an API That exposes the topology of your hardware, so it will show a sensor or a DMA engine various video devices and how they are all hooked together This is extended has been extended to cover also DVB and And The We also would like to see that for also, but that is very uncertain at this moment I'm not sure what the status is and also the CEC the new new stuff that I've been making I will talk about that a little more CEC will definitely happen because you need that the main problem we have right now for the media controller is that We need better documentation better compliance tests better utilities. There is too much. That's Fuzzy if you want to implement this there are too many things that are bits Should they do it that way should they do it that way the documentation isn't precise enough and I really would like to work on that my problem is getting time I Will try to get more time, but I'm kind of guaranteed that they actually can get it But this is I think the main blocking thing that's the media controller that is just it's 90% there But it's just missing the final covering the corner cases good documentation all the little things you need in order to make a nice API a really good API that is actually People can easily use What I also see that a lot of drivers that use this they tend to do the same thing and That needs to be refactored into a helper function so that it's a lot easier to work with the media controller So this is an example for the media topology for a USB video flinux and DVB stick It's a it's cheap hardware, but what what you see here is fairly complicated. So there are lots of things going on Let me see if I So the the yellow boxes they are all the actual device nodes So this is what applications will open and then issue I octals to and do the do the right things What has been new newly added to the media controller are the orange Lines That indicates what that device note actually controls so in this case Let me see this one controls the tuner So it can be used to set the right frequency and cetera and the demodulator so it can program that as well for the various protocols The other blocks so the dark blue ones are connectors the support for that is In progress, let me put it that way so this is a television inputs and we have as video and composite inputs and And the light blue ones are sub devices. So we have a tuner a demodulator audio TV the TV decoder and M-PAC transport stream demuxer and These What's that green whatever? These are the DMA engines that actually produce copy the internal data into memory The blue lines indicate how the data flows now there are there are some little things that are so for example you have you have in the Unknown error type really that needs to be a proper type So there are lots of things that need to be improved here to that those that final 10% We really need to tackle that and that cost that takes time and We really do not have that enough at the moment I think this is one of the bigger blocking issues to make that that people that needs to be sorted out Other things that are in progress. I really hope this year that we will get a visual codec driver So we are a big we love our visual drivers. We have a vivid driver, which is a visual video capture driver it emulates a sensor TV inputs as video input and HDMI input and It works brilliantly. It's ideal for testing your application It's ideal for us to test the API's and you can run it without having HDMI capture hardware And you can test your application with that. It's very very nice We do have a simple virtual memory to memory device driver So memory to memory means you give it a frame. It's processed. You get it back. So it's for codecs for scalers the interlaces any processing block that does something with video and The amazes back to memory We have a very simple Vigil memory to memory test driver But what we really would like to have is a visual codec driver So we can emulate the way codecs behave and ideally we can switch between a stateful codec and a stateless codec and Applications can then check their API towards a codec like that. See if they all do the right things I worked with a student Tom on the wheel and As part of his university studies he did a project for me figuring out what would be a good Nice codec to get into the kernel. So it had to be patent-free. It had to be simple You don't want an ace to six four encoder into the kernel. That's not a good idea. So it has to be simple fast Patent-free and he found a very nice one Hopefully he will have time to turn it into a real driver. If not, I will probably take it on And it would really help developing and checking the API and making good compliance tests for codecs Another thing I've been working on and I do a lot of I'm specializing in HDMI receivers and transmitters And as part of that the EDID is very important very important part of the whole protocol. So that's the display Extended display information So that's the definition. I'm not sure it tells you what the properties are of the display and The EDID decode utility is part of X-Windows Utility suite But it was fairly out of date and I've been doing a lot of work and updating it one of the things I still need to do is upstream it So it has now support for the latest HDMI 2.0 Standards and lots of extra checks so that it can verify whether the EDID that you make yourself is Actually according to the specification and it will warn if it's not For the same reason you can you know, you can hook up a display and check the EDID of the display whether it's correct or whether there's anything weird so it's a very nice piece of work and Has been very useful for us to to debug issues with displays So I really need to spend some time in getting this stuff upstream Not a utility I've been working on QVitcap is One way you can is similar to QV402 that already exists But this is much simpler. It just allows you to capture from a device node and it will just show the image What is nice about it is that on the fly you can change formats you can scale So this is specifically useful for prototyping when you want to bring up a new board You think you are getting one format from the hardware, but it turns out not to be the correct one And then you can just try various combinations and see okay. What is going wrong? Perhaps this wasn't interleaved because it was planer or Was it YUV? Why you why V or was it you why V why or what order actually do I get the stuff? You couldn't you can all do that interactively It's close to being ready But it's not quite there yet What is also nice is that this is the command line utility V for L to CTL You can actually if you install that on your box that you have that you're trying to bring up You can stream the data the video that you capture to a PC where QVitcap is running So you don't need to have a full HDMI output and fuel Display support and applications running on the system You can just stream it or through the internet through ethernet to a PC and watch it there Very useful in early stages of board bring up So one of the big problems we have video is complicated. So there are not that many people who know Really all the ins and outs and we really could do with more work with more people If you are involved as a company with video And you use video for Linux lots Think about giving back and that's specifically time I would love to have more code reviewers people are willing to dig into the core stuff If you are if you get involved in that the nice thing about it is that you can also control it to some extent You can control the direction things are going if you as a company have certain features you want get involved you know if you If you implement the support for that for that feature, you know, it will work for your hardware because you did it yourself so we would really like to get more people for the long term involved in this and To give an example how I do that with Cisco My Mondays and Fridays are completely for video for Linux. I don't I try not to do anything else Doesn't always work out But really you need to if this should work you need to make good Agreements with your manager that these days. I'm not working on the products. I'm working on this long-term support for video for Linux That worked best But you need to you need to make sure that you are not pulled off For the next customer emergency you have to sort of three days for that this works for me very well Not always, especially the last we had we were very busy as well the last several months and it I admit It was interfering with my video for Linux work, but I really try to limit that as much as possible if you're interested Go to Maro Chahap does the media subsystem maintainer or to me or the mailing list I would really like to get more people involved because this is important and we are just As more drivers pop up and more things need to be done We are running out of people to work on it. I think I'll take the questions at the end give them the time so cc What is it? Let me start with that. It is Cc is I'm missing. Oh, that's the next one. It's a pin on the htmi connector it's called consumer electronics control it's a pin on the htmi connector and It allows you to control other devices So the typical use case that you as a consumer will see is you have a blu-ray player You pop in a disc and the TV automatically goes on It starts playing and you can use the TV remote to also control the fold the the blu-ray player or vice-versa That's all done through cc it's a ridiculously slow Protocol with 400 bits bits not bytes bits per second So even the new horizons probe well beyond horizon Well, well beyond Pluto. It's faster than cc at one meter Latency sucks for Pluto probe, but the speed is a lot better than this What you typically have here you have a physical address that is given to you by the display in the edid and You have a logical address logical address is really a Nickname so it's not you know when I first started in cc I was thinking that this was some some special like an IP address There's nothing to do with that. It's really a nickname. You have a TV. You have a playback device You have a tuner you have a few tip a few different things that you can be and You allocate yourself a logical address or you allocate a nickname. It's like like IRC You know you want a nickname and if if you are locked in somewhere else under the same nickname you get a Variant of that nickname. It's sort of similar to that It's an optional feature to HDMI so you don't have to implement it but a lot of consumer electronics these days will have it Provide high-level control functions is based on the very old AV On very old scarred connectors. That's where it's first popped up in an earlier incarnation The protocol has been improved a lot, but for whatever reason they kept the physical characteristics So it's just as slow as technology from I don't know 20 years ago Which is a bit of a shame You have CC in AC my receivers in transmitters and stand alone USB dongles like this where you put in You have an AC my input and AC my output and through the USB you can control the CEC This is typically used with graphics cards that do not support CEC But you still want to communicate with your TV and that's what these things are used for Data packets you have a header bytes and then zero to 15 bytes of payloads and very very slow I've worked on this for quite some time because Cisco wants to use this a lot more So this was a good opportunity to make a proper API before this there was there was CEC support but not in the mainline kernel and every vendor did their own little thing and In 4.8. It was merged in staging and In 4.10 just released this Sunday. It finally was moved out of staging and is now mainline framework driver for this fairly popular device is included in the kernel and It's actually working very well I'm very pleased with it One of the things that are missing we want DRM drivers AC my transmitters when they detect New connect events and they read the EDID the EDID contains the physical address So that needs to be the CEC driver needs to be notified of that new physical address Russell King made a notifier framework for this and it was not quite 100% so a improved it further and I'm trying to get this in for 4.12. This is a missing piece that we really need Because it makes it much easier for DRM drivers to just send out a notification Hey, you're disconnected or hey, there's a new new physical address and you can have a separate CEC driver Because usually it's a separate IP block that can just receive that notification and then do the right thing We have Two new CC drivers pending one is for a USB similar to to this one a range shadow device ST micro electronics has one up and running The weird thing about CEC and really annoying actually is that the protocol the high-level protocol it is it can be ambiguous and More importantly a lot of vendors Do not comply to the spec now the reason behind this is this is again my opinion my guess is that The spec can be difficult to figure out So it's probably just can well very well be lack of knowledge But also there has been particularly in the beginning a lot of log in so it only works your TV of brand X Only works with the Blu-ray player of brand X So you're forced if you want to have this to buy it off the same brand It's improving quite a bit is my impression lately but there are still Weird things going on and Also the CEC spec if you read it there are lots of corner case a lot of special things that you need to do so it's not like a regular protocol where you just which is Nicely symmetrical and Systematic this is more ad hoc and oh dear. We have lots of people doing this. Well, let's let's hack support into the spec for this One very good example that we recently discovered is that if you have a display and you send it in to stand by or you switch to another input then on the Then the hot plug detects will go away But if the hot plug detects of the display goes low that means that there is no EDID so you lose as a CEC Device you lose your physical address Because that's part of the EDID But you still connected and CEC commands still work. So if you want to wake up that display you still need to be able to send a message and The CEC 1.4 specification says nothing about this, but in the 2.0. They added in the tiny Tiny notes. They said well in this case You can send the pole message or an image view on or text view on as With this specific logical address and then it will work as an exception We only recently discovered that actually what is currently in the 410 kernel does not support this yet I have a patch that I'm working on to fix this But those are the little annoying Corner cases and weird things that are it's very difficult to figure out if when you start out with CEC Because there are so many of them and I'm trying to get as much of that into the CEC framework So that you as a driver and application developer do not have to care about it and also that it is That it is properly implemented somewhere So that brings me to the next step, which are the CEC utilities I've three utilities. They are part of the V4L utils git repository CEC CTL is similar to V4L 2 CTL, which is just a Swiss Army knife you can Configure CEC adapters you can send any message that you like a full coverage of the whole specification So you can very easily check all sorts of things using that utility the next two The compliance and the follower test so the follower is sort of We you emulate what should happen in a TV or a playback device It's emulating so it's can follow messages. It was what it receives messages. It will reply with the right things And if you don't have your own application up running yet, you can just run this and see How it works when you hook up say a display? So you can consider this sort of a reference implementation how a typical playback device Would work in CEC and you can look at that it is it is Dual license as TPL and BSD so you just can't take that code and incorporate it in your own application That's sort of an initial template and then flash it out for your own specific use case The other is the compliance test and that tests a remote device So you can use that to test how well does my display? Corresponds to the specification how well does my Blu-ray player that I've hooked up correspond to the specification I've continually improving them They are written with the needs of Cisco in mind So we typically are playback devices. We advertise ourselves as a playback device or a TV device depending whether we transmitter or receiver and We've been concentrating on the features that we need we do have coverage for the other features But there are very simplistic tests and no way are they in depth. So if you are for example Want to test the tuner over TV? It will do a little bit, but it's by no means complete if you have patches you want to improve it Please do so. Let me let me post them to me or the mailing list I would love to improve that part, but since it's not a priority for for us It's unlikely that I will do that So that would really be up to whoever is using it to do that It is great because this is really ideal for deep backing any devices you connect to and see how well they correspond to the spec and If you're lucky enough to actually be able to talk to the vendor you can just so show the Basically a checklist succeed. This is what is wrong. And that's what is wrong. And this is not according to the spec Please fix this Another thing I've been working on sadly. I've not been able to test it for hotels There is an extension to the cc spec called the hospitality profile That can drive this place to do things like you know when you enter your hotel room It is all on low volume very annoying by the way, but Those things can be controlled through cc from a central server I've implemented in a test version of cc ctl I have implemented this but I've been unable to find a hotel yet that actually does this if I do I can hook up this device and just Start sending commands and see what happens Unfortunately, it's all coax at the moment and on ten are driven. So I'm not being able to do anything with that Love to be able to do that One thing that's very nice about this besides being able to be used as a cc Replacement for graphics cards that do not have it you can also use this to monitor So you can just you have a system with say Blu-ray player and TV You can put this in the middle hook it up to a laptop and monitor all the traffic that's going by very very nice Ideal for debugging issues So some of the resources are Media subsystem main upstream tree Utility media utilities including the cc utilities documentation cc is documented in you can find it all there. What's a public API is? And of course my email I So I'm for video flinux. I'm one of the maintainers for cc. I'm the only maintainer so we Cisco really developed this over the period of two about two years, I think and So if you have any questions any things just reach out to me and I'd be happy to help I would really like Like what we have right now it's much better than what we saw in In Android trees where it's all vendor specific. So this is working out very well if you get issues you find mistakes Whatever, please let me know It's also much easier to set up messages cc messages because there is a header that is in the in the There's a public header of the kernel Which lots of static inlines? You just call the right function in that from that header to fill in all the fields of a cc message So you don't need to you know copy all the cc defines yourself and make it all yourself It's all part and it's shared between user space in the kernel So it's all the same for both and that makes it a central place where all the is a central repository repository of all the knowledge and exceptions and weirdo things in cc and I really would like to have that Document everything that's weird corner cases get as much as possible into the framework So you as an application developer do not have to think about it And if you want to know if you do the right implementation, you just run the compliance test on your own code See what happens Much better the dark compliance tests in commercial products, but they are very expensive Apparently none of the at least TV manufacturers seems to run it because they are just You know the very first thing your tests will fail The spec says if you send a message that you do not support you should give back a feature abort Almost everyone I've tested does not do that It just silently ignores it and that's just you look into the compliance test official compliance test for cc. It's pretty much the first test So apparently nobody is actually running this on their own devices But this is cheap. It's free. You have a laptop. You all you need is one of these or If you have an embedded system where cc is already implemented you can use that So it's very easy to do so nice time questions Do we have any comments about lip cc? Shoot I do that in public. Let me put it this way. It's one megabyte of Fairly complicated overblown cc code a c++ code. I looked at it and I didn't like it And there are also so this is a user space implementation that is basically for those who do not know this basically a Library that has support for vendor specific cc APIs and That applications can use to to handle cc. Now. There are a few problems with that one First is the approach. I can't let It's made by the same manufacturer as this dongle and I can't blame them because hey There was no support for cc in the kernel. So they had no choice that we put that up front I mean given the situation. I may not like the code, but that they have it makes sense but this really cc really belongs into the kernel because you want to be able to be notified when the edid comes in or disappears and Live as lip cc. You need to do that in user space. So you need to read out this the edid from your graphics cards and Pass that on to lip cc. It all has to be done manually It's not This really belongs into the kernel There are various other reasons why it's this should belong in the kernel as well But this is one of the main ones and it's much nicer because right now you can configure your cc adapter I'm a T. I'm a playback device and The whole claiming of logical addresses is all done by the framework. So you disconnect and you reconnect and it will be Automatically be come up again So it's much easier if this isn't the kernel and I yeah, I also don't like the code So it's it's tightly come to the code is tightly controlled of lip cc Okay, okay. Yeah, and this video with these cc utilities. I happily accept patches if they pass quality control, of course, but I Really want to make this a good good framework this So this stuff into all this knowledge should be reposited into the utilities and into the framework Because it's way too complex otherwise Any other questions then thank you very much for turning up at this early hour