[06:18] <learningc> When I capture my camera input, I get only half of the capture width.  How can I capture the full width?
[08:50] <pinchartl> mchehab: it seems to be effective to block spammers. should we update the channel topic to tell people to register their nickname to talk ?
[09:17] <rellla> pinchartl: they get a notice, in case they try to login with an unregistered nick anyway...
[09:19] <pinchartl> rellla: are they told that they need to register to post to the channel, or do they just get a message stating they can't post, without an explanation ?
[09:19] <rellla> pinchartl: sry. i think i'm wrong as you set -r ...
[09:19] <rellla> i don't know. in case of +r they get a message, that they have to register to log in.
[09:20] <rellla> wait, i'll try :)
[09:21] <mchehab> rellla: we're not using +r
[09:21] <mchehab> instead, we're using +q $~a
[09:21] <rellla> i get "Cannot send to channel" if i want to talk as unregistered user
[09:22] <mchehab> Ok
[09:22] <mchehab> I'll add a note at the channel topic
[09:22] <rellla> but no hint to register, so changing topic would be good
[09:23] <rellla> mchehab: what does +q $~a exactly do? i just set +r for #linux-sunxi, but that seems to be suboptimal...
[09:23] <mchehab> it de-voices unregistered users
[09:24] <rellla> ok thanks. i'll try that.
[09:25] *** ChanServ sets mode: +o mchehab
[09:27] *** mchehab changes topic to: video4linux / analog video support | *only registered users can talk* | * 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
[09:31] *** mchehab changes topic to: Linux analog video support (V4L2) | *only registered users can talk* | 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
[09:37] *** mchehab changes topic to: Linux analog video support (V4L2) | *only registered users can talk* | http://linuxtv.org/wiki | repo: https://linuxtv.org/git/media_tree.git | linux-media ML: http://vger.kernel.org/vger-lists.html#linux-media | logs: http://linuxtv.org/irc/irclogger_log/v4l | bugs: http://bugzilla.kernel.org (v4l-dvb category)
[09:38] <mchehab> I guess the topic is better now
[09:38] <mchehab> I also standardized it with the one at #linuxtv
[09:38] <hverkuil> test
[09:39] <pinchartl> wait until the spammers start registering accounts :-)
[09:39] <hverkuil> Regarding media properties: would there be any reason to get them other than via VIDIOC_G_TOPOLOGY? I.e. with a G_PROP ioctl to get a specific property?
[09:40] <hverkuil> I tried that, but it is very painful since a property does not have a fixed length.
[09:41] <mchehab> pinchartl: yeah, that would require other measures
[09:42] <pinchartl> hverkuil: do you mean MEDIA_IOC_G_TOPOLOGY ?
[09:42] <hverkuil> y
[09:42] <mchehab> you also confused me :-)
[09:42] <hverkuil> oh, oops.
[09:42] <hverkuil> didn't see that :-)
[09:42] <pinchartl> I think retrieving them all in one go is fine
[09:42] <pinchartl> we might possibly want to retrieve them per entity
[09:43] <pinchartl> as an optimization
[09:43] <pinchartl> but one property at a time, I don't think so
[09:43] <hverkuil> I'll start with just G_TOPOLOGY, we can always adding a new ioctl in the future.
[09:44] <mchehab> agreed
[09:45] <mchehab> things could change we start implementing properties like controls (e.g. with set/get, dynamic changes, notification, ...)
[09:46] <mchehab> but the use cases we have so far are related to something that won't change without a topology change
[09:47] <mchehab> I mean: a color of a connector won't change :-D
[09:48] <hverkuil> Exactly, and that's my assumption: properties are read-only and static.
[09:48] <mchehab> (well, there are some metamaterials that could actually change colors - and people are experiencing with led panels that can change colors - the skull at the Haydes Canyon NUC for example can change the color)
[09:48] <hverkuil> But properties can be attached to any object (entity, pad, link, interface) although initially I only have them for entities and pads.
[09:49] <mchehab> with read-only, static properties, just G_TOPOLOGY is enough
[09:50] <mchehab> yeah, the API should be allowing props attached to any object
[09:50] <mchehab> starting with entities/pads should likely be enough for now
[09:52] *** ChanServ sets mode: -o mchehab
[10:04] <pinchartl> hverkuil: as properties are static, at least to start with, wouldn't be better to add a new MEDIA_IOC_G_PROPERTIES ioctl ?
[10:04] <pinchartl> otherwise when reading properties we've have to retrieve the whole topology too
[10:05] <pinchartl> and the other way around as well
[10:05] <pinchartl> gathering all information would take some more time
[10:05] <pinchartl> does binding topology and properties together in a single ioctl give us benefits ?
[10:07] <hverkuil> If you don't want to get the properties in G_TOPOLOGY, then just set the ptr_props to NULL.
[10:07] <hverkuil> I.e., you don't need to get properties if you don't want to.
[10:07] <pinchartl> right
[10:07] <pinchartl> but is there a need to bind properties and topology in a single ioctl ?
[10:08] <hverkuil> Frankly, I think you always want to get everything, so why split it?
[10:08] <pinchartl> especially if we want to allow retrieving a subset of all properties in the future (per-entity for instance) a separate ioctl would be easier
[10:09] <hverkuil> It's always possible to add such an ioctl in the future, but I do believe that G_TOPOLOGY should be able to return everything.
[10:10] <pinchartl> well, it's no big deal for now anyway, I'm more interested in seeing how the properties work. which ioctl is used is more of a detail and won't affect the design
[10:10] <pinchartl> we can discuss it later too
[10:11] <mchehab> IMO having everything at G_TOPOLOGY is a plus
[10:11] <mchehab> the problem of having it on a separate ioctl happens when there are hotplug stuff
[10:12] <mchehab> we want to be sure to get everything in an atomic context
[10:12] <mchehab> on a complex board with V4L2, DVB and ALSA, the topology changes at probing time
[10:13] <mchehab> as the time where each driver/subdriver registers themselves is different
[10:13] <hverkuil> mchehab: I agree
[10:13] <pinchartl> I could be convinced that it's better to bind it with the topology, but I'd like to see how it works first
[10:14] <pinchartl> again it won't influence the architecture much, so I'm not concerned at this point
[10:16] <mchehab> I'll unlog for a while... added a welcome message to the channel... want to test it
[10:19] <mchehab> Ok, when someone logs to this channel, it will now display:
[10:19] <mchehab> [#v4l] Welcome to Linux analog video support channel (V4L2). Only registered users can talk
[10:19] <mchehab> should we still keep the message about registered users at the channel topic?
[10:20] <mchehab> I guess I'll keep it for one week or so, and then remove from the topic
[10:45] <pinchartl> hopefully the spam attack will end by then
[11:02] <mchehab> well, I'll keep the mode setting
[11:03] <mchehab> but probably having the message only to the welcome message should be enough
[11:47] <mchehab> [ANN] I removed all traces of the spam attack from the logs at: https://linuxtv.org/irc/irclogger_log/v4l
[11:50] *** learningc has quit IRC (Ping timeout: 240 seconds)
[12:59] *** mszyprow_ has quit IRC (Ping timeout: 240 seconds)
[13:00] *** ttomov has quit IRC (Ping timeout: 265 seconds)
[13:02] *** indy has quit IRC (Remote host closed the connection)
[13:05] <hverkuil> mchehab: do you think you will need properties for interfaces as well?
[13:20] <mchehab> maybe
[13:21] <mchehab> properties at interface level could be useful for generic apps to work with subdevs
[13:22] <mchehab> I would keep it at documentation level
[13:22] <pinchartl> I have no use case at the moment but I can imagine there could be use cases
[13:22] <pinchartl> would it affect the userspace API ?
[13:22] <mchehab> if we'll actually implement it or not is something to be decided once we have an use case
[13:23] <hverkuil> Hmm, never mind. I can simplify this so it doesn't affect the userspace API.
[13:23] <mchehab> IMO, the userspace API should be generic enough, e. g. Object ID#999 will be associated to a set of API properties
[13:24] <mchehab> (won't matter what would be the type of ID#999)
[13:25] <mchehab> at Kernel level, we could bind a properties list at the graphic object, making it generic enough to be used by all kinds of objects
[13:25] <mchehab> this way, if we ever need an interface properties set, it would be just a matter of adding the properties that would be pertinent to the interface, without needing to write too much stuff
[13:26] <hverkuil> that's what I did, but I also added num_props fields to media_v2_entity/pad/interface, but I don't need to do that.
[13:26] <mchehab> I would avoid adding a num_props field
[13:27] <mchehab> this can be dynamically incremented at G_TOPOLOGY code while it navigates at the properties list
[13:27] <mchehab> also, I wouldn't have a num_props per object type there... just a global number of props returned to userspace
[13:28] <mchehab> btw, if one is using G_TOPOLOGY to query just a subset of object types (for instance, just entities), it probably make sense to return only the properties associated with such type
[13:29] <hverkuil> I hadn't thought of that one. Let me see how hard that is to implement.
[13:30] <pinchartl> mchehab: regarding number of properties per object type, or per object, versus a global number of properties
[13:30] <pinchartl> I agree with you
[13:31] <pinchartl> but I think we should try to lay out the properties in the buffer in a way that makes it easy to navigate it
[13:31] <pinchartl> if there was a way to jump to properties for a given object for instance, it could be interesting
[13:31] <pinchartl> I don't know how yet
[13:31] <pinchartl> just something to keep in mind
[13:32] <mchehab> yeah, we could try to do some optimizations internally at Kernel level to speed up access to props, but I prefer to have a sub-optimal internal implementation than a sub-optimal API interface
[13:32] <mchehab> we can change the internal representation any time, but changing the API is a way harder
[13:34] <mchehab> hverkuil: no matter what internal model you used, it should be easy to implement...
[13:34] <mchehab> as the object ID carries the type
[13:34] <mchehab> so, filtering out objects from a given type should be easy
[13:37] <mchehab> so, if you want just entities, you could do:
[13:37] <mchehab>  if (media_type(obj) == MEDIA_GRAPH_ENTITY)
[13:39] <mchehab> the actual code would be somethat like:
[13:40] <mchehab> if ((uentity && media_type(obj) == MEDIA_GRAPH_ENTITY)
[13:40] <mchehab>     || ... ) {
[13:40] <mchehab>     /* Add properties for the object */
[13:40] <mchehab> }
[13:42] <mchehab> where "..." would be similar tests for uintf, upad and ulink
[13:42] <pinchartl> mchehab: by internal representation, I meant the way properties are layed out in the buffer passed to userspace, so it's part of the public API
[13:42] <pinchartl> they could be organized in a tree-based structure instead of in a list for instance
[13:43] <mchehab> IMHO, no matter if internally we use a tree-based structure, I would be passing a list to userspace
[13:43] <pinchartl> mchehab: let's discuss that based on the patches
[13:43] <mchehab> IMO, that makes the interface simpler and flexible-enough
[13:45] <mchehab> and it would be easy for userspace to internally use trees - or to just filter the properties it wants, binding them to whatever object representation they use
[13:50] <mchehab> anyway, as you said, let's see what hverkuil is proposing on his patchset
[13:56] *** ndufresne has quit IRC (Ping timeout: 245 seconds)
[14:00] <hverkuil> I can lay out the properties grouped per type (entity, pad, etc), and within that per object that owns the properties.
[14:05] *** snawrocki has quit IRC (Remote host closed the connection)
[14:13] <mchehab> that would work
[14:13] <mchehab> IMHO, the best model would be to use a tree based struct like:
[14:13] <mchehab> object -> type -> object ID -> property set
[14:14] <mchehab> actually...
[14:14] <mchehab> root -> object type -> object ID -> property set
[14:15] <mchehab> eventually, the property set could also be a tree struct too (as sailus proposed initially)
[14:15] <mchehab> but, as I said, the internal model can be changed anytime
[14:15] <mchehab> provided that we won't change the API
[14:21] *** pH5 has quit IRC (Quit: bye)
[14:32] *** bparrot has quit IRC (Remote host closed the connection)
[14:37] <hverkuil> I posted a first RFC. Please read the cover letter first before reviewing :-)
[14:51] <mchehab> :-D
[14:52] <mchehab> anyway, I'll likely be ruthless while reviewing it ;-p
[15:00] *** benjiG has left 
[15:34] *** dmt has quit IRC (Remote host closed the connection)
[15:44] *** svarbanov has left 
[17:13] <mchehab> hverkuil: sent my comments to the RFC
[17:13] <mchehab> won't comment about patch 3... it is just test stuff :-D
[18:33] <mchehab> hverkuil, pinchartl, sailus: just sent an email to the ML with the summary of yesterday's discussions about connectors and DT bindings
[18:33] <mchehab> feel free to comment
[18:33] <mchehab> I c/c the ones that are at patch 19/22 thread
[19:02] *** mmattice has quit IRC (Read error: Connection reset by peer)
[21:27] *** ao2 has quit IRC (Quit: Leaving)
[21:56] *** lyakh has quit IRC (Quit: thanks, bye)
[23:11] *** mchehab has quit IRC (Ping timeout: 240 seconds)