#v4l 2015-09-02,Wed

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)

Who	What	When
bottest	test	[13:10]
***	bottest has quit IRC (Quit: Saindo) aard has quit IRC (Read error: Connection reset by peer) Muzer has quit IRC (Excess Flood)	[13:24]
.... (idle for 16mn)
	Parker_ has quit IRC (Ping timeout: 244 seconds)	[13:45]
mchehab	people, i started a new IRC log server at linuxtv, as the older one was not working nice... logs will be at: http://linuxtv.org/irc/irclogger_logs/ please let me know if you experience any troubles with that the logger will be done by the nick name: [LOGGER] if it doesn't join the chat, it means troubles ;)	[13:47]
hverkuil	hmm, clicking on the 'v4l' or 'linuxtv' links on that irc log page produces: Cannot list channel irclogger_logs/v4l (no dir /var/log/irclogger/irclogger_logs/v4l) not sure what it is supposed to do.	[13:53]
.... (idle for 19mn)
mchehab	hmm... http://linuxtv.org/irc/irclogger_log/linuxtv?date=2015-09-02,Wed let me recheck those urls	[14:13]
javier__	mchehab: the irclogger_logs is duplicated in the link	[14:14]
mchehab	yes, but not sure why i was guessing that this was a cache issue with opera it is working fine newer firefox versions seem to handle cache on a different way	[14:14]
javier__	mchehab: with chrome it's also not working fyi	[14:17]
mchehab	i forced a clean at the caches on firefox, and it is now working there was a wrong redirect in the first setups could you try to cleanup the caches and see if the problem remains?	[14:18]
hverkuil	mchehab: pinchartl: I might be a bit later for the irc meeting depending on traffic	[14:20]
jmleo	small (dumb ?) question: can a subdev register a subdev if it is described as such in DTS ?	[14:21]
***	headless has quit IRC (Quit: headless) ChanServ sets mode: +o mchehab mchehab changes topic to: video4linux / analog video support * git repo: http://linuxtv.org/git/media_tree.git * http://linuxtv.org/wiki * bugs: http://bugzilla.kernel.org (v4l-dvb category) * subscribe to linux-media ML: http://vger.kernel.org/vger-lists.html#linux-media * channel logs: http://linuxtv.org/irc/irclogger_log/v4l/	[14:22]
javier__	mchehab: yes, after clearing the browser caches, the link is correct indeed	[14:25]
***	mchehab changes topic to: video4linux / analog video support * git repo: http://linuxtv.org/git/media_tree.git * http://linuxtv.org/wiki * bugs: http://bugzilla.kernel.org (v4l-dvb category) * subscribe to linux-media ML: http://vger.kernel.org/vger-lists.html#linux-media * channel logs: http://linuxtv.org/irc/irclogger_log/v4l ChanServ sets mode: -o mchehab	[14:25]
.... (idle for 16mn)
	egavinc has quit IRC (Remote host closed the connection)	[14:42]
