<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
pinchartl: <u>mchehab</u>: it seems to be effective to block spammers. should we update the channel topic to tell people to register their nickname to talk ?
rellla: <u>pinchartl</u>: they get a notice, in case they try to login with an unregistered nick anyway...
pinchartl: <u>rellla</u>: 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 ?
rellla: <u>pinchartl</u>: sry. i think i'm wrong as you set -r ...
<br> i don't know. in case of +r they get a message, that they have to register to log in.
<br> wait, i'll try :)
mchehab: <u>rellla</u>: we're not using +r
<br> instead, we're using +q $~a
rellla: i get "Cannot send to channel" if i want to talk as unregistered user
mchehab: Ok
<br> I'll add a note at the channel topic
rellla: but no hint to register, so changing topic would be good
<br> <u>mchehab</u>: what does +q $~a exactly do? i just set +r for #linux-sunxi, but that seems to be suboptimal...
mchehab: it de-voices unregistered users
rellla: ok thanks. i'll try that.
***: ChanServ sets mode: +o mchehab
<br> 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
<br> 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
<br> 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)
mchehab: I guess the topic is better now
<br> I also standardized it with the one at #linuxtv
hverkuil: test
pinchartl: wait until the spammers start registering accounts :-)
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?
<br> I tried that, but it is very painful since a property does not have a fixed length.
mchehab: <u>pinchartl</u>: yeah, that would require other measures
pinchartl: <u>hverkuil</u>: do you mean MEDIA_IOC_G_TOPOLOGY ?
hverkuil: y
mchehab: you also confused me :-)
hverkuil: oh, oops.
<br> didn't see that :-)
pinchartl: I think retrieving them all in one go is fine
<br> we might possibly want to retrieve them per entity
<br> as an optimization
<br> but one property at a time, I don't think so
hverkuil: I'll start with just G_TOPOLOGY, we can always adding a new ioctl in the future.
mchehab: agreed
<br> things could change we start implementing properties like controls (e.g. with set/get, dynamic changes, notification, ...)
<br> but the use cases we have so far are related to something that won't change without a topology change
<br> I mean: a color of a connector won't change :-D
hverkuil: Exactly, and that's my assumption: properties are read-only and static.
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)
hverkuil: But properties can be attached to any object (entity, pad, link, interface) although initially I only have them for entities and pads.
mchehab: with read-only, static properties, just G_TOPOLOGY is enough
<br> yeah, the API should be allowing props attached to any object
<br> starting with entities/pads should likely be enough for now
***: ChanServ sets mode: -o mchehab
pinchartl: <u>hverkuil</u>: as properties are static, at least to start with, wouldn't be better to add a new MEDIA_IOC_G_PROPERTIES ioctl ?
<br> otherwise when reading properties we've have to retrieve the whole topology too
<br> and the other way around as well
<br> gathering all information would take some more time
<br> does binding topology and properties together in a single ioctl give us benefits ?
hverkuil: If you don't want to get the properties in G_TOPOLOGY, then just set the ptr_props to NULL.
<br> I.e., you don't need to get properties if you don't want to.
pinchartl: right
<br> but is there a need to bind properties and topology in a single ioctl ?
hverkuil: Frankly, I think you always want to get everything, so why split it?
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
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.
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
<br> we can discuss it later too
mchehab: IMO having everything at G_TOPOLOGY is a plus
<br> the problem of having it on a separate ioctl happens when there are hotplug stuff
<br> we want to be sure to get everything in an atomic context
<br> on a complex board with V4L2, DVB and ALSA, the topology changes at probing time
<br> as the time where each driver/subdriver registers themselves is different
hverkuil: <u>mchehab</u>: I agree
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
<br> again it won't influence the architecture much, so I'm not concerned at this point
mchehab: I'll unlog for a while... added a welcome message to the channel... want to test it
<br> Ok, when someone logs to this channel, it will now display:
<br> [#v4l] Welcome to Linux analog video support channel (V4L2). Only registered users can talk
<br> should we still keep the message about registered users at the channel topic?
<br> I guess I'll keep it for one week or so, and then remove from the topic
pinchartl: hopefully the spam attack will end by then
mchehab: well, I'll keep the mode setting
<br> but probably having the message only to the welcome message should be enough
<br> [ANN] I removed all traces of the spam attack from the logs at: https://linuxtv.org/irc/irclogger_log/v4l
***: learningc has quit IRC (Ping timeout: 240 seconds)
<br> mszyprow_ has quit IRC (Ping timeout: 240 seconds)
<br> ttomov has quit IRC (Ping timeout: 265 seconds)
<br> indy has quit IRC (Remote host closed the connection)
hverkuil: <u>mchehab</u>: do you think you will need properties for interfaces as well?
mchehab: maybe
<br> properties at interface level could be useful for generic apps to work with subdevs
<br> I would keep it at documentation level
pinchartl: I have no use case at the moment but I can imagine there could be use cases
<br> would it affect the userspace API ?
mchehab: if we'll actually implement it or not is something to be decided once we have an use case
hverkuil: Hmm, never mind. I can simplify this so it doesn't affect the userspace API.
mchehab: IMO, the userspace API should be generic enough, e. g. Object ID#999 will be associated to a set of API properties
<br> (won't matter what would be the type of ID#999)
<br> 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
<br> 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
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.
mchehab: I would avoid adding a num_props field
<br> this can be dynamically incremented at G_TOPOLOGY code while it navigates at the properties list
<br> also, I wouldn't have a num_props per object type there... just a global number of props returned to userspace
<br> 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
hverkuil: I hadn't thought of that one. Let me see how hard that is to implement.
pinchartl: <u>mchehab</u>: regarding number of properties per object type, or per object, versus a global number of properties
<br> I agree with you
<br> but I think we should try to lay out the properties in the buffer in a way that makes it easy to navigate it
<br> if there was a way to jump to properties for a given object for instance, it could be interesting
<br> I don't know how yet
<br> just something to keep in mind
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
<br> we can change the internal representation any time, but changing the API is a way harder
<br> <u>hverkuil</u>: no matter what internal model you used, it should be easy to implement...
<br> as the object ID carries the type
<br> so, filtering out objects from a given type should be easy
<br> so, if you want just entities, you could do:
<br> if (media_type(obj) == MEDIA_GRAPH_ENTITY)
<br> the actual code would be somethat like:
<br> if ((uentity && media_type(obj) == MEDIA_GRAPH_ENTITY)
<br> || ... ) {
<br> /* Add properties for the object */
<br> }
<br> where "..." would be similar tests for uintf, upad and ulink
pinchartl: <u>mchehab</u>: 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
<br> they could be organized in a tree-based structure instead of in a list for instance
mchehab: IMHO, no matter if internally we use a tree-based structure, I would be passing a list to userspace
pinchartl: <u>mchehab</u>: let's discuss that based on the patches
mchehab: IMO, that makes the interface simpler and flexible-enough
<br> 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
<br> anyway, as you said, let's see what hverkuil is proposing on his patchset
***: ndufresne has quit IRC (Ping timeout: 245 seconds)
hverkuil: I can lay out the properties grouped per type (entity, pad, etc), and within that per object that owns the properties.
***: snawrocki has quit IRC (Remote host closed the connection)
mchehab: that would work
<br> IMHO, the best model would be to use a tree based struct like:
<br> object -> type -> object ID -> property set
<br> actually...
<br> root -> object type -> object ID -> property set
<br> eventually, the property set could also be a tree struct too (as sailus proposed initially)
<br> but, as I said, the internal model can be changed anytime
<br> provided that we won't change the API
***: pH5 has quit IRC (Quit: bye)
<br> bparrot has quit IRC (Remote host closed the connection)
hverkuil: I posted a first RFC. Please read the cover letter first before reviewing :-)
mchehab: :-D
<br> anyway, I'll likely be ruthless while reviewing it ;-p
***: benjiG has left
<br> dmt has quit IRC (Remote host closed the connection)
<br> svarbanov has left
mchehab: <u>hverkuil</u>: sent my comments to the RFC
<br> won't comment about patch 3... it is just test stuff :-D
<br> hverkuil, pinchartl, sailus: just sent an email to the ML with the summary of yesterday's discussions about connectors and DT bindings
<br> feel free to comment
<br> I c/c the ones that are at patch 19/22 thread
***: mmattice has quit IRC (Read error: Connection reset by peer)
<br> ao2 has quit IRC (Quit: Leaving)
<br> lyakh has quit IRC (Quit: thanks, bye)
<br> mchehab has quit IRC (Ping timeout: 240 seconds)