shuah	mchehab: tried Chrome and Firefox cleared caches - still doesn't work for me	[14:51]
mchehab	shuah: http://linuxtv.org/irc/irclogger_logs/ ?	[14:54]
shuah	yes I see that page	[14:55]
hverkuil	mchehab: http://linuxtv.org/irc/irclogger_logs/irclogger_logs/v4l still broken for me as well (firefox & chrome)	[14:55]
mchehab	hverkuil: there are two irclogger_logs on the above url should be just one http://linuxtv.org/irc/irclogger_logs/v4l	[14:56]
shuah	ah success - the above worked on Chrome	[14:56]
hverkuil	ah, that's better	[14:56]
javier__	mchehab: Ok, the problem is when the URL ends with a / http://linuxtv.org/irc/irclogger_logs <= works http://linuxtv.org/irc/irclogger_logs/ <= doesn't	[15:00]
mchehab	ok. not sure if this would be easy to fix I'll see that after the meeting it is already 6pm on Finland time, right?	[15:00]
javier__	mchehab: yeah, I just pointed out in case you still didn't know what triggered the issue	[15:01]
pinchartl	yes it is. time flies... let me grab a cup of tea I'll be ready in a minute	[15:01]
mchehab	ok I'm ready for the meeting. just ping when it is ok for everyone	[15:01]
shuah	ok I am here as well	[15:01]
hverkuil	I'm ready.	[15:02]
pinchartl	ok I'm ready too I haven't heard back from Sakari though	[15:06]
mchehab	ok well, let's start then...	[15:06]
pinchartl	he just texted me saying "30 minotes" I have no idea what that means though :-) let me quickly call him	[15:06]
mchehab	no problem for me if we start 30 mins latter (if that's what he's meaning)	[15:07]
hverkuil	it would be OK for me too, but not later than that.	[15:07]
pinchartl	yes that's what he meant he's on his way	[15:08]
mchehab	ok if not a problem for the rest, let's then wait ~30 mins for him to join	[15:08]
hverkuil	ack	[15:08]
shuah	ok	[15:13]
.... (idle for 16mn)
sailus	Hello!	[15:29]
pinchartl	right on time :-)	[15:29]
mchehab	ok, let's start then first topic from the email: links namespace should we define a v2 for the flags, e. g. newer flags will be like #define MEDIA_V2_LNK_FL_ENABLED, or should we just add new stuff at MEDIA_LNK_FL_*	[15:32]
pinchartl	is that about flags for the in-kernel API, or for the userspace API ? or both ?	[15:33]
mchehab	we're focused on userspace API	[15:34]
pinchartl	ok	[15:34]
hverkuil	I see no reason to add a new namespace for the flags.	[15:34]
***	APic has quit IRC (Ping timeout: 246 seconds)	[15:34]
mchehab	(of course, kernel API may need changes depending on what we decide)	[15:34]
pinchartl	if we keep the existing flags and add new ones I don't really see a reason for a _NEW_ or _V2_ either	[15:34]
mchehab	s/kernel/in-kernel/ ok. one of the things I proposed there was to add a flag to distinguish interface links from data links: #define MEDIA_NEW_LNK_FL_INTERFACE_LINK (1 << 3)	[15:34]
pinchartl	note that I'm still not convinced that using the existing link object to expose interface links/associations is a good idea, but let's assume for the purpose of the discussion that we go that way	[15:35]
hverkuil	pro: it's simple to set in the kernel and simple to check in apps.	[15:35]
mchehab	of course, if we do that, such flag should never be exposed to the old API, as we don't want interface links there	[15:36]
hverkuil	con: what if we get different types of links in the future? E.g. entity-to-entity (if one entity controls another). Flags are not really suitable for that. Would a static inline function that checks if it is an interface-to-entity link be more suitable?	[15:36]
pinchartl	if we are to reuse media_link then I'd prefer showing explicitly that the link is an interface association instead of deducing it from the type of objects on the two ends of the link	[15:37]
shuah	could two entities be linked by interface as well as data - there will two links between them - in that how would flags work	[15:37]
hverkuil	shuah: you are right. I'm OK with a flag.	[15:37]
pinchartl	sailus: any comment ?	[15:38]
sailus	Yes. Do you have alternatives in mind?	[15:38]
***	agd5f has quit IRC (Remote host closed the connection)	[15:39]
pinchartl	sailus: could you elaborate ?	[15:39]
hverkuil	shuah: I just remembered that data flows between pad objects, not between entities. there are no datalinks between entities.	[15:40]
shuah	yes that is correct - data links are between pads	[15:40]
hverkuil	so the two alternatives are either a flag or a static inline that checks the object types the link connects.	[15:41]
pinchartl	hverkuil: I'd still prefer the explicit option over the implicit one	[15:41]
hverkuil	I have no strong preference myself.	[15:41]
mchehab	hverkuil: one alternative for the con would be to reserve <n> bytes at the flag to tell the type of the link... e. g.	[15:42]
shuah	pinchartl:could elaborate on explicit vs implicit	[15:42]
sailus	I wonder if we could have different types of objects at both ends of the links than just pad/pad and pad/interface (assuming now that interfaces are conveyed to the user space using links).	[15:42]
mchehab	something like that #define MEDIA_LINK_FL_TYPE (3<<3)	[15:43]
pinchartl	shuah: explicit means showing the link type in the link object, while implicit means deducing it from other information, the type of the sink and source objects in this case	[15:43]
hverkuil	mchehab: masks are always a bit messy. Having a 'link_type' field is easier when coding.	[15:43]
sailus	In that case there would be a proliferation of such flags.	[15:43]
shuah	I am with pinchartl on this - it would be good to have explicit	[15:43]
pinchartl	link_type is an option too. it would waste a couple of bits but I don't think that would be a big issue	[15:44]
mchehab	works for me	[15:44]
pinchartl	sailus: does that mean that you would prefer a link_type field ?	[15:45]
sailus	I have no strong preference.	[15:45]
mchehab	still I think that link_type would be overkill, as this can always be inferred from the object types	[15:45]
hverkuil	The field should probably be just called 'type' since it will be part of the media_v2_link struct.	[15:45]
shuah	one more thing - when there is an active data link - having a way to quickly check at media device level which data paths are active	[15:45]
sailus	I think I'd favour it, but only slightly.	[15:45]
pinchartl	hverkuil: type is fine	[15:46]
hverkuil	I think a type field is the most generic and future-proof way to go.	[15:46]
pinchartl	if memory footprint is really a concern we could use u32 type:4, flags:28;	[15:46]
mchehab	shuah: not sure what you're meaning... media_device is kABI, not uAPI	[15:46]
hverkuil	internally, yes. Not in a public API. Sadly (I'd love to be able to use bitfields)	[15:47]
mchehab	pinchartl: that's not portable due to endianness	[15:47]
shuah	I will get to mine after we discuss type	[15:47]
pinchartl	mchehab: how so ? mchehab: we can't run a big-endian userspace on a little-endian kernel, can we ? :-)	[15:47]
hverkuil	I don't think it is endianness that is the problem, it is that different compilers can pack bitfields differently.	[15:48]
pinchartl	my main issue with bitfields is that it's easy to forget they're not atomic oh really ?	[15:48]
hverkuil	C doesn't standardize that.	[15:48]
mchehab	yes	[15:49]
pinchartl	I thought they were standardized :-/	[15:49]
mchehab	depending on the compiler, it will use different endiannes and even different sizes	[15:49]
pinchartl	then it's indeed not an option	[15:49]
mchehab	or do bit reorder that's why when we need this on userspace API, we end by using macros	[15:49]
pinchartl	tell me that at least gcc and llvm agree on it :-)	[15:50]
mchehab	pinchartl: I guess even on that it can do weird things... depending on the compiler options	[15:50]
shuah	active data link indication at media device level is for kABI. e.g: ALSA/DVB/Video want to quickly check if there is an active pipeline tuner and decoder (busy) - currently it takes a graph walk if remember correctly. Does MC next gen simplify this - we can get to this after type is settled	[15:51]
mchehab	the patches I'm working so far are not addressing it feel free to write some patches if you have a good idea for that back to uAPI... if we want to pack the type, we need to do this via either macros or inline functions	[15:52]
pinchartl	right	[15:54]
hverkuil	shuah: in the general case you won't have a choice but to walk the graph.	[15:54]
pinchartl	I don't care too much on whether we pack it or not but I'd like to make it explicit	[15:54]
shuah	I can do that - I am going to port over the ALSA work I am doing to MC Next Gen to see how this works - the current problem I have is not being able to easily find if tuner is busy.	[15:54]
pinchartl	so either a couple of flag bits, or a type field	[15:54]
mchehab	I would use macros at UAPI to avoid any weird issue with the several c++ different compiler behaviors	[15:54]
shuah	hverkuil: yeah that is a bummer	[15:54]
mchehab	I'd vote for a couple of flag bits	[15:55]
sailus	There are plenty of flags left.	[15:56]
mchehab	yes	[15:57]
hverkuil	I prefer a separate field myself. Internally we can use a bitfield, externally all this information is going to be parsed by the application anyway so I really don't care if we use a bit more memory for this additional field.	[15:57]
shuah	do we still support 32-bit userspace	[15:57]
pinchartl	we could also use the MSBs of the flags field to allow the type bits to grow down if needed in the future	[15:57]
hverkuil	shuah: yes	[15:57]
sailus	We could snatch one reserved field and use u8 for the type, leaving the other three reserved2.	[15:57]
pinchartl	hverkuil: I'm fine with both	[15:57]
sailus	Me, too...	[15:57]
pinchartl	(but again, please note that I might challenge usage of struct media_link for this when I'll finish reviewing the patch series)	[15:58]
shuah	how can we make sure we aren't exporting too much in UAPI - once it is out it is out, we can't change it	[15:59]
hverkuil	Starting with bit 31 in flags and adding bits if needed would work for me. So the type for an interface link would be (1 << 31).	[15:59]
mchehab	hverkuil: there are too many links to be passed on a hybrid DVB device... on a PC consumer device, we're talking about ~1K links	[16:00]
pinchartl	what ?	[16:01]
mchehab	adding one additional u32 would mean one extra page	[16:01]
pinchartl	how many entities and interfaces are there in such a device ?	[16:01]
mchehab	pinchartl: a typical demux has one sink pad and 256 source pads on each source pad, two data entities are linked	[16:01]
hverkuil	mchehab: as sailus said, we can take just a u8 for the type.	[16:02]
mchehab	one for TS output via demux, another one for TS output via dvr	[16:02]
pinchartl	mchehab: that's a clear sign that something is wrong in the API	[16:02]
mchehab	on each such interface, there is a ringbuffer	[16:02]
hverkuil	For example: __u32 reserved[5] is replaced by __u8 reserved[4*4+3]; __u8 type;	[16:02]
mchehab	that can be used for read() or mmap() (after we add mmap() support)	[16:03]
pinchartl	that's a software demux, isn't it ?	[16:03]
mchehab	pinchartl: no, the API is not wrong or hardware demux that depends on the device	[16:03]
hverkuil	Alternatively: __u8 type; __u8 reserved[4*4+3]; but that has alignment problems if we need to add a __u32 later.	[16:04]
pinchartl	a hardware demux with 256 independent DMA engines ?	[16:04]
mchehab	PC consumer's hardware demux typically have 32 outputs pinchartl: as I explained dozens of times, on DVB, the DMA engine is somewhere between two entities as it is at USB devices	[16:04]
pinchartl	for a software demux, yes not for a hardware demux	[16:05]
mchehab	even for hardware demux	[16:05]
sailus	mchehab: Do you have as many interfaces as well?	[16:05]
mchehab	if the device is USB, the DMA will be at the xHCI driver sailus: no. one interface controls all ringbuffers	[16:05]
pinchartl	for USB you're limited by the number of endpoints. if the streams are multiplexed over a single endpoint then there's a software demux on the receiving side 256 source pads is a clear sign that something is wrong in our design	[16:06]
mchehab	even with multiple endpoints, the DMA is at xHCI driver	[16:07]
pinchartl	that's not limited to DVB	[16:07]
mchehab	and software is needed to remove USB headers and fill the ringbuffers for the userspace API	[16:07]
pinchartl	we also have an issue with devices that have a large number of entities and a large crossbar switch that can connect the entities in any orde r the number of links grow quadratically in that case that's something we should address in the API revamp design	[16:07]
devinheitmuell-1	Does the MC framework allow for dynamic creation of new pads?	[16:09]
mchehab	devinheitmuell-1: for now, no	[16:09]
pinchartl	devinheitmuell-1: that's not planned	[16:09]
mchehab	but yes, we could use dynamic PAD creation for the ringbuffers	[16:09]
devinheitmuell-1	The reason I ask is because while you could have 256 links, that definiltely wouldnâ€™t be a common use case.	[16:09]
pinchartl	I'd be reluctant to go that way as it opens another can of worms	[16:09]
sailus	mchehab: The entries in the ring buffer should not be visible in the media graph.	[16:09]
mchehab	sailus: they need to	[16:10]
sailus	Why?	[16:10]
mchehab	userspace needs to route them to hardare hardware	[16:10]
devinheitmuell-1	pinchartl: Yeah, I hear you. It definitely creates new problems (in particular if generating graphs dynamically like gStreamer does)	[16:10]
mchehab	(some of them)	[16:10]
pinchartl	mchehab: that could be handled by the DVB API but anyway	[16:10]
sailus	Has that been done in the past?	[16:10]
pinchartl	that's a separate discussion	[16:10]
sailus	If yes, how?	[16:10]
mchehab	pinchartl: why to write another MC juist for DVB?	[16:11]
hverkuil	can we go back to the topic of the discussion?	[16:11]
pinchartl	to summarize what we've just discussed I think everybody agrees to use an explicit link type	[16:11]
mchehab	yes	[16:11]
pinchartl	whether to use bits of the flag field or a new type field is still up for discussion Sakari, Shuah and I have no strong opinion	[16:11]
shuah	yes	[16:12]
pinchartl	so I propose to differ discussing that particular point and let Mauro and Hans debate on it the 256 source pads issue is a separate topic that I'll want to revisit too	[16:12]
hverkuil	Either take a __u8 from the reserved fields, or create a mask for 5 or 6 bits for the flags field. I leave that up to Mauro.	[16:13]
pinchartl	if that's fine with everybody I propose moving to the next item on the agenda	[16:13]
mchehab	ok next topic: entities namespace right now, it is messy, as the current namespace was mixing interfaces and entities this is easy to fix at the non-subdev entities	[16:13]
pinchartl	agreed	[16:14]
mchehab	(and my patch series did that - we can of course rename them as needed, and hverkuil gave a proposal during the review) the big problem there is what do to with the MEDIA_ENT_T_V4L2_SUBDEV* namespace my proposal is to reorganize it like: MEDIA_ENT_T_CAMERA_foo - for camera stuff (sensor, flash, ...) MEDIA_ENT_T_RF_foo - for things like tuner, LNBf, LNA MEDIA_ENT_T_DTV_foo - for digital TV stuff MEDIA_ENT_T_ATV_foo - for analog TV stuff MEDIA_ENT_T_MEDIA_foo - for common media blocks (scaler, resizer)	[16:15]
pinchartl	is it about backward compatibility only ?	[16:16]
hverkuil	I think there is no such thing as a subdev entity (or v4l2 entity for that matter). Instead, an entity may have a v4l-subdev/video/demod/etc. interface.	[16:16]
pinchartl	I agree that entities should not mention V4L2 or subdev	[16:16]
mchehab	pinchartl: no, it is not about backward compat only	[16:16]
pinchartl	or DVB, ALSA or any other API	[16:17]
sailus	hverkuil: Agreed.	[16:17]
pinchartl	I'm wondering whether we really need to classify entity types in categories	[16:18]
hverkuil	I seriously dislike having entity types like _T_CAMERA_foo. I feel that this will be chaos given the huge variety of different entity types that you can have.	[16:18]
mchehab	well, MEDIA_ENT_T_SENSOR seems a bad name	[16:19]
hverkuil	I prefer to have a 'PROCESSING' entity type, and a bunch of properties that give information about the functionalities it supports.	[16:19]
mchehab	as there are other types of sensors not related to V4L devices	[16:19]
pinchartl	but wait... haven't we agreed that entities can have multiple types, and that we would call them functions ?	[16:19]
mchehab	MEDIA_ENT_T_CAMERA_SENSOR is clearer	[16:19]
hverkuil	it's not about camera vs entity, it is about trying to have the type specify what the entity does. That doesn't scale.	[16:20]
mchehab	MEDIA_ENT_T_FUN_CAMERA_SENSOR sounds funny ;) MEDIA_ENT_T_FUNCT_CAMERA_SENSOR	[16:20]
pinchartl	s/_T// MEDIA_ENT_FUNC_* or MEDIA_ENT_F_*	[16:20]
hverkuil	entities can have multiple functions, and those should be implemented as properties as discussed during the workshop.	[16:21]
pinchartl	hverkuil: agreed but we still need to define names for the functions though	[16:21]
mchehab	hverkuil: most entities will have just one function... among them, all the current entities will be in that case	[16:21]
hverkuil	The current MEDIA_ENT_T_V4L2_SUBDEV_ types remain only for the v1 API.	[16:22]
mchehab	works for me	[16:22]
pinchartl	if my recollection of the meeting is correct, we have agreed that existing entities that implement a single function would expose it directly in struct media_entity_desc for backward compatibility I'm not sure whether new entities that implement a single function should also expose it directly in struct media_entity_desc as a shortcut it could be useful for userspace, but right now I don't have a strong opinion on this hverkuil: can we define the numerical values of the functions to match the existing values of MEDIA_ENT_T_V4L2_SUBDEV_* ?	[16:22]
hverkuil	sure	[16:24]
mchehab	pinchartl: it is easier to have a map for userspace... as with a map, we will avoid to keep something at the entity struct just for backward compatibility	[16:24]
pinchartl	we need to decide whether the function properties will be integers or strings though mchehab: what do you mean by map here ?	[16:24]
mchehab	the way I see is that we'll now have something like an array/bitarray/list at the media_entity with the functions associated to it...	[16:25]
pinchartl	for the kAPI or uAPI ?	[16:25]
mchehab	and we'll remove 'type' from media_entity kABI	[16:25]
pinchartl	right, inside the kernel the type field shouldn't duplicate the functions list	[16:26]
mchehab	only the C function that would handle v1 calls will have some logic to map from the media_entity:functions into some type for backward compat	[16:26]
pinchartl	it might still make sense to keep it to tell whether the entity is a connector for instance, but that's a separate discussion mchehab: I agree	[16:27]
mchehab	(I actually used a flag for connector entities, but this is a separate discussion)	[16:27]
pinchartl	yes, separate discussion at least the current usage of the type field will be dropped inside the kernel so what's the question again ? :-)	[16:28]
hverkuil	How to represent multi-function entities And how to represent each function.	[16:29]
shuah	capabilities/properties	[16:30]
mchehab	it is not that... I guess... it is more what userspace namespace we'll use for multi-function entities, and if we'll be using the same numberspace for V1 and V2 or if we'll be doing something else	[16:31]
hverkuil	My concern is that there will be a zillion different functions. And I would like to avoid that for every new function someone needs to add a new define. mchehab: ignore v1 for now. Assume we can do this from scratch.	[16:31]
mchehab	ok... maybe it would help to look on the graphs I generated using the new G_TOPOLOGY ioctl... where, currently, there's no type or function: https://mchehab.fedorapeople.org/mc-next-gen/omap3isp.png https://mchehab.fedorapeople.org/mc-next-gen/au0828.png	[16:32]
hverkuil	My personal preference would be that we use propery strings to describe functions.	[16:32]
shuah	UAPI	[16:33]
mchehab	(I simplified the au0828 to display only 5 outputs with is generally what's actually used in practice - and hacked it to have a subdevice for the tuner - just for testing purposes)	[16:33]
hverkuil	Or we drop functions altogether and have userspace rely on the entity name. Which assumes userspace knows about it (but wouldn't it have to know anyway?)	[16:34]
mchehab	hverkuil: that's the entity name. Should we need something else?	[16:34]
pinchartl	I think we all agree that we'll use properties to list functions. we haven't agreed on whether those properties should be integers or strings. is that a good summary so far ?	[16:34]
sailus	I think the capabilities (types) are the most useful for humans to figure out what the entity is.	[16:35]
hverkuil	Hmm, what shuah has to do for alsa (find the link between tuner and decoder) is an example where you need more than the entity name. You really want to check the function as well.	[16:35]
sailus	Most applications have to recognise it exactly. Well, at least current applications. But I can see more generic applications will exist.	[16:35]
shuah	hverkuil: right	[16:35]
hverkuil	s/as well//	[16:35]
pinchartl	sailus: agreed device-specific applications can use the names but if we want to allow generic code to exist I think we'll need functions	[16:35]
shuah	thinking aloud - media tokens look lot simpler now :)	[16:36]
mchehab	sailus: I think otherwise: types (as a number) is something that helps the machine to recognize something names are what humans like	[16:36]
pinchartl	it's a bit hard to tell what the functions should be though, as there's no such generic code yet	[16:36]
mchehab	I mean: entity->names seem to be enough for humans, IMHO	[16:36]
pinchartl	but if we don't specify them now, it will be hard to add them later the uAPI will be easy	[16:36]
shuah	right we use types for kernel use which get translated to strings for user consumption - e.g: USB speeds	[16:36]
pinchartl	but all drivers would need to be patched to report functions	[16:37]
mchehab	let me refresh my memory: what are the usecases for multi-type entities?	[16:38]
pinchartl	so, regarding the userspace namespace for functions we first need to decide whether functions will be reported as integers or strings mchehab: do you mean multi-function entities ?	[16:38]
mchehab	yes	[16:38]
shuah	strings are hard to deal with	[16:39]
mchehab	shuah: agreed	[16:39]
pinchartl	we don't have any multi-function entity currently in the kernel, as there's no way to report them with the current API the idea is mostly that we don't want to restrict the new API to a single function per entity	[16:39]
mchehab	function (or types) should be something easy to be handled in applications pinchartl: but I fail to see an usercase for that	[16:39]
pinchartl	how about a sensor that can scale ? it would have two functions, image sensor and scaler	[16:40]
mchehab	could be mapped as two separate entities	[16:40]
pinchartl	that depends on the hardware	[16:41]
mchehab	? I can't see why	[16:41]
pinchartl	the functions are not always well-separated at the hardware level you can't always split them in different entities	[16:41]
mchehab	so what? one subdev interface, two entities	[16:41]
pinchartl	no the subdev pad-level API assumes one subdev == one entity	[16:42]
hverkuil	What about this: we do create MEDIA_ENT_T_foo defines + a MEDIA_ENT_T_MULTI define. If the type is MFD, then apps will have to check the properties to find the multiple types/functions of this entity.	[16:42]
sailus	mchehab: How about a sensor which has a lens as well in a single I2C device? There also could be a flash.	[16:42]
hverkuil	Hmm, perhaps type should just be renamed to 'function' in the v2 API.	[16:42]
sailus	In most cases these are separate devices, but not always. Especially the lens.	[16:42]
pinchartl	s/lens/lens controller/	[16:42]
sailus	pinchartl: Right.	[16:43]
pinchartl	there are multiple discussions in parallel here	[16:43]
mchehab	pinchartl: (13:42:20) pinchartl: the subdev pad-level API assumes one subdev == one entity	[16:43]
pinchartl	hverkuil: what was your concern regarding integers vs. strings for functions ?	[16:43]
mchehab	this would need to be changed anyway for multiple functions	[16:43]
myself	I'd argue the discussions start parallel, but then are serialized and muxed into a single IRC channel... ;) myself ducks	[16:44]
mchehab	sailus: the I2C is mapped via an interface	[16:44]
hverkuil	pinchartl: I think that we will have a huge number of different functions and for each we would have to add a new define. That's easier to handle with strings. But strings have there own disadvantages, so I think using defines is probably better. s/there/their/	[16:44]
sailus	mchehab: I'm not sure if I can follow you here.	[16:45]
pinchartl	my main concern with strings is that people will add new ones freely without giving the API much thought	[16:45]
mchehab	sailus: interfaces are used to control, entities for data	[16:45]
pinchartl	so, regardless of whether we use integers or strings, we'll need a central registry	[16:46]
mchehab	I2C is control, not data	[16:46]
pinchartl	for integers that's easy to enforce	[16:46]
hverkuil	BTW, I think renaming 'type' to 'function' for the entity v2 struct would be a good idea. Entities do not have a type, they have functions.	[16:46]
myself	Dummy entries that serve as examples?	[16:46]
mchehab	hverkuil: agreed	[16:46]
sailus	hverkuil: How about capabilities? Actually function sounds good as well.	[16:46]
mchehab	I still fail to see any case where we would have multiple functions at the same entity	[16:47]
pinchartl	would anyone prefer reporting entity functions as strings instead of integers (using the property API in both cases) ?	[16:47]
hverkuil	So an entity has a function, and if the entity has multiple functions, then the function is MEDIA_ENT_F_MULTI, and you'll have to check the properties. (note: even if there is one function, you still want to list it as a property.)	[16:47]
pinchartl	everybody, integers or strings ?	[16:48]
hverkuil	int	[16:48]
mchehab	I'm not convinced about an entity has multiple functions... let's postopone it to when we have a real usecase	[16:48]
sailus	mchehab: The sensor and lens example above?	[16:48]
shuah	int	[16:48]
pinchartl	mchehab: int or string ? sailus: int or string ?	[16:48]
mchehab	sailus: a DVB frontend has tuner and demod... we're still maping as two separate entities	[16:49]
hverkuil	cx25840: it has both audio and video decoding.	[16:49]
mchehab	sensor is one entity; lens is another entity	[16:49]
pinchartl	mchehab: int or string ? sailus: int or string ?	[16:49]
mchehab	int	[16:49]
sailus	mchehab: So you'd create one more entity for the lens controller, even if it's in the same sub-device? s/sub-device/I2C device/	[16:50]
pinchartl	sailus: INT OR STRING ?	[16:50]
sailus	pinchartl: I favour strings.	[16:50]
mchehab	hverkuil: any generic logic would need to know exactly what part cx25840 handles audio and what part handles video, in order to do the right links	[16:50]
pinchartl	too bad, we were close to an agreement on that sailus: why do you prefer strings ?	[16:51]
sailus	They're easier to read.	[16:51]
pinchartl	by the way if we use integers	[16:51]
sailus	The user space would require to have the knowledge which number means which functionality.	[16:52]
shuah	sailus: yes they are - ints could be mapped to strings for humans	[16:52]
pinchartl	I believe we'll need to define the corresponding text representation in the documentation a bit like control names that were not standardized to start with that was messy	[16:52]
sailus	I have no strong opinion on this btw.	[16:52]
pinchartl	so for every function the documentation should list the way to represent it as text for both kernel log messages and userspace applications	[16:52]
sailus	If it's only for humans, strings are an obvious choice, but programs would probably prefer numbers.	[16:52]
mchehab	yes, we should define the text sailus: btw, using strings at the Kernel API actually makes worse for apps...	[16:52]
sailus	Still I have to say that in either case, there would most likely have to be a helper library to help the applications with this.	[16:53]
pinchartl	sailus: if functions end up being used by humans only then I don't think the API should expose them	[16:53]
mchehab	as it is a way harder to translate to a locale name	[16:53]
shuah	usb_speed_string() e.g	[16:53]
mchehab	doing it at userspace is a way easier	[16:53]
pinchartl	I quite agree. same for controls, if I were to redo them from scratch I wouldn't expose control names in the uAPI	[16:54]
mchehab	agreed	[16:54]
pinchartl	so everybody is fine with integers, with a documented text representation ?	[16:54]
mchehab	yes	[16:55]
hverkuil	y	[16:55]
shuah	yes on not exposing control names in the uAPI	[16:55]
pinchartl	as integers will require #define's it will be easy to enforce propery documentation during the review process	[16:55]
shuah	yes on integers, with a documented text representation	[16:55]
pinchartl	hverkuil: regarding your MEDIA_ENT_F_MULTI proposal	[16:56]
sailus	pinchartl: Fine with me.	[16:56]
hverkuil	I have a modified proposal:	[16:56]
pinchartl	I see two ways to handle the current type field there's one constraint	[16:56]
hverkuil	you go first.	[16:56]
pinchartl	we need to keep backward compatibility so the type field must keep its current value for existing entities using MEDIA_ENT_F_MULTI for multi-function entities is one way another one would be to report the main/first function for all entities	[16:56]
***	benjiG has left	[16:57]
pinchartl	and all functions through the properties API for single-function entities the two options are the same they only differ for multi-function entities it could be useful to report the main function but on the other hand MEDIA_ENT_F_MULTI seems cleaner the third option	[16:57]
hverkuil	I was thinking of always filling in function (either with the only or the main function), and setting a flag for the entity if there are additional functions.	[16:58]
pinchartl	is to use a MEDIA_ENT_F_THROUGH_PROPS value for all new entities	[16:59]
hverkuil	That way we can postpone adding multi function support until we actually need it.	[16:59]
pinchartl	we could postpone adding MEDIA_ENT_F_MULTI too	[16:59]
mchehab	as we don't have any real usecase for multi-function, I would postpone that discussion for when we have it	[16:59]
hverkuil	Note: this is for the public API, what we do internally is a different matter (I wouldn't implement it at all for now)	[16:59]
mchehab	we can anytime add a flag or a MEDIA_ENT_F_MULTI or whatever when we have such usecase	[17:00]
pinchartl	mchehab: we still to agree on what we do now with the type field, and ensure that we can implement multi-function entities later when needed	[17:00]
mchehab	using MEDIA_ENT_F_THROUGH_PROPS value is not an option, IMHO	[17:00]
pinchartl	so, even if we don't set the API in stone right now, I'd still like to have an overall agreement on how it could look like to ensure that there will be a way forward	[17:01]
mchehab	pinchartl: sure	[17:01]
pinchartl	I don't advocate for MEDIA_ENT_F_THROUGH_PROPS, but why do you believe that would be bad ?	[17:01]
hverkuil	so we add a 'function' field to struct media_v2_entity. The type field in the existing struct will be filled with the function (the IDs remain compatible).	[17:01]
mchehab	well, I still think that we should use multiple entities, but we can revisit that later on, once we have such case hverkuil: yes	[17:01]
hverkuil	All MEDIA_ENT_T_ defines are renamed to MEDIA_ENT_F_ defines. Where we need to keep the old ones we add defines for that (#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_F_LENS)	[17:02]
mchehab	and at kernelspace, to rename "type" to "function" at media_entity	[17:03]
pinchartl	hverkuil: I'd like the function field to be clearly documented as a way to pass the function of single-function entities, and that for multi-function entities applications should not really solely on the function field that sounds good	[17:03]
hverkuil	I would advocate adding a flags field to media_v2_entity, even though we don't have flags yet.	[17:03]
mchehab	hverkuil: I actually added... and I guess you added to your RFC too ;)	[17:04]
hverkuil	pinchartl: I agree with that. Note that we should add helper functions to a media library to get the functions, so apps don't directly access the function field. I feel much more comfortable calling it 'function' rather than 'type'.	[17:04]
shuah	hverkuil: yes I vote for helper function and hide function details	[17:05]
pinchartl	hverkuil: agreed on both	[17:06]
mchehab	agreed	[17:06]
pinchartl	should we force applications to use the library in all cases ?	[17:06]
hverkuil	MEDIA_ENT_T_DVB_DEMOD as a 'type' feels arbitrary to me, but MEDIA_ENT_F_DVB_DEMOD as a function feels much better. pinchartl: you can't force that :-)	[17:06]
shuah	pinchartl: I think so that way internal changes won't break userspace	[17:06]
mchehab	hverkuil: I want to actually rename them from DVB to DTV ;)	[17:07]
pinchartl	hverkuil: you can explictly say that there's no ABI guarantee if applications don't use the library	[17:07]
hverkuil	If we make a good well-structured and documented library, then it wouldn't make sense for apps to use something else.	[17:07]
pinchartl	mchehab: I prefer DTV over DVB for entity functions, yes	[17:07]
mchehab	again, DVB is the name of the API (IMHO, a bad name, because it is actually a name of a particular standard)	[17:08]
pinchartl	it would avoid confusing the two, yes so a question that remains is do we need to split function in categories with ID ranges ?	[17:08]
mchehab	hverkuil: we can create a doxygen documentation for the library the same way as we did with libdvbv5 pinchartl: that's an interesting discussion	[17:08]
hverkuil	pinchartl: we can never break the ABI, so that makes no sense. Using the lib will make it easier to stay up to date with new API enhancements.	[17:09]
mchehab	IMHO, for new symbols, using ranges of numbers make easier to maintain but we don't want userspace to rely on it	[17:10]
pinchartl	hverkuil: we need to ensure that API extensions remain compatible with older versions of the library, sure, but I don't want to give guarantees that badly coded applications using the API directly won't break that's what ALSA does, the official API is the ALSA lib, not the kernel API mchehab: I don't want userspace to rely on it either and I feel that categories might be a bit artificial it could be difficult to find a proper category for a function so a continuous ID range might be easier	[17:10]
sailus	I think we could have categories, but I might not add classes such as we have in controls. If you look at the controls, some controls appear to be in strange classes.	[17:12]
mchehab	pinchartl: there are for sure some categories...	[17:12]
hverkuil	Having ranges allows you to group related functionalities. It is helpful for v4l2-controls.h, and I would suggest to use it here as well. But we can choose start values that do not lend themselves to abuse (e.g. DVB_BASE 0x12341234)	[17:12]
mchehab	DRM, DTV, ATV, CAMERA, ... are all categories	[17:12]
sailus	I think in documentation the groups definitely make sense.	[17:12]
pinchartl	hverkuil: how helpful is it for controls ? sailus: in documentation, I think so in the numerical IDs, I don't think I would do it	[17:12]
mchehab	hverkuil: controls actually somewhat rely on the ranges	[17:13]
hverkuil	No, classes aren't necessary. But some grouping makes it easy to 1) see if a similar function (control) already exists, since you only need to check the category, not the whole list.	[17:13]
***	Muzer has quit IRC (Excess Flood)	[17:13]
mchehab	yes, that's what I think too	[17:13]
sailus	hverkuil: Couldn't you check the documentation where the grouping exists? If a function ends up being wrongly grouped, it can be rearranged without affecting the API. And, grouping can be redone entirely, again without affecting the API.	[17:14]
hverkuil	You do have to order the list numerically to make it easy to add new IDs. Without grouping the list of defines will be messy.	[17:15]
pinchartl	I'm fine with grouping functions in the documentation and the header files hverkuil: include/uapi/linux/media-bus-format.h shows that you can sort the list alphabetically without too much issues with a /* next ID is */ comment	[17:15]
hverkuil	but it is grouped as well :-)	[17:17]
mchehab	pinchartl: include/uapi/linux/media-bus-format.h is used only by a single subsystem	[17:17]
sailus	mchehab: I think it'd being used by DRM nowadays as well.	[17:17]
mchehab	so, it is easier to maintain than something like include/linux/pci_ids.h	[17:17]
pinchartl	actually, two of them :-) it's used by DRM too	[17:17]
mchehab	just recently... and by only one driver, I think, right? it is still manageable	[17:18]
pinchartl	still, I'm not sure to see the point we won't add new functions daily	[17:19]
hverkuil	I don't have a strong opinion. I think it should certainly be grouped in the documentation, and I think it should be grouped in the header as well. But we can use a single range and use the include/uapi/linux/media-bus-format.h technique for keeping track of the next available ID.	[17:19]
mchehab	but yeah, I guess we can use the same model as what's there at media-bus-format.h	[17:19]
hverkuil	I'd be happy with that.	[17:19]
pinchartl	me too	[17:19]
hverkuil	(we just need to keep the backwards compat for the existing types).	[17:20]
pinchartl	of course mchehab: does this answer all the questions you raised in your e-mail ?	[17:20]
mchehab	there's just one left: A side discussion that we can do if we have time is how to fix those "type V4L2 subdev subtype Unknown" subdevs at OMAP3 (and likely other drivers) that are just putting all non-camera subdevices under a generic umbrella (MEDIA_ENT_T_V4L2_SUBDEV).	[17:20]
pinchartl	I'd set a proper function for them	[17:21]
mchehab	on my patches, I actually nacked the usage of MEDIA_ENT_T_V4L2_SUBDEV inside the Kernel, as this is an API abuse and added a MEDIA_ENT_T_V4L2_SUBDEV_UNKNOWN to handle such cases where the driver doesn't fill the type	[17:21]
pinchartl	OMAP3 ISP userspace code relies on MEDIA_ENT_T_V4L2_SUBDEV	[17:22]
hverkuil	perhaps this can be discussed once Laurent reviewed those patches?	[17:22]
mchehab	not anymore ;)	[17:22]
pinchartl	but only to the extend that the MSBs match	[17:22]
mchehab	sorry... userspace	[17:22]
pinchartl	the subtype is ignored	[17:22]
mchehab	ok	[17:22]
pinchartl	so we can replace MEDIA_ENT_T_V4L2_SUBDEV with proper functions as long as the MSBs keep the same numerical value	[17:23]
mchehab	pinchartl: yes, that was my idea we should keep the MEDIA_ENT_T_V4L2_SUBDEV range unused for backward compatibility reserving it to get rid of the already-existing drivers that are not filling the entity type reserving it to get rid of the already-existing drivers abuse that are not filling the entity type	[17:23]
pinchartl	http://git.ideasonboard.org/omap3-isp-live.git if you want to have a look at userspace code sailus: any idea on what the N900/N9 userspace does ? sailus: has anything been pushed to mainline gstreamer or it is all out-of-tree ?	[17:25]
sailus	I think it's all out-of-tree. Only CameraBin2 made it, and it's hardware independent.	[17:25]
mchehab	pinchartl: thinks for the pointer	[17:26]
sailus	I'm actually not even sure whether it's libomap3camd or the GStreamer source which sets up the pipeline. (I wouldn't spend much time on figuring out which one is true.) I bet only the entity name is used there.	[17:26]
mchehab	In any case, I guess we should not create anything at the range of 0x00010000 and 0x00020000 for the new entity types, to avoid conflicts with existing stuff	[17:27]
pinchartl	we might not have to reserve the complete range, but I would be fine with that	[17:28]
mchehab	so, 0x00010000-0x0002ffff would be reserved, at least for now... we may reuse it on some future, but there's no good reason, IMHO for doing that Ok, I guess we covered everything for today's meeting	[17:28]
pinchartl	\o/	[17:29]
hverkuil	dinner! (I'm hungry)	[17:30]
mchehab	I'll write a separate patch series with just those changes (applied on the top of the current patch series) for it to be reviewed	[17:30]
pinchartl	ok do you know when you'll send that ?	[17:30]
shuah	ok	[17:30]
pinchartl	hverkuil: smakelijk	[17:30]
mchehab	pinchartl: no. latter this week, I hope	[17:30]
pinchartl	mchehab: ok	[17:30]
mchehab	as otherwise, it would take some time	[17:31]
pinchartl	s/latter/later/ ;-)	[17:31]
mchehab	as I'll be busy with something else on the next two weeks	[17:31]
pinchartl	I'll travel to the US from the 15th to the 27th	[17:32]
shuah	mchehab: I am planning to port over the ALSA/au0828 work to MC next Gen just so I know for sure this MC next gen works for this case and be able to change as needed	[17:32]
hverkuil	Sep 23 to Oct 10th I'll be on vacation/ELCE/gStreamer conference.	[17:32]
mchehab	shuah: ok sounds good	[17:33]
pinchartl	I'll attend ELCE too I'll be in Dublin from the 4th to the 10th of October	[17:33]
mchehab	I won't attend ELCE... too much work	[17:34]
pinchartl	and in Belgium and France from the 28th of September to the 3rd of October	[17:34]
hverkuil	mchehab: regarding the kernel summit:	[17:34]
pinchartl	then there's the kernel summit, and I might spend the week before it in Taipei...	[17:34]
mchehab	I'll be in China in September for TDC	[17:34]
hverkuil	the media workshop is on the 26th, I believe the kernel summit on the 28th is open for us as well, right?	[17:34]
mchehab	hverkuil: 26 is open to us	[17:35]
hverkuil	Are there any plans for another meeting with Samsung engineers?	[17:35]
mchehab	27 is not ops 27 is open to us 28 is not	[17:35]
hverkuil	http://events.linuxfoundation.org/events/linux-kernel-summit/program/summit-agenda	[17:36]
mchehab	there will be the SOSCON there between 26-28	[17:36]
hverkuil	This suggests 27 is invite only, and 28 is open	[17:36]
mchehab	oh... yes, you're right	[17:36]
hverkuil	Are there any plans for another meeting with Samsung engineers?	[17:36]
mchehab	hmm... from Tso's email: The annual Kernel Summit for 2015 will be held October 26th through the 28th in Seoul, South Korea, overlapping with the Korea Linux Forum, which will be on October 26th. The format of the Kernel Summit will be: * Monday: Workshops and break out sessions (overlap with Korea Linux Forum) * Tuesday: Dual-track technical sessions * Wednesday: Invite-only core attendees' plenary sessions either the email or the site is wrong hverkuil: nothing confirmed yet	[17:37]
hverkuil	I need to know soon as I'll book hotel and flight in two weeks time at the latest.	[17:38]
mchehab	ok	[17:39]
hverkuil	I'll be there 26-28 regardless, but as things are now I might return Thu or Fri.	[17:39]
pinchartl	the open plenary will be on the 28th according to the registration form	[17:39]
shuah	right 28th is listed as open plenary - registration from doesn't mention 27th	[17:41]
pinchartl	shuah: will you attend the core discussions ?	[17:42]
shuah	that is the plan	[17:42]
pinchartl	nice :-) ok, time to get some food I'll be back later	[17:43]
mchehab	btw, for those that won't be at the core sections, there will be the Soscon between 26-28, at the same place: http://www.soscon.net/	[17:43]
shuah	ok time for lunch be back later	[17:50]
............ (idle for 56mn)
***	lyakh has quit IRC (Quit: thanks, bye)	[18:46]
.............. (idle for 1h7mn)
	mszyprow\|home has quit IRC (Ping timeout: 264 seconds) awalls has left	[19:53]
	ao2 has quit IRC (Ping timeout: 244 seconds)	[20:01]
....... (idle for 32mn)
	_daniel_1 has left	[20:33]
headless	concerning rcar_vin using subdev's querystd() method... I'm not sure the patches that make I2C subdevs support g_std() in order to work with this soc_camera driver would look good patches to make the I2C subdev drivers work with soc_camera in general are one thing... and my case is the other	[20:34]
	BTW, looking at adv7180.c, g_std() method should be the same as querystd() ah, hverkuil is away pinchartl too. OK, I'll post the patches, then we'll see	[20:48]
.... (idle for 19mn)
***	dv_ has quit IRC (Quit: scott me up, beamie!) pfallenop has quit IRC (Ping timeout: 256 seconds) ParkerR has quit IRC (Remote host closed the connection) mchehab has quit IRC (Ping timeout: 245 seconds)	[21:09]
	devinheitmuell-1 has quit IRC (Quit: devinheitmuell-1)	[21:19]
.......... (idle for 48mn)
	monkwitdafunk has quit IRC (Ping timeout: 265 seconds)	[22:07]
headless	hm, soc_camera calls subdev's g_std() from its g_std() method	[22:14]
	vidioc_g_std(), I mead meant not sure why adv7180 doen't have this method then	[22:19]
......... (idle for 40mn)
	night	[22:59]
...... (idle for 29mn)
***	iive has quit IRC (Quit: They came for me...)	[23:28]

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